path: root/c8/b9cad16dcbc749425480b99b5a1c5605bf2831

Delivery-date: Sat, 11 May 2024 09:27:15 -0700
Received: from mail-yw1-f188.google.com ([209.85.128.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBW5Y72YQMGQESIAB5HQ@googlegroups.com>)
	id 1s5pZ5-00038u-5f
	for bitcoindev@gnusha.org; Sat, 11 May 2024 09:27:15 -0700
Received: by mail-yw1-f188.google.com with SMTP id 00721157ae682-61510f72bb3sf59901617b3.0
        for <bitcoindev@gnusha.org>; Sat, 11 May 2024 09:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1715444829; x=1716049629; 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=Q1KkrPWb3pgoFK9JA4hlSmeS4ChuLlIhZeHhlODvvP4=;
        b=D2VxLGyHXbV3tgWOacSd4fjstcCGYpRU/4qk7Ypof5vhnDRc0KRpzzB4khsIDs/r8m
         IrbtkG/WA/JW+kml1EOUaOS9w3ZHktoxxcup1qq5zFxj4dHcaK6O7ONpR47Slw13G4K0
         uCvPxK9108ZiiQUni7PZvuOuLKM2PQyphHNq2FbPWSTAzAPa/N8onCL6LLdWwJgZj0qI
         GP1DN757QK1LiHT3s9e5m9xJVEJ97PQnvlC5X1lgQZCfbYZvWGIOCerrtNJ+Ljl7f0Z3
         El9cMD1zd0dAgcBCjJtoxT444j/uf5++ZTB7Js9xtnKtxnVwMQ/MZV3CKeglNDC0sPDY
         qfKQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1715444829; x=1716049629; 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:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Q1KkrPWb3pgoFK9JA4hlSmeS4ChuLlIhZeHhlODvvP4=;
        b=NsX4NdvLD0cxqtPpn92mgi4kk1kFYzFqscI/eF9aj0jWkGX2eDcrEDAvU/ZYzVPNbJ
         0fVqFIBlbejtIYKhFTC3Rvzkj+CztecurzB8k1FBMjHXnTVmApezwovpbY//Y3K8sqR5
         f1809zfNPCCAV4Y0QZUD5CBxuO/2rj6+VSp0sAAxBmh9Ajk5z+L8FHhYAMsaEmR3ERdR
         7BWJ5ZyJtTZOeqJPzk7zis2eZkOsQF6K6CrWyHP7+pV9BI3fqbUqxqmzaJL8sxmhzdmP
         5Kic5W1kaq30PEki49JHiOyk1crpzTtYLOgyepvJtTnkrPG3dfF3dWcNs4/kp85zQWT5
         nnFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1715444829; x=1716049629;
        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=Q1KkrPWb3pgoFK9JA4hlSmeS4ChuLlIhZeHhlODvvP4=;
        b=ugSB2cg+L3p+1Yz/0GM2wIkU37p5FTVUQNKsLq6T0WJz/+FZ2fswaewp7kXVlT8TZJ
         M3M2MJgrXLfe8y8rLnBwNSKHMi01xz3VCLRZdB6y5fUA36w/3OHEzIFqS/UqnfwOYSwb
         gZjLx79gpQRKnRweJJDWYDfkHF1FUYQFbLdsaCb9ssSeoE7rfkJJaXvCu3v6eDgt5Cdy
         5jXk10oWHIdQkBVreLvlVlUwMqd+W97y5rSYLQq7Ny/in+Jr4ITG7lfGPIfrWhTI96TB
         zwGdUM7Yg0qzeqD7gCwt86B+icuwV/NFAPiufA29+IE3965OVNn/IqXp3FYABD0k9y2U
         QkaQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVlf8i9LGth7qJujhryrJ4YH21N3KFVKXdRwV633sR47H5U7s0SJcM9baUgslLC7cAtJBl50qd8LqlAblWe4oVWdzvyBQ4=
X-Gm-Message-State: AOJu0YznqMqJmjLLmjN8Fz1SuPL4xBLPEszmEdEOJZ8WWD0SwTVYIsY9
	n3tbYEMqI2+roN/8iWL0BN683BqKEqYtLjzkK+TQqoTrASsJE/4A
X-Google-Smtp-Source: AGHT+IGF/7fSVvklHIomzN4YfFcmGqxkAc2E7b7SkCuXB0dU+V+LtLvgUitOPUpJ8l+NCpLk4e2YCA==
X-Received: by 2002:a25:5557:0:b0:de5:4d41:80c3 with SMTP id 3f1490d57ef6-dee4f37dd38mr5704124276.55.1715444828907;
        Sat, 11 May 2024 09:27:08 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:2e04:0:b0:de5:b132:90f0 with SMTP id 3f1490d57ef6-debcfefb514ls866160276.0.-pod-prod-07-us;
 Sat, 11 May 2024 09:27:07 -0700 (PDT)
X-Received: by 2002:a25:fe0f:0:b0:de4:7be7:1c2d with SMTP id 3f1490d57ef6-dee4f31fb93mr1379220276.11.1715444826866;
        Sat, 11 May 2024 09:27:06 -0700 (PDT)
Received: by 2002:a05:690c:97:b0:622:b23d:3cdf with SMTP id 00721157ae682-622b23d3d16ms7b3;
        Fri, 10 May 2024 19:53:56 -0700 (PDT)
X-Received: by 2002:a05:690c:380d:b0:61b:eb26:a08c with SMTP id 00721157ae682-622affb442cmr11785557b3.7.1715396033547;
        Fri, 10 May 2024 19:53:53 -0700 (PDT)
Date: Fri, 10 May 2024 19:53:53 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <9e48edb6-1909-4eee-a0c7-48123f42a198n@googlegroups.com>
In-Reply-To: <ZjzFtus_aBchwKz2@camus>
References: <CAEM=y+XyW8wNOekw13C5jDMzQ-dOJpQrBC+qR8-uDot25tM=XA@mail.gmail.com>
 <CA+x5asTOTai_4yNGEgtKEqAchuWJ0jGDEgMqHFYDwactPnrgyw@mail.gmail.com>
 <ZjD-dMMGxoGNgzIg@camus>
 <b50b6b09-4d13-46ab-9776-f6b8a02aa2e0n@googlegroups.com>
 <ZjzFtus_aBchwKz2@camus>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport
 Signatures (no changes needed)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_82594_60687045.1715396033218"
X-Original-Sender: antoine.riard@gmail.com
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.5 (/)

------=_Part_82594_60687045.1715396033218
Content-Type: multipart/alternative; 
	boundary="----=_Part_82595_1310793545.1715396033218"

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

Hi Ethan,

> It sounded like originally you were saying she can't bump her fee
> without double signing, but as you point out ANYONECANPAY or CPFP
> let's you do fee bumping without double signing. This doesn't seem
> different from say a pre-signed bitcoin transaction that you can't
> change transaction hash of.

With lamport signature, the public key is committed in the coin. Once
you're spending the coin, the secret key must be revealed to commit to
the transaction hash. The secret key cannot be re-used to commit to
another transaction hash and the spend *in its current state* must be
included in the chain.

With pre-signed bitcoin transaction under ecdsa / schnorr, the signer
group can change the transaction hash (e.g adjust destination or feerate),
assuming "off-chain" interactivity.

> I don't see the attack. If the point at infinity is forbidden, how is
> this exploited? Wouldn't the attacker's signature just be rejected by
> the network?

Yes, a pair of ecdsa (r, s) integers verifying as a point at infinity
would be rejected by the network. Assume short r-value that can be guessed
by the attacker, the k nonce is fixed and the attacker can contribute to
the transaction hash. Can the attacker contributes to the transaction hash
in way the pair of ecdsa (r, s) verifies as a point at infinity ?

I don't think the attack works as the private key d is still assume to
be secret here, and the computational space to find short-r and hash=20
contribution inputs to provoke a point at infinity collision sounds to be=
=20
huge.
Though I cannot convince myself without a more fleshed scheme.

> If someone discovers a smaller r than used in the signatures, they
> would break the existing signatures I agree. Grover's might break P2SH
> in general so Bitcoin might be in real trouble at that point.

I still wonder if you could have tree of such lamport pubkeys, to have more
sounds true lamport signature with a 1-to-1 bit mapping between transaction
bit and lamport secret key bit ? Sounds you will hit consensus limits. And=
=20
yeah
note Grover's algo could also be used to break proof-of-work mining races,
so trouble.

> No APO?

There is a "faux-ctv" variant I think known by a lot of people, where with
bip118 anyprevout you can have no-input signature committed in the redeem=
=20
script.
A way to have ensure any spending child is a valid pre-image of the=20
signature digest.

Best,
Antoine

Le jeudi 9 mai 2024 =C3=A0 13:49:04 UTC+1, Andrew Poelstra a =C3=A9crit :

> On Wed, May 08, 2024 at 05:31:18PM -0700, Ben Carman wrote:
> > I think it is possible to get past the 201 op code limit doing it in=20
> > tapscript. I don't think it would have the same quantum security but=20
> could=20
> > maybe be a path to covenants. My understanding is that you're using the=
=20
> > OP_SIZE of the sig to basically decide to verify if the bit is a 0 or a=
=20
> 1,=20
> > then do that verification. You could do the same trick with schnorr=20
> sigs,=20
> > just for 0 bits don't include the sighash_all flag, and for 1 bits=20
> include=20
> > it. This would allow you to get around all the resource limits that=20
> taproot=20
> > lifted. This still should be safe since the the signature commits to if=
=20
> it=20
> > is SIGHASH_DEFAULT vs SIGHASH_ALL. I am not sure if this will enable=20
> very=20
> > complex things or just let you do it on 1 bit of information in=20
> tapscript.
> >
>
> If I'm understanding you right, then what you're signing is your choice
> of sighash flags, rather than anything inherent to the transaction. So I
> don't think this works.
>
> --=20
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
>

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/9e48edb6-1909-4eee-a0c7-48123f42a198n%40googlegroups.com.

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

Hi Ethan,<br /><br />&gt; It sounded like originally you were saying she ca=
n't bump her fee<br />&gt; without double signing, but as you point out ANY=
ONECANPAY or CPFP<br />&gt; let's you do fee bumping without double signing=
. This doesn't seem<br />&gt; different from say a pre-signed bitcoin trans=
action that you can't<br />&gt; change transaction hash of.<br /><br />With=
 lamport signature, the public key is committed in the coin. Once<br />you'=
re spending the coin, the secret key must be revealed to commit to<br />the=
 transaction hash. The secret key cannot be re-used to commit to<br />anoth=
er transaction hash and the spend *in its current state* must be<br />inclu=
ded in the chain.<br /><br />With pre-signed bitcoin transaction under ecds=
a / schnorr, the signer<br />group can change the transaction hash (e.g adj=
ust destination or feerate),<br />assuming "off-chain" interactivity.<br />=
<br />&gt; I don't see the attack. If the point at infinity is forbidden, h=
ow is<br />&gt; this exploited? Wouldn't the attacker's signature just be r=
ejected by<br />&gt; the network?<br /><br />Yes, a pair of ecdsa (r, s) in=
tegers verifying as a point at infinity<br />would be rejected by the netwo=
rk. Assume short r-value that can be guessed<br />by the attacker, the k no=
nce is fixed and the attacker can contribute to<br />the transaction hash. =
Can the attacker contributes to the transaction hash<br />in way the pair o=
f ecdsa (r, s) verifies as a point at infinity ?<br /><br />I don't think t=
he attack works as the private key d is still assume to<br />be secret here=
, and the computational space to find short-r and hash <br />contribution i=
nputs to provoke a point at infinity collision sounds to be huge.<div>Thoug=
h I cannot convince myself without a more fleshed scheme.<br /><br />&gt; I=
f someone discovers a smaller r than used in the signatures, they<br />&gt;=
 would break the existing signatures I agree. Grover's might break P2SH<br =
/>&gt; in general so Bitcoin might be in real trouble at that point.<br /><=
br />I still wonder if you could have tree of such lamport pubkeys, to have=
 more<br />sounds true lamport signature with a 1-to-1 bit mapping between =
transaction<br />bit and lamport secret key bit ? Sounds you will hit conse=
nsus limits. And yeah<br />note Grover's algo could also be used to break p=
roof-of-work mining races,<br />so trouble.<br /><br />&gt; No APO?<br /><b=
r />There is a "faux-ctv" variant I think known by a lot of people, where w=
ith<br />bip118 anyprevout you can have no-input signature committed in the=
 redeem script.<div>A way to have ensure any spending child is a valid pre-=
image of the signature digest.<div><br /></div><div>Best,</div><div>Antoine=
<div><br /></div></div></div></div><div class=3D"gmail_quote"><div dir=3D"a=
uto" class=3D"gmail_attr">Le jeudi 9 mai 2024 =C3=A0 13:49:04 UTC+1, Andrew=
 Poelstra a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); pad=
