From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 21 Jun 2024 06:22:58 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sKeED-0002yr-RX for bitcoindev@gnusha.org; Fri, 21 Jun 2024 06:22:58 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-6f9a12fae6dsf1979993a34.3 for ; Fri, 21 Jun 2024 06:22:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718976172; cv=pass; d=google.com; s=arc-20160816; b=dHvSVYx807w7rQFMu04TdqA9wZs2GrAXW6SllxBxuvTHycAmE9Fb8IrlhkrtJuhDFB nVRjHVV3lqO90gj5C7DhEFRxRe3ULMg3U/aI2YBHTnXZpEk3Z0XzX7321GUh2nk10RX2 ZqfXlytfHLDsC5yYJ441z4cJo/Pgu+bN7VKLxK/4VGrdRh4g1AjcFyJ3m54QdDZLRvSy pUyCGCx0XmfjUY0w2tbFnsdoxwCs52KutJCxJGNxzQDDPxObYIX78arL4tGIBUjfBjJg bnecL4LXjPXm0CkOwFZLUn51Yh+1Jth5butDDng11VP6XUIN6T0Lpr4TA9DJtjMrAaN1 TmOg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=PlQNxAZ5oDtTw4IhwlD9eltS2AvySeLDqmdxB3BDhOI=; fh=7PlZUnjgz1cZV0cHPjDESz+TWXaypRy8/BRLB3EUM1c=; b=Opy5eor9jnq9ORep8R97i9OS2SSrmtRswX7zWt1xh5KU3qyaj4YXm2vpZxr2ePRiaq n2OJ1c3NYrX4ASSuWB6zg0rckM8Fo0iGxd+FKl3yJil9CxAqAu/IAwxIacj9MaYfQ5XA OdsLG/qqxcOuogryk2QNPKZ1C2+xPbtT7us+hj7z88f5UCAROm+9l09xfmNGysMvdz4n vXjLMr+BWmdTSR6mcMhCsTx0fOQ0VU1TzaD3bvd24NQh/UMQOtSAVVFTkbZupjzPbKL1 l2yFCSGKiqLJ4wcO+Cy8GdTAxc+7nWXBTitk1AUVjlH78hVx23DM45YPVxXUGEG6Krgz YjBQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=htzenAcI; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1718976172; x=1719580972; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=PlQNxAZ5oDtTw4IhwlD9eltS2AvySeLDqmdxB3BDhOI=; b=gfTU251VP/ctJnfhcVmVCrS/XLPLHzpF5ukV3IdVLqYe8gJizrn3XOXh7s5tuvv+Aq /wXp5A6JSpdPTDq9t9wncEeDojyfl3SjM9256uhfIZgIk+KcMkmc933fSazGMJK8X0f+ +6liZSRagW3/Epsvc/VSXHs43F98tv0YyBKKrQikdAQWS0BD60pYs9zeGJUGxjN0oxow lbSipps3iP/v9vWS4J0D5KiLDN20B6xGOqoMNqT/JOAv37QJvAg0CoM9+8pg6yLB1OsZ CIvthajqp1cQ4B4S0MG9lHBCjbAairBEVI56StA+u3w1rvlHyIiFWbbKYlaJ9rhCgHKN O/Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718976172; x=1719580972; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PlQNxAZ5oDtTw4IhwlD9eltS2AvySeLDqmdxB3BDhOI=; b=En5Pvz5UJUKU6oNVuJlC4tcYi5OVVDFtVj5eWQx9bAK+9VRs8B+xe4ezleSIVLBI9S 9J7ELyLmkjMCW9jFfUXFJjWjCidgSVDso20m7BRENrvAHWFTeChR/T1hsLQ5gHT4podB ZBm7Kdqpi+JVlmgXfmnKu0euEkgK2/un1/hnmHcdtujbtKnW4LmFqxAgjWlvKV/JkUdo 6G4PCyZzAwUwdEhBgLxzdsIppq8JKVw6GmosReuf90MpvZsCI2LnV8n41J5oEwq07it5 ViUqZGrvbByEjj7prTpTtyLjnz688TbwbpN2hSApdFkwHC1lnouXVEasxRFYFI4KokBN YVuQ== X-Forwarded-Encrypted: i=2; AJvYcCWSHAUNFxW7lbRF+FbOKZ2vaIvT1dN1QjRItxxsxGf0pFIMOo9x4xV4tx6B8vLcbbuowcmQcghMuxcRgrqRtSY2FejW6B4= X-Gm-Message-State: AOJu0YwukTLEz1b2SM14csfgIlET0LTrRJWfJHZr0R0oPLU8YlCYVhnO Nxb6KPhJdec4MjzT0HqKcE+1ulRCngVCgnU/ADrsVvomTEa+hgIA X-Google-Smtp-Source: AGHT+IHcyrHqd6LKUNkRyHQA2k949cb58oah7GZo7s+dwQeDl1dBrwOwduHiyCUInQYVTw9TtdPbwA== X-Received: by 2002:a9d:5f07:0:b0:6f9:e049:e11f with SMTP id 46e09a7af769-700739448d7mr8576210a34.9.1718976171542; Fri, 21 Jun 2024 06:22:51 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:3b82:b0:6b0:8c6c:833b with SMTP id 6a1803df08f44-6b50ff15984ls20224516d6.0.-pod-prod-08-us; Fri, 21 Jun 2024 06:22:50 -0700 (PDT) X-Received: by 2002:a05:6214:4521:b0:6b0:8e22:b57c with SMTP id 6a1803df08f44-6b501eda61cmr3469816d6.11.1718976170081; Fri, 21 Jun 2024 06:22:50 -0700 (PDT) Received: by 2002:a05:620a:4493:b0:795:58a6:42ec with SMTP id af79cd13be357-79bcdd0032fms85a; Fri, 21 Jun 2024 06:10:06 -0700 (PDT) X-Received: by 2002:a5d:464a:0:b0:35f:28eb:5a46 with SMTP id ffacd0b85a97d-363170ed434mr8157634f8f.10.1718975404862; Fri, 21 Jun 2024 06:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1718975404; cv=none; d=google.com; s=arc-20160816; b=rTkwq4ymbxp7pnDYLHUHg8G0q5OpuclaBrLLQ8MXCd4heBw7qjsolif+PGz5vsNoAE RmVtMCdHKN3GEeu7lbcnEw+C707npojXfhDeyxRwuOy47skFjfhtgmEfHntn6NOv0fwC ZsKTqOLEeTMK9fgAaiPpCb/d13dO5S9PywJ3tDQYvlSCWXWfPUrnQRZvfKsx/pB+Aqp+ KU6DlRz17I6rORvHYFta/SQiGRYOZ4GCgM1OulyYe2NaVKU6jkK2viGnQWcfptoq5vIE hUUN3GRCXaqdWYjLDkUS0P7blcfpihx1BoowpNQxrVqCGQG2kjBzdH37SYzd74JbTZoc AL5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=UsmQ6GxZp6K+IZIX9DicBkpAUnPAuOMmxey0KMSAnHg=; fh=VUyRMGDsLDyKXHBc8DWjokFBiSMTvXavinKdBJZhUls=; b=j6RvXHbllb45UjOG6DPAWpqr3IuHidEi6biNIOPhfoqmzz2gsaeubQnyzKfGmUdKYJ tIxCBXwS1cUmX/VSWBToVZxJ4UcFBMT2BMBBmWMIzOs/2vQpDvfK4WmyRwLlF5e+YETc OzdpoR5+iae/MoOzZJNTpniCb5ZFMZeATZ9Oh1QtB21ePxbJHWc55L/UlVAEodgGVejw rQZIIwMWdXCWG79TpYm2HWkdDlI5CKshcIBmKXMwUGog9oWDnfR69c/Rhb7rgb3o5yDL dGmDFim3eoRtT3AotJauoVqi5v7AlAuw2bQ8qDBMP8jbZYseAaEGIv3DGVgdahebqjWb DVOg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=htzenAcI; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch. [185.70.40.132]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4247194de3bsi6028625e9.0.2024.06.21.06.10.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jun 2024 06:10:04 -0700 (PDT) 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 From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival Message-ID: In-Reply-To: <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com> References: <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 8940a86c135c24bb9b189c0d1cc9f6631fd44e3f MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_0ULKdmmtEsghf84SYk6JG3bfVPrurwP59DH4vUrehU" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=htzenAcI; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) 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 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 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
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.

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.

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.

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.

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.

