path: root/34/623e050d0c13b2e2bba7011898d378ddcbedc5

Delivery-date: Thu, 13 Mar 2025 20:33:27 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD3YNWFH7IHBB7GGZ27AMGQEH3OK5CI@googlegroups.com>)
	id 1tsvna-0003gU-AU
	for bitcoindev@gnusha.org; Thu, 13 Mar 2025 20:33:27 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e63405c626asf1781454276.1
        for <bitcoindev@gnusha.org>; Thu, 13 Mar 2025 20:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741923200; x=1742528000; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=jRYAkjq329gcC5picu6m081DU3GIRSntiGGvMru1Z28=;
        b=StlV7kLDHSag+66fx53n1t+2TKmqmw8FVBcm2MD+cm5wdzAfzLNZjd1baAwU6dFOVG
         vElOfx+5XULbMrGdDtC7DUalYjULDbJTaAump0zP/O+LfvNx0d/yoYOVGC9HUjxV1WSQ
         jb6iC0jpml6B5orlrRUFxJIXMRPLaoCd7Z7VbQE1udd4TDNVlggTL906Mma+Bo02fnLN
         mydf74kpG+t2SvioAHdr92QxqDup+0de39NQYnD+m4499j/q4i6WKkX4DBY3KgCUmTvv
         L135O82RRbjfjl/bVn1ft5r38GABmEnLuOyS+3f/bA/Dtg219xKOIoCcCu4v7SbYEETz
         wZyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741923200; x=1742528000;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jRYAkjq329gcC5picu6m081DU3GIRSntiGGvMru1Z28=;
        b=SNpyJ6c5sOOY4EcWVfo3QhNvO/vIsahMEQ5YjSoTGi8EDTFXjHLX+GhDTY7l10kaRu
         1RdSdMeUIT3VHMUFkmu5sAMRKwDrwNC/kampFVcXEZDMOAs/2WQgydNj9P/LH/Q1ZzSl
         1NhOXnr9h6T0CmSFepWM49CFJH4emYOiidVObE1+qbZwVLWn29dGh4frf3MEZz7wVlIU
         PNM1qZOshRqHb6Ib25la4yLJE/p2BaZBadBvLC64h+1Z2QFFQ90sw3Tyewc0PEaIfUo4
         LHNASsk3+a7glMGRV4gIHKGJjTKpfWuQdxequqMl/W30A9tCnzE10Qhqepfj+SXsBiVo
         Fwcw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX8xyhzg6bzZFMGuOic0oMNH+0WfyrXCl7s8rqDVehmHgSnkmbaXFuIkifc5omOJGCgdJpeR8CRLjRj@gnusha.org
X-Gm-Message-State: AOJu0YwbvVPWeHf16D2kKuPn1m4N7qLy5Wo0AwGEzex4M2G3CMQQyBoB
	xGjAIIJ6loS3u49n2DFKjGFni+HgEQVZQR6bJMlw3bHYzebhsiPa
X-Google-Smtp-Source: AGHT+IEjrOKCDXAIU/CIElRwE6XFk27ZM3R79LH5Lx4zAsoKJIA7pVJhlHZdOmSufbtv7Sr/zvaBSA==
X-Received: by 2002:a05:6902:2308:b0:e63:6443:2ecd with SMTP id 3f1490d57ef6-e63f653701fmr1111720276.27.1741923200030;
        Thu, 13 Mar 2025 20:33:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKLLsvZr/SAAIwRSRwCQeCgvwd0MZHfS7FcbcEHANM9nw==
Received: by 2002:a25:d306:0:b0:e63:fe96:113f with SMTP id 3f1490d57ef6-e63fe96138els34641276.1.-pod-prod-05-us;
 Thu, 13 Mar 2025 20:33:16 -0700 (PDT)
X-Received: by 2002:a05:690c:c08:b0:6fe:aa66:5d82 with SMTP id 00721157ae682-6ff45fa652dmr10706627b3.19.1741923195887;
        Thu, 13 Mar 2025 20:33:15 -0700 (PDT)
Received: by 2002:a05:690c:288a:b0:6fb:b341:b6f6 with SMTP id 00721157ae682-6ff19b1c6f6ms7b3;
        Wed, 12 Mar 2025 14:05:23 -0700 (PDT)
