path: root/a0/acb57eb49405bf107efae04d8389acabc2ee9e

Delivery-date: Thu, 27 Jun 2024 05:11:18 -0700
Received: from mail-oo1-f64.google.com ([209.85.161.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+bncBDL4XL646QOBBXNN6WZQMGQE7BFZ6EY@googlegroups.com>)
	id 1sMny9-0004Xg-Nw
	for bitcoindev@gnusha.org; Thu, 27 Jun 2024 05:11:18 -0700
Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-5c21a6f06e0sf2742040eaf.3
        for <bitcoindev@gnusha.org>; Thu, 27 Jun 2024 05:11:17 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1719490271; cv=pass;
        d=google.com; s=arc-20160816;
        b=Obk+Fkcrnrs0VDl64aLUYv2k9YeQROvHSRc12ovHslMWJfDGCnBiuIGbyq31hELF/6
         mX4xBT60EaAuBjmOvfXSt5GwUcQGXyeVtaRUqDvza2NMbgFea26+mvwI56Cj227n0j14
         0ZwZtqglUSHi550PdUHHOm+ftt3SfAqDgU+wnaSLvvNoFQTkpFPoW6OI8d4Np8aHXgRY
         TfGN9fLLjP2YpsOhxrDQ4UWAHFqy4x20qJdpdo94sAMBDh7kONituNXi7jD7KBiQXm2h
         78T8GeRGdV/YzKlvgNFRWKkZ5qfasz/uVKRMm9Bu8ZeCEnOdcnddbCNpimj1VnxFwDOQ
         ltNw==
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=QevQuxI+KIuKhEvbH6Atwq0FLLcd5jlCnWCZb+XUgC8=;
        fh=BpyVFD/EfVg0EL5j8yow51NK8AwmkrclpHTvmI5sksA=;
        b=CktlGhNZgZSN/i9BHlChugpEXo+dJleRTW78vU3vKYYsb5Izb3xEZHHjhfq8LzWQls
         dAisV5SCvxkUrwMvsAeHdJfgWa8l/K9ZnX3smxjfd3tBR/Y0FHrNB792SIf7VNvOauzP
         FBhAYwdR46HL6U+X+kDuR0b9BrhBojIFUnbAlBgjr2m7qSv9M9XgVwzM7Fw424nKN3+T
         OAxX3jHMrLVu8gz7yqcm+6r7FCxvFrF+rDlalAUsl9qjcoAZAPVKs5dPkUtzCaE+RSRQ
         hPV5rTimh+DbaigAQ4C2W5dIA/DTkllR5Aq23sT7XSzYGIXFvKJznYKgIVV8WrhteNU6
         9shg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JI+uBAkP;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.138 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=1719490271; x=1720095071; 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=QevQuxI+KIuKhEvbH6Atwq0FLLcd5jlCnWCZb+XUgC8=;
        b=ZBhRXsgAxmrweBi9EG8uOyZFrj2ZOrrf5gt+Bi+SjJrT4cyxxcI9di5XoYr3M42yjY
         mTXwbhvhYWMMmM1yMuO/HC3Nxu4miZuelkvpSs8pHHsIaYLKdFLfc4SlqbNgUuZwxETw
         pqJPVJn+YmEIo92cs2DIqj8XH89ZwtPFTy8cOhm1jABhYnuPRRaZr1/mt6ZRgIUA/Z8R
         jcwyEKQIezKqY5/hauwhIRCX4Tnk6lkn+MpGFe79MnJfy97In/pBqhXP8z9mmCx1Ir9N
         QmWm91TEb/KKbllIFSSuTTciOAVIwv1CeDNFZ2mhNQvcd4VTSaL3+1kRvGvP8EtEWa4f
         2cCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1719490271; x=1720095071;
        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=QevQuxI+KIuKhEvbH6Atwq0FLLcd5jlCnWCZb+XUgC8=;
        b=YJ6/LReGNxsTETfmLWFQ0kkW7ivSJy2hNvBYPCT3S7LH1Ms1bxMq/91HKiOE0Ys0xn
         uLcBMelte87LdiQJCa86zvHj93QwZbkY7v9EQKl9gLwmcZmJq08ILz+ShyPQLPqCQKGv
         2iLdrUANqxoOYlDOINCovtvmq5Bu6lFwXZxojorviEOO9ZpRav8N++hHB1jlbjwW+EQv
         UAJAkiJnjVs8TyC7hoaKKdTi7j99vriYVD3RrpqG7Eyrl9opiEKNSrjeJtf37EDGSAy2
         hOh0AWfBwyWVLvKy0S/Hz/qv7ysoJhXz1eYat5HKH09texKpX0tD4gNc9wP2tGUbDm/2
         qzxQ==
X-Forwarded-Encrypted: i=2; AJvYcCU/gGb12S9dB2eq3dLYeP0KByIYS4wSO6uNEGjPPVG3f0Q6VZRwY3GjAL116dFa1pE0pWgWQk5+zilD+F6m/BdmEEK5Pr0=
X-Gm-Message-State: AOJu0YzJRlc7mntO14Esp0i7JljRfvtqESStVGOoD3FpV1Ih49M7qGEr
	4j0Hx5iPxJ0eGfpii6OJuL3s6Z+5DE7OkC9m+alOz+mlRZ8SrrCv
X-Google-Smtp-Source: AGHT+IEOL6XI7QWc6wUXGha3bfOWvCUVt/3NxAoB8u4uUNncwgffyY+jFeq1MOao1SxvadKseKF0aA==
X-Received: by 2002:a05:6808:1824:b0:3d5:1f50:188b with SMTP id 5614622812f47-3d543adb0e9mr16954133b6e.23.1719490270583;
        Thu, 27 Jun 2024 05:11:10 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:2cd:b0:444:b60d:daa5 with SMTP id
 d75a77b69052e-444e3002b3fls58585141cf.1.-pod-prod-07-us; Thu, 27 Jun 2024
 05:11:09 -0700 (PDT)
X-Received: by 2002:a05:622a:41c8:b0:446:363c:355f with SMTP id d75a77b69052e-446363c3b0amr1917401cf.6.1719490269166;
        Thu, 27 Jun 2024 05:11:09 -0700 (PDT)
Received: by 2002:a05:620a:35d:b0:79d:5863:c65b with SMTP id af79cd13be357-79d5affc488ms85a;
        Thu, 27 Jun 2024 02:36:06 -0700 (PDT)
X-Received: by 2002:a5d:5712:0:b0:367:3803:e1c4 with SMTP id ffacd0b85a97d-3673803e31cmr1602736f8f.39.1719480963469;
        Thu, 27 Jun 2024 02:36:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1719480963; cv=none;
        d=google.com; s=arc-20160816;
        b=pwd9T182rcE7wMBLt9jhrK2Yir4jsczIJztT4dEzl78fa1mnoK3JCi36nvZ2hIi7wA
         nlNJpKVKZSs7GZ0vXBr4g7aDTzf26Yo/ZpcXpVYWs08T/9rjjOHxnwVgjKp0BBJmtKNU
         zjigFpCEbaaQaz1qYOg0BFsqq/PFzq7p6YlwdyB/vO0Y/HiWoUthGW7+K8MaF3O5S49A
         hvIXCRh12nI52DbM7k1G1woYXUOtZaGqny39TOFLuBzD06Gvf9LPCLRSlDRTG8YZ+p6+
         4hyu23lYD9vPc6yAA40A+UvclQKu77hNoyzGmO3EaLsc7HfU1XzwqiGV/hTvPx5QnbyD
         rScA==
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=I/CmuH7n5oJM1fw8BOa6lOQqlditIYZVFehinDIx7bI=;
        fh=VUyRMGDsLDyKXHBc8DWjokFBiSMTvXavinKdBJZhUls=;
        b=oTUhPdg01NF6t+oYXGVmWDbM7Vn2QLcrKYLRJvlOFD+HqT1TIY+1wNcVKmtUfxvY78
         newT3yV2YzDWZSDLA6+INsmfbQFLYDttuAjDvOWe+4jnMEBwERyUMCK2Q+FCeC7qZeiz
         9LetFLokeuA5DhjONwJK+k4v2GA0jnf6XqX5zeyaD9xrI6eiZnIPlDACqWTe5dsBUOXs
         g3t9sDyQ3ZZoaW05vr3QpYZtASxkZ5LihQ04L2aAnGQbQuvTgmnqFmjEdXlVElYm5csX
         wDSkidwLmTzE6InLcnuJL4uYhuMiGZPNNXGbqC6JXn6uP95BrBDU2s4i8JdplLm+CgzZ
         Q1Mw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JI+uBAkP;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.138 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch. [185.70.40.138])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-3674369efd9si18898f8f.7.2024.06.27.02.36.03
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 27 Jun 2024 02:36:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.138 as permitted sender) client-ip=185.70.40.138;
Date: Thu, 27 Jun 2024 09:35:59 +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: <jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY=@protonmail.com>
In-Reply-To: <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@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> <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com> <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 09bebe8ceb11fe8a4287bb6b47c06fe46b69745b
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_1CgWDOX9rJbJHO7L15t9f9KK006luTO7qO3U6fzgbI"
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=JI+uBAkP;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.40.138 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_1CgWDOX9rJbJHO7L15t9f9KK006luTO7qO3U6fzgbI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> It is not clear to me how determining the coinbase size can be done at an=
 earlier stage of validation than detection of the non-null coinbase.