=20
=20
Best,
Antoine

<= div class=3D"protonmail_quote"> On Thursday, June 20th, 2024 at 6:57 PM, Eric Voskuil <eric@vosk= uil.org> wrote:
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).

Best,=
Eric
O= n Tuesday, June 18, 2024 at 7:46:28=E2=80=AFAM UTC-4 Antoine Poinsot wrote:=
Hi Eric,

=
It is. This is what is implemented= in Bitcoin Core, see this snippet and section 4.1 = of the document you reference:
Another check th= at was also being done in CheckBlock() relates to the coinbase= transaction: if the first transaction in a block fails the re= quired 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 validation. The side effect of this test being in C= heckBlock() was that even though the block malleability discus= sed in section 3.1 was unknown, we were effectively 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 coinbase ch= eck.

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 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?

Best,
Eric

--
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+...@goog= legroups.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 e= mail to bitcoindev+unsubscribe@googl= egroups.com.
To view this discussion on the web visit https://groups.= google.com/d/msgid/bitcoindev/5b0331a5-4e94-465d-a51d-02166e2c1937n%40googl= egroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/b= itcoindev/yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-= 2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I%3D%40protonmail.com.
--b1_0ULKdmmtEsghf84SYk6JG3bfVPrurwP59DH4vUrehU--