X-Received: by 2002:a05:690c:45c1:b0:6f9:45de:408f with SMTP id 00721157ae682-6febf3e4a7amr318421267b3.35.1741813522588;
        Wed, 12 Mar 2025 14:05:22 -0700 (PDT)
Date: Wed, 12 Mar 2025 14:05:22 -0700 (PDT)
From: Hunter Beast <hunter@surmount.systems>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <ae919b55-cd35-40a1-95a3-96551eadec9an@googlegroups.com>
In-Reply-To: <77dbf51a-93aa-4d4a-87c0-b1303d83d5ccn@googlegroups.com>
References: <8797807d-e017-44e2-b419-803291779007n@googlegroups.com>
 <5667eb21-cd56-411d-a29f-81604752b7c4@gmail.com>
 <16d7adca-a01e-40c5-9570-31967ee339ecn@googlegroups.com>
 <5550807e-0655-4895-bc66-1b67bfde8c3e@gmail.com>
 <8e1cf1b5-27d1-4510-afec-52fb28959189n@googlegroups.com>
 <69ab395f-acba-4d11-87ee-9da6327509c6@gmail.com>
 <fac67bec-cbf3-4e49-b73d-f8057adca0aan@googlegroups.com>
 <77dbf51a-93aa-4d4a-87c0-b1303d83d5ccn@googlegroups.com>
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_91146_890765621.1741813522055"
X-Original-Sender: hunter@surmount.systems
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

------=_Part_91146_890765621.1741813522055
Content-Type: multipart/alternative; 
	boundary="----=_Part_91147_1693723470.1741813522055"

------=_Part_91147_1693723470.1741813522055
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

P2TRH doesn't protect against short exposure attacks.
Matt Corallo's approach basically breaks the entire existing Taproot=20
ecosystem because nobody is using PQC opcodes.
Anyway, I guess the alternative is to wait for the Binance cold wallet to=
=20
get hacked and then everyone rushes to move their funds using private=20
mempools that have limited capacity.
Either that or we wait until a perfect algorithm that does not yet exist=20
gets FIPS-certified within the next 5 years.
Not sure what else to say other than I guess we just let perfect be the=20
enemy of the good until it's too late.
Anyway, I'll keep working on this in the meantime until it's needed.
Thanks for all the support, guys.

On Wednesday, March 12, 2025 at 6:41:09=E2=80=AFAM UTC-6 Jose Storopoli wro=
te:

> I think that ECDSA was a mistake in Bitcoin (Schnorr patent expired in=20
> 2008; but I do understand its motives).
> My fear is that this BIP will become a mistake in Bitcoin in 15 years or=
=20
> less.
>
> It adds orders of magnitude to public keys sizes and/or signature sizes;=
=20
> and verification computation cost.
> About the whole QR cryptography hype:
> one thing is to do have key encapsulation QR schemes in symmetric-key=20
> cryptography where we don't have tight constrains around storage,
> like with TLS, or E2EE messaging apps.
> Another thing is to add these huge public key and signature schemes to a=
=20
> storage-restricted blockchain like Bitcoin.
> QR lattice-based asymmetric-key cryptography is still in its infancy both=
=20
> in standards and research; and we should wait.
>
> If we are worried about quantum menaces, a much better approach would be=
=20
> the P2TRH (Pay To Taproot Hash),
> even with the loss of batch verification, combined with advising users to=
=20
> not re-use address.
> Address reuse should be treated the same as nonce reuse: you get pwned!
> Or Matt Corallo's emergency disable of key path spends in P2TR;
>
> Jose Storopoli
>
> On Monday, March 3, 2025 at 6:55:19=E2=80=AFPM UTC-3 Hunter Beast wrote:
>
>> Hi, Jonas
>>
>> In order to spend the coins, a valid signature will need to be present i=
n=20
>> the attestation. Even if it's a 1/1024 multisig, a valid public key=20
>> signature pair will need to be provided. The merkle path would then be h=
ow=20
>> the arbitrary data could be encoded. In my mind this is a highly=20
>> impractical scenario that gets exponentially more complex, and only work=
s=20
>> 32 bytes at a time.
>>
>> Does that make sense?
>>
>> Hunter
>>
>> On Wednesday, February 26, 2025 at 3:00:36=E2=80=AFAM UTC-7 Jonas Nick w=
rote:
>>
>>> > it would require an extraordinary amount of computation to wind up=20
>>> with enough=20
>>> > to store arbitrary data.=20
>>>
>>> I have no idea why this would require extraordinary amount of=20
>>> computation. In=20
>>> the example I provided, arbitrary data can be included in the=20
>>> attestation=20
>>> structure with zero additional computational cost, no elliptic curve=20
>>> grinding or=20
>>> hash collisions required.=20
>>>
>>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
ae919b55-cd35-40a1-95a3-96551eadec9an%40googlegroups.com.