My point wasn't about checking the coinbase size, it was about being able t=
o cache the hash of a (non-malleated) invalid block as permanently invalid =
to avoid re-downloading and re-validating it.

> It seems to me that introducing an arbitrary tx size validity may create =
more potential implementation bugs than it resolves.

The potential for implementation bugs is a fair point to raise, but in this=
 case i don't think it's a big concern. Verifying no transaction in a block=
 is 64 bytes is as simple a check as you can get.

> And certainly anyone implementing such a verifier must know many intricac=
ies of the protocol.

They need to know some, but i don't think it's reasonable to expect them to=
 realize the merkle tree construction is such that an inner node may be con=
fused with a 64 bytes transaction.

> I do not see this. I see a very ugly perpetual seam which will likely res=
ult in unexpected complexities over time.

What makes you think making 64 bytes transactions invalid could result in u=
nexpected complexities? And why do you think it's likely?

> This does not produce unmalleable block hashes. Duplicate tx hash malleat=
ion remains in either case, to the same effect. Without a resolution to bot=
h issues this is an empty promise.

Duplicate txids have been invalid since 2012 (CVE-2012-2459). If 64 bytes t=
ransactions are also made invalid, this would make it impossible for two va=
lid blocks to have the same hash.

Best,
Antoine
On Monday, June 24th, 2024 at 2:35 AM, Eric Voskuil <eric@voskuil.org> wrot=
e:

