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 ) 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 ; 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 (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 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: References: <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> <5b0331a5-4e94-465d-a51d-02166e2c1937n@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 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_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 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
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.
<= br>
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.=

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

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 concern. Verifying no transaction in a block is= = 64 bytes is as simple a check as you can get.
<= 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);">
And certainly a= nyone implementing such a verifier must know many intricacies of the protoc= ol.

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 style=3D"font-family: Arial, sans-serif; font-size: 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.

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 style=3D"">
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.
<= /blockquote>

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

Be= st,
Antoine
On Monday, June 24th, 2024 at 2:35 AM, Eric Voskuil <eric@voskui= l.org> wrote:
Thanks for the responses Antoine.

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

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.

size check

(1) requi= res 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/s= kipping 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 anyo= ne implementing a software verifying an SPV proof verifier and not knowing = the intricacies of the protocol...

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.

> Finally, it wou= ld get rid of a large footgun in general.

I do not see this. I see = a very ugly perpetual seam which will likely result in unexpected complexit= ies over time.

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

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.

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.

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+unsubscribe@googl= egroups.com.
To view this discussion on the web visit https://groups.= google.com/d/msgid/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%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/jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCU= usnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY%3D%40protonmail.com.
--b1_1CgWDOX9rJbJHO7L15t9f9KK006luTO7qO3U6fzgbI--