------=_Part_91147_1693723470.1741813522055
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>P2TRH doesn't protect against short exposure attacks.</div><div>Matt C=
orallo's approach basically breaks the entire existing Taproot ecosystem be=
cause nobody is using PQC opcodes.</div><div>Anyway, I guess the alternativ=
e is to wait for the Binance cold wallet to get hacked and then everyone ru=
shes to move their funds using private mempools that have limited capacity.=
</div><div>Either that or we wait until a perfect algorithm that does not y=
et exist gets FIPS-certified within the next 5 years.</div><div>Not sure wh=
at else to say other than I guess we just let perfect be the enemy of the g=
ood until it's too late.</div><div>Anyway, I'll keep working on this in the=
 meantime until it's needed.</div><div>Thanks for all the support, guys.<br=
 /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_=
attr">On Wednesday, March 12, 2025 at 6:41:09=E2=80=AFAM UTC-6 Jose Storopo=
li wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 =
0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I t=
hink that ECDSA was a mistake in Bitcoin (Schnorr patent expired in 2008; b=
ut I do understand its motives).<div>My fear is that this BIP will become a=
 mistake in Bitcoin in 15 years or less.</div><div><br></div><div>It adds o=
rders of magnitude to public keys sizes and/or signature sizes; and verific=
ation computation cost.</div><div>About the whole QR cryptography hype:</di=
v><div>one thing is to do have key encapsulation QR schemes in symmetric-ke=
y cryptography where we don&#39;t have tight constrains around storage,</di=
v><div>like with TLS, or E2EE messaging apps.</div><div>Another thing is to=
 add these huge public key and signature schemes to a storage-restricted bl=
ockchain like Bitcoin.</div><div>QR lattice-based asymmetric-key cryptograp=
hy is still in its infancy both in standards and research; and we should wa=
it.</div><div><br></div><div>If we are worried about quantum menaces, a muc=
h better approach would be the P2TRH (Pay To Taproot Hash),</div><div>even =
with the loss of batch verification, combined with advising users to not re=
-use address.</div><div>Address reuse should be treated the same as nonce r=
euse: you get pwned!</div><div>Or Matt Corallo&#39;s emergency disable of k=
ey path spends in P2TR;<br></div><div><br></div><div>Jose Storopoli</div><b=
r><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Mond=
ay, March 3, 2025 at 6:55:19=E2=80=AFPM UTC-3 Hunter Beast wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">Hi, Jonas<div><br></div><div>In=
 order to spend the coins, a valid signature will need to be present in the=
 attestation. Even if it&#39;s a 1/1024 multisig, a valid public key signat=
ure pair will need to be provided. The merkle path would then be how the ar=
bitrary data could be encoded. In my mind this is a highly impractical scen=
ario that gets exponentially more complex, and only works 32 bytes at a tim=
e.</div><div><br></div><div>Does that make sense?</div><div><br></div><div>=
Hunter<br><br></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"g=
mail_attr">On Wednesday, February 26, 2025 at 3:00:36=E2=80=AFAM UTC-7 Jona=
s Nick wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> &gt; it=
 would require an extraordinary amount of computation to wind up with enoug=
h
<br> &gt; to store arbitrary data.
<br>
<br>I have no idea why this would require extraordinary amount of computati=
on. In
<br>the example I provided, arbitrary data can be included in the attestati=
on
<br>structure with zero additional computational cost, no elliptic curve gr=
inding or
<br>hash collisions required.
<br></blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/ae919b55-cd35-40a1-95a3-96551eadec9an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/ae919b55-cd35-40a1-95a3-96551eadec9an%40googlegroups.com</a>.<br />

------=_Part_91147_1693723470.1741813522055--

------=_Part_91146_890765621.1741813522055--