> Thanks for the responses Antoine.
>
>> 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 hav=
e.
>
> It is not clear to me how determining the coinbase size can be done at an=
 earlier stage of validation than detection of the non-null coinbase. The f=
ormer requires parsing the coinbase to determine its size, the latter requi=
res parsing it to know if the point is null. Both of these can be performed=
 as early as immediately following the socket read.
>
> size check
>
> (1) requires new consensus rule: 64 byte transactions (or coinbases?) are=
 invalid.
> (2) creates a consensus "seam" (complexity) in txs, where < 64 bytes and =
> 64 bytes are potentially valid.
> (3) can be limited to reading/skipping header (80 bytes) plus parsing 0 -=
 65 coinbase bytes.
>
> point check
>
> (1) requires no change.
> (2) creates no consensus seam.
> (3) can be limited to reading/skipping header (80 bytes) plus parsing 6 -=
 43 coinbase bytes.
>
> Not only is this not a large (performance) gain, it's not one at all.
>
>> It would also avoid a large footgun for anyone implementing a software v=
erifying an SPV proof verifier and not knowing the intricacies of the proto=
col...
>
> It seems to me that introducing an arbitrary tx size validity may create =
more potential implementation bugs than it resolves. And certainly anyone i=
mplementing such a verifier must know many intricacies of the protocol. Thi=
s does not remove one, it introduces another - as there is not only a bifur=
cation around tx size but one around the question of whether this rule is a=
ctive.
>
>> Finally, it would get rid of a large footgun in general.
>
> I do not see this. I see a very ugly perpetual seam which will likely res=
ult in unexpected complexities over time.
>
>> Certainly, unique block hashes would be a useful property for Bitcoin to=
 have. It's not far-fetched to expect current or future Bitcoin-related sof=
