Delivery-date: Fri, 21 Jun 2024 06:22:58 -0700
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.132 as permitted sender) client-ip=185.70.40.132;
Date: Fri, 21 Jun 2024 13:09:58 +0000
To: Eric Voskuil <eric@voskuil.org>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Message-ID: <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
In-Reply-To: <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com> <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> <heKH68GFJr4Zuf6lBozPJrb-StyBJPMNvmZL0xvKFBnBGVA3fVSgTLdWc-_8igYWX8z3zCGvzflH-CsRv0QCJQcfwizNyYXlBJa_Kteb2zg=@protonmail.com> <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_0ULKdmmtEsghf84SYk6JG3bfVPrurwP59DH4vUrehU"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

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

Making 64-bytes transactions invalid is indeed not the most pressing bug fi=
x, but i believe it's still a very nice cleanup to include if such a soft f=
ork ends up being seriously proposed.

As discussed here it would let node implementations cache block failures at=
 an earlier stage of validation. Not a large gain, but still nice to have.

As discussed in the DelvingBitcoin post it would also be a small gain of ba=
ndwidth for SPV verifiers as they wouldn't have to query a merkle proof for=
 the coinbase transaction in addition to the one for the transaction they'r=
e interested in. It would also avoid a large footgun for anyone implementin=
g a software verifying an SPV proof verifier and not knowing the intricacie=
s of the protocol which make such proofs not secure on their own today.

Finally, it would get rid of a large footgun in general. Certainly, unique =
block hashes would be a useful property for Bitcoin to have. It's not far-f=
etched to expect current or future Bitcoin-related software to rely on this=
.

Outlawing 64-bytes transactions is also a very narrow and straightforward c=
hange, with trivial confiscatory effect as any 64-bytes transactions would =
either be unspendable or an anyone-can-spend. Therefore i believe the benef=
its of making them illegal outweigh the costs.

Best,
Antoine

On Thursday, June 20th, 2024 at 6:57 PM, Eric Voskuil <eric@voskuil.org> wr=
ote:

> Right, a fairly obvious resolution. My question is why is that not suffic=
ient - especially given that a similar (context free) check is required for=
 duplicated tx malleability? We'd just be swapping one trivial check (first=
 input not null) for another (tx size not 64 bytes).
>
> Best,
> Eric
> On Tuesday, June 18, 2024 at 7:46:28=E2=80=AFAM UTC-4 Antoine Poinsot wro=
te:
>
>> Hi Eric,
>>
>> It is. This is what is implemented in Bitcoin Core, see [this snippet](h=
ttps://github.com/bitcoin/bitcoin/blob/41544b8f96dbc9c6b8998acd6522200d67cd=
c16d/src/validation.cpp#L4547-L4552) and section 4.1 of the document you re=
ference:
>>
>>> Another check that was also being done in CheckBlock() relates to the c=
oinbase transaction: if the first transaction in a block fails the required=
 structure of a coinbase =E2=80=93 one input, with previous output hash of =
all zeros and index of all ones =E2=80=93 then the block will fail validati=
on. The side effect of this test being in CheckBlock() was that even though=
 the block malleability discussed in section 3.1 was unknown, we were effec=
tively protected against it =E2=80=93 as described above, it would take at =
least 224 bits of work to produce a malleated block that passed the coinbas=
e check.
>>
>> Best,
>> Antoine
>>
>> On Tuesday, June 18th, 2024 at 12:15 AM, Eric Voskuil <er...@voskuil.org=
> wrote:
>>
>>> Hi Antoine,
>>>
>>> Regarding potential malleability pertaining to blocks with only 64 byte=
 transactions, why is not a deserialization phase check for the coinbase in=
put as a null point not sufficient mitigation (computational infeasibility)=
 for any implementation that desires to perform permanent invalidity markin=
g?
>>>
>>> Best,
>>> Eric
>>>
>>> ref: [Weaknesses in Bitcoin=E2=80=99s Merkle Root Construction](https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190225/a27d8=
837/attachment-0001.pdf)
>>
>>> --
>>
>>> You received this message because you are subscribed to the Google Grou=
ps "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an email to bitcoindev+...@googlegroups.com.
>>
>>> To view this discussion on the web visit https://groups.google.com/d/ms=
gid/bitcoindev/72e83c31-408f-4c13-bff5-bf0789302e23n%40googlegroups.com.
>
> --
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googlegroups.com.

--=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/yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_=
-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Making 64-b=
ytes transactions invalid is indeed not the most pressing bug fix, but i be=
lieve it's still a very nice cleanup to include if such a soft fork ends up=
 being seriously proposed.</div><div style=3D"font-family: Arial, sans-seri=
f; font-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif=
; font-size: 14px;">As discussed here it would let node implementations cac=
he block failures at an earlier stage of validation. Not a large gain, but =
still nice to have.</div><div style=3D"font-family: Arial, sans-serif; font=
-size: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-=
size: 14px;">As discussed in the DelvingBitcoin post it would also be a sma=
ll gain of bandwidth for SPV verifiers as they wouldn't have to query a mer=
kle proof for the coinbase transaction in addition to the one for the trans=
action they're interested in. It would also avoid a large footgun for anyon=
e implementing a software verifying an SPV proof verifier and not knowing t=
he intricacies of the protocol which make such proofs not secure on their o=
wn today.<br></div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;">Finally, it would get rid of a large footgun in general. Certainly, =
unique block hashes would be a useful property for Bitcoin to have. It's no=
t far-fetched to expect current or future Bitcoin-related software to rely =
on this.<br></div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;">Outlawing 64-bytes transactions is also a very narrow and straightfor=
ward change, with trivial confiscatory effect as any 64-bytes transactions =
would either be unspendable or an anyone-can-spend. Therefore i believe the=
 benefits of making them illegal outweigh the costs.<br></div><div style=3D=
"font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class=3D"protonmail_signature_block" style=3D"font-family: Arial, sans=
-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton">Best,</div><di=
v class=3D"protonmail_signature_block-proton">Antoine<br></div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><=
div class=3D"protonmail_quote">
        On Thursday, June 20th, 2024 at 6:57 PM, Eric Voskuil &lt;eric@vosk=
uil.org&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            Right, a fairly obvious resolution. My question is why is that =
not sufficient - especially given that a similar (context free) check is re=
quired for duplicated tx malleability? We'd just be swapping one trivial ch=
eck (first input not null) for another (tx size not 64 bytes).<br><br>Best,=
<br>Eric<div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"auto">O=
n Tuesday, June 18, 2024 at 7:46:28=E2=80=AFAM UTC-4 Antoine Poinsot wrote:=
<br></div><blockquote style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div style=3D=
"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-co=
lor:rgb(255,255,255)">Hi Eric,</div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br>=
</div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0=
,0,0);background-color:rgb(255,255,255)">It is. This is what is implemented=
 in Bitcoin Core, see <a data-saferedirecturl=3D"https://www.google.com/url=
