path: root/ca/0db13aa9321f69d30fa0f7aa2372021b08adb6

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 <bitcoindev+bncBDL4XL646QOBBKX52WZQMGQEW3CAS7Q@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <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
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 <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -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 <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--