tware to rely on this.
>
> This does not produce unmalleable block hashes. Duplicate tx hash malleat=
ion remains in either case, to the same effect. Without a resolution to bot=
h issues this is an empty promise.
>
> The only possible benefit that I can see here is the possible very small =
bandwidth savings pertaining to SPV proofs. I would have a very hard time j=
ustifying adding any consensus rule to achieve only that result.
>
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%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/jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsC=
UusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY%3D%40protonmail.com.

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

<blockquote style=3D"border-color: rgb(200, 200, 200); border-left: 3px sol=
id 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 style=3D"font-family: Ari=
al, sans-serif;">It is not clear to me how determining the coinbase size ca=
n be done at
an earlier stage of validation than detection of the non-null coinbase.</sp=
an><br></div></blockquote><div style=3D"font-family: Arial, sans-serif; fon=
t-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; col=
or: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><span style=3D"fon=
t-family: Arial, sans-serif;">My point wasn't about checking the coinbase s=
ize, it was about being able to cache the hash of a (non-malleated) invalid=
 block as permanently invalid to avoid re-downloading and re-validating it.=
</span><br></div><br><blockquote style=3D"border-color: rgb(200, 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: 1=
4px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><span styl=
e=3D"font-family: Arial, sans-serif;">It seems to me that introducing an ar=
bitrary tx size validity may create more potential implementation bugs than=
 it resolves.</span></div></blockquote><div style=3D""><br></div><div style=
=3D""><span style=3D"font-family: Arial, sans-serif; font-size: 14px; font-=
weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Th=
e potential for implementation bugs is a fair point to raise, but in this c=
ase i don't think it's a big con</span><span style=3D"font-family: Arial, s=
ans-serif; font-size: 14px; font-weight: 400; color: rgb(0, 0, 0); backgrou=
nd-color: rgb(255, 255, 255);">cern. Verifying no transaction in a block is=
 </span><span style=3D"font-family: Arial, sans-serif; font-size: 14px; fon=
t-weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">=
64 bytes is as simple a check as you can get.</span></div><div style=3D""><=
span style=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight:=
 400; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></spa=
n></div><blockquote style=3D"border-color: rgb(200, 200, 200); border-left:=
 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102=
);"><div style=3D""><span style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px; font-weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, =
255, 255);"><span style=3D"font-family: Arial, sans-serif;">And certainly a=
nyone implementing such a verifier must know many intricacies of the protoc=
ol.</span><span><br></span></span></div></blockquote><div style=3D""><span =
style=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight: 400;=
 color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></span></d=
iv><div style=3D""><span style=3D"font-family: Arial, sans-serif; font-size=
: 14px; font-weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, 2=
55, 255);">They need to know some, but i don't think it's reasonable to exp=
ect them to realize the merkle tree construction is such that an inner node=
 may be confused with a 64 bytes transaction.</span></div><div style=3D""><=
span style=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight:=
 400; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></spa=
n></div><blockquote style=3D"border-color: rgb(200, 200, 200); border-left:=
 3px solid rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102=
);"><div style=3D""><span style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px; font-weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, =
255, 255);">I do not see this. I see a very ugly perpetual seam which will =
likely result in unexpected complexities over time.</span><span style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px; font-weight: 400; color: rgb=
(0, 0, 0); background-color: rgb(255, 255, 255);"><br></span></div></blockq=
uote><div style=3D""><br></div><div style=3D""><span style=3D""><span style=
=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight: 400; colo=
r: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">What makes you thin=
k making 64 bytes transactions invalid could result in unexpected complexit=
ies? And why do you think it's likely?</span></span></div><div style=3D""><=
span style=3D""><span style=3D"font-family: Arial, sans-serif; font-size: 1=
4px; font-weight: 400; color: rgb(0, 0, 0); background-color: rgb(255, 255,=
 255);"><br></span></span></div><blockquote style=3D"border-color: rgb(200,=
 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 10px; =
color: rgb(102, 102, 102);"><div style=3D""><span style=3D""><span style=3D=
"font-family: Arial, sans-serif; font-size: 14px; font-weight: 400; color: =
rgb(0, 0, 0); background-color: rgb(255, 255, 255);">This does not produce =
unmalleable block hashes. Duplicate tx hash
malleation remains in either case, to the same effect. Without a
resolution to both issues this is an empty promise.</span><span style=3D"fo=
nt-family: Arial, sans-serif; font-size: 14px; font-weight: 400; color: rgb=
(0, 0, 0); background-color: rgb(255, 255, 255);"><br></span></span></div><=
/blockquote><div style=3D""><br></div><div style=3D""><span style=3D"font-f=
amily: Arial, sans-serif;">Duplicate txids have been invalid since 2012 (</=
span><span style=3D"font-family: Arial, sans-serif;">CVE-2012-2459</span><s=
pan style=3D"font-family: Arial, sans-serif;">).</span><span style=3D""><sp=
an style=3D"font-family: Arial, sans-serif;"> If 64 bytes transactions are =
also made invalid, this would make it impossible for two valid blocks to ha=
ve the same hash.</span></span></div><div style=3D""><span style=3D""><span=
 style=3D"font-family: Arial, sans-serif;"><br></span></span></div><div sty=