?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bitcoin/blob/41544b8f96dbc9c6b8=
998acd6522200d67cdc16d/src/validation.cpp%23L4547-L4552&amp;source=3Dgmail&=
amp;ust=3D1718801575712000&amp;usg=3DAOvVaw1G_CHfl1AktvQeatrhLGHr" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank" title=3D"this snippet" href=
=3D"https://github.com/bitcoin/bitcoin/blob/41544b8f96dbc9c6b8998acd6522200=
d67cdc16d/src/validation.cpp#L4547-L4552">this snippet</a> and section 4.1 =
of the document you reference:</div><blockquote style=3D"border-color:rgb(2=
00,200,200);border-left:3px solid rgb(200,200,200);padding-left:10px;color:=
rgb(102,102,102)"><div style=3D"font-family:Arial,sans-serif;font-size:14px=
;color:rgb(0,0,0);background-color:rgb(255,255,255)"><span>Another check th=
at was also being done in </span><span>CheckBlock() relates to the coinbase=
 transaction: if the first transaction in a </span><span>block fails the re=
quired structure of a coinbase =E2=80=93 one input, with previous output </=
span><span>hash of all zeros and index of all ones =E2=80=93 then the block=
 will fail validation. The </span><span>side effect of this test being in C=
heckBlock() was that even though the block </span><span>malleability discus=
sed in section 3.1 was unknown, we were effectively protected </span><span>=
against it =E2=80=93 as described above, it would take at least 224 bits of=
 work to produce</span><span> a malleated block that passed the coinbase ch=
eck.</span><br></div></blockquote><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></=
div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0=
,0);background-color:rgb(255,255,255)">Best,<br></div><div style=3D"font-fa=
mily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(=
255,255,255)">Antoine<br></div><div></div><div>
        On Tuesday, June 18th, 2024 at 12:15 AM, Eric Voskuil &lt;<a rel=3D=
"noreferrer nofollow noopener" data-email-masked=3D"" href=3D"" target=3D"_=
blank" style=3D"pointer-events: none;">er...@voskuil.org</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            Hi Antoine,<br><br>Regarding potential malleability pertaining =
to blocks with only 64 byte transactions, why is not a deserialization phas=
e check for the coinbase input as a null point not sufficient mitigation (c=
omputational infeasibility) for any implementation that desires to perform =
permanent invalidity marking?<br><br>Best,<br>Eric<div><br></div><div>ref: =
<a data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190225/a27=
d8837/attachment-0001.pdf&amp;source=3Dgmail&amp;ust=3D1718801575712000&amp=
;usg=3DAOvVaw0zeDpkdLLI5wciemjYc3fB" target=3D"_blank" rel=3D"noreferrer no=
follow noopener" href=3D"https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/attachments/20190225/a27d8837/attachment-0001.pdf">Weaknesses in Bitc=
oin=E2=80=99s Merkle Root Construction</a><br></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <br></blockquote></div><div><blockquote type=3D"cite">
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a data-email-masked=3D"" rel=3D"noreferrer nofollow noopener" href=
=3D"" target=3D"_blank" style=3D"pointer-events: none;">bitcoindev+...@goog=
legroups.com</a>.<br></blockquote></div><div><blockquote type=3D"cite">
To view this discussion on the web visit <a data-saferedirecturl=3D"https:/=
/www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitco=
indev/72e83c31-408f-4c13-bff5-bf0789302e23n%2540googlegroups.com&amp;source=
=3Dgmail&amp;ust=3D1718801575712000&amp;usg=3DAOvVaw0GpYuuUIvyElt8EOpe9rzc"=
 target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://gro=
ups.google.com/d/msgid/bitcoindev/72e83c31-408f-4c13-bff5-bf0789302e23n%40g=
ooglegroups.com">https://groups.google.com/d/msgid/bitcoindev/72e83c31-408f=
-4c13-bff5-bf0789302e23n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://groups.=
google.com/d/msgid/bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googl=
egroups.com</a>.<br>

        </blockquote><br>
    </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/yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjP=
lUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-=
2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I%3D%40protonmail.com</a>.<br />

--b1_0ULKdmmtEsghf84SYk6JG3bfVPrurwP59DH4vUrehU--