ding-left: 1ex;">On Wed, May 08, 2024 at 05:31:18PM -0700, Ben Carman wrote=
:
<br>&gt; I think it is possible to get past the 201 op code limit doing it =
in=20
<br>&gt; tapscript. I don&#39;t think it would have the same quantum securi=
ty but could=20
<br>&gt; maybe be a path to covenants. My understanding is that you&#39;re =
using the=20
<br>&gt; OP_SIZE of the sig to basically decide to verify if the bit is a 0=
 or a 1,=20
<br>&gt; then do that verification. You could do the same trick with schnor=
r sigs,=20
<br>&gt; just for 0 bits don&#39;t include the sighash_all flag, and for 1 =
bits include=20
<br>&gt; it. This would allow you to get around all the resource limits tha=
t taproot=20
<br>&gt; lifted. This still should be safe since the the signature commits =
to if it=20
<br>&gt; is SIGHASH_DEFAULT vs SIGHASH_ALL. I am not sure if this will enab=
le very=20
<br>&gt; complex things or just let you do it on 1 bit of information in ta=
pscript.
<br>&gt;
<br>
<br>If I&#39;m understanding you right, then what you&#39;re signing is you=
r choice
<br>of sighash flags, rather than anything inherent to the transaction. So =
I
<br>don&#39;t think this works.
<br>
<br>--=20
<br>Andrew Poelstra
<br>Director, Blockstream Research
<br>Email: apoelstra at <a href=3D"http://wpsoftware.net" target=3D"_blank"=
 rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Df=
r&amp;q=3Dhttp://wpsoftware.net&amp;source=3Dgmail&amp;ust=3D17154822021380=
00&amp;usg=3DAOvVaw2c72oppaPz7rVhVD7lac6w">wpsoftware.net</a>
<br>Web:   <a href=3D"https://www.wpsoftware.net/andrew" target=3D"_blank" =
rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr=
&amp;q=3Dhttps://www.wpsoftware.net/andrew&amp;source=3Dgmail&amp;ust=3D171=
5482202138000&amp;usg=3DAOvVaw20caRMTDSvCaRxBCUZa18a">https://www.wpsoftwar=
e.net/andrew</a>
<br>
<br>The sun is always shining in space
<br>    -Justin Lewis-Webster
<br>
<br></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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/9e48edb6-1909-4eee-a0c7-48123f42a198n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/9e48edb6-1909-4eee-a0c7-48123f42a198n%40googlegroups.com</a>.=
<br />

------=_Part_82595_1310793545.1715396033218--

------=_Part_82594_60687045.1715396033218--