le=3D""><span style=3D""><span style=3D"font-family: Arial, sans-serif;">Be=
st,<br>Antoine<br></span><span style=3D""></span></span></div><div class=3D=
"protonmail_quote">
        On Monday, June 24th, 2024 at 2:35 AM, Eric Voskuil &lt;eric@voskui=
l.org&gt; wrote:<br>
        <blockquote type=3D"cite" class=3D"protonmail_quote">
            Thanks for the responses Antoine.<br><br>&gt;  As discussed her=
e it would let node implementations cache block failures at an earlier stag=
e of validation. Not a large gain, but still nice to have.<br><br>It is not=
 clear to me how determining the coinbase size can be done at an earlier st=
age of validation than detection of the non-null coinbase. The former requi=
res parsing the coinbase to determine its size, the latter requires parsing=
 it to know if the point is null. Both of these can be performed as early a=
s immediately following the socket read.<br><br>size check<br><br>(1) requi=
res new consensus rule: 64 byte transactions (or coinbases?) are invalid.<b=
r>(2) creates a consensus "seam"  (complexity) in txs, where &lt; 64 bytes =
and &gt; 64 bytes are potentially valid.<br>(3) can be limited to reading/s=
kipping header (80 bytes) plus parsing 0 - 65 coinbase bytes.<br><br>point =
check<br><br>(1) requires no change.<br>(2) creates no consensus seam.<br>(=
3) can be limited to reading/skipping header (80 bytes) plus parsing 6 - 43=
 coinbase bytes.<br><br>Not only is this not a large (performance) gain, it=
's not one at all.<br><br>&gt; It would also avoid a large footgun for anyo=
ne implementing a software verifying an SPV proof verifier and not knowing =
the intricacies of the protocol...<br><br>It seems to me that introducing a=
n arbitrary tx size validity may create more potential implementation bugs =
than it resolves. And certainly anyone implementing such a verifier must kn=
ow many intricacies of the protocol. This does not remove one, it introduce=
s another - as there is not only a bifurcation around tx size but one aroun=
d the question of whether this rule is active.<br> <br>&gt; Finally, it wou=
ld get rid of a large footgun in general. <br><br>I do not see this. I see =
a very ugly perpetual seam which will likely result in unexpected complexit=
ies over time.<br><br>&gt; Certainly, unique block hashes would be a useful=
 property for Bitcoin to have. It's not far-fetched to expect current or fu=
ture Bitcoin-related software to rely on this.<br><br>This does not produce=
 unmalleable block hashes. Duplicate tx hash malleation remains in either c=
ase, to the same effect. Without a resolution to both issues this is an emp=
ty promise.<br><br>The only possible benefit that I can see here is the pos=
sible very small bandwidth savings pertaining to SPV proofs. I would have a=
 very hard time justifying adding any consensus rule to achieve only that r=
esult.<br><br>Best,<br>Eric<br><span style=3D"font-family: Arial, sans-seri=
f;"><br></span>

<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 target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"m=
ailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a target=3D"_blank" rel=3D"norefe=
rrer nofollow noopener" href=3D"https://groups.google.com/d/msgid/bitcoinde=
v/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.com">https://groups.=
google.com/d/msgid/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%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/jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_=
WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCU=
usnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY%3D%40protonmail.com</a>.<br />

--b1_1CgWDOX9rJbJHO7L15t9f9KK006luTO7qO3U6fzgbI--