Delivery-date: Sun, 23 Jun 2024 18:19:05 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sLYMK-0004Z7-Nc for bitcoindev@gnusha.org; Sun, 23 Jun 2024 18:19:05 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e0268d49b6dsf7695798276.2 for ; Sun, 23 Jun 2024 18:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1719191938; x=1719796738; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=; b=Vc+rDXd6VCde6paRlf9i6jlwIPzAEeU8Zw7pZHUWSxcgIzbev/1yyOvD89PtjmU4Bz noGI1CysDJPgHY11RRXfvUU88yBhMuqST8l/0jFEiD+umnRIFWfVUaZJLK1LuUURmOB7 LBM73M7yS6LEx4vbNfhi5EO2SPwbiNydl074NDOCmOJ5DkuoY0OfofVKZwC7tXv7Y1rX uDBtep8ERVV0asfOwQs/AhSzOH/jgY1CayQjuOvj2iDsvCxqyi7OEnjtI8CnlqeO6Tjx X11k6JnALYHp4a6EZnTvuTEa8mNNpYUa5erDu9YYA316RNuDCVHImeSBMJooHooRySqB ABRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1719191938; x=1719796738; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=; b=IBUJ6WP00bYKnYrQYzap4dxXRg0ailpZoCR8tlz7UDKD61w9UI5Mg+2Q4t/01S/k9K RdJ1IhlwYtiaBaGH/VxMkq3iRaqO8QurEFbmKL0Ec5LclMM694b9vrc2PWJXkHQ4vvGk R30IXcETDY6FqChYX2cyFeCNqIRbWcJ8uKxTtyjjfT6xYQTfBQyzMvHhF3QLtQ783TGc 4tN2ex+b9rQeHQcmQCFcG/u8RDGsANKw5Bz09DkHTTDb1GJCnJBSqimUORjX9nIISkjy 60gRK7Jw9KZOr5mR2akrSwFXmDkDldvm/JqtmGOb1sCEJ6+I2D5hnb7eNXYJISc9IGlc ej0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719191938; x=1719796738; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=Cv0/0BuasHf11tabwyztJoV3QitL8PqzUkXPeh7NRvw=; b=dpQYWff94PVRXsX3r7MjTXDTZ4b+8avvvts6J5KJ8X5k27te9ecueTJxgXvoJ1ng2B FtG13a3HROQfLMt4/DUvOfR/FZc3xAdNogFxyOsGIW565OFSofG2d3ty6RCR76jd8u9A 7NBApgwAgISzDpMIgkvW8xXURMFLCj5JpdLPsbHIMn1voEJj87AyiCeQi1IAOvl2b1WK ZkNOBKzj1XaAgDIG98ClslqUZY7NlqoOjWMRfBrf/HvD7u7ZSHrJQhte/W1pERD/72tr 9q73wpFFh/dbzS4cq8jtfUtHrpWYR0Roe+eeuLRfzSq5QbDiAxR0Dc5M/M8+4IgivDFy urTw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWHSO1bVtblO5T3oYlSqOWaFoH98eNcXTnjYqE1MIL+WMHiWFsV/dxapyx0tXkt33Ddp6WbuO2Q04gZ2sD9TjnA6IL75R0= X-Gm-Message-State: AOJu0Yz8Pe5nInHPtWx8tUNHQW7G37KudhqAKyvTuRx6b8S/TP35adt8 fiu5+g9NOtbi7Hb7N1V3Qvqq1mGGqJvl6iS4rzNE7eSxvsTXVSTS X-Google-Smtp-Source: AGHT+IHh+EPg2QB+4TLegFk/m5u4yleEENpvp9+n1XOcYVcHQdDDGUarOEARlqTBEP7eprzB31SDPg== X-Received: by 2002:a25:6b41:0:b0:df4:d91d:74a7 with SMTP id 3f1490d57ef6-e0304007dc0mr3016301276.45.1719191937647; Sun, 23 Jun 2024 18:18:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1895:b0:dff:34c9:92f8 with SMTP id 3f1490d57ef6-e02d0ac0766ls5977524276.0.-pod-prod-05-us; Sun, 23 Jun 2024 18:18:56 -0700 (PDT) X-Received: by 2002:a05:690c:6e0d:b0:62c:67f4:4f5 with SMTP id 00721157ae682-643ae44f5e5mr2390177b3.9.1719191936182; Sun, 23 Jun 2024 18:18:56 -0700 (PDT) Received: by 2002:a05:690c:4605:b0:627:7f59:2eee with SMTP id 00721157ae682-6413a4f66e0ms7b3; Sun, 23 Jun 2024 17:35:31 -0700 (PDT) X-Received: by 2002:a05:690c:7001:b0:62c:c5ea:66ad with SMTP id 00721157ae682-643ab54d839mr4222117b3.4.1719189330473; Sun, 23 Jun 2024 17:35:30 -0700 (PDT) Date: Sun, 23 Jun 2024 17:35:30 -0700 (PDT) From: Eric Voskuil To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <72e83c31-408f-4c13-bff5-bf0789302e23n@googlegroups.com> <5b0331a5-4e94-465d-a51d-02166e2c1937n@googlegroups.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_258520_191179190.1719189330256" X-Original-Sender: eric@voskuil.org 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: -0.7 (/) ------=_Part_258520_191179190.1719189330256 Content-Type: multipart/alternative; boundary="----=_Part_258521_1966216055.1719189330256" ------=_Part_258521_1966216055.1719189330256 Content-Type: text/plain; charset="UTF-8" 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 have. 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 former requires 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 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 verifying an SPV proof verifier and not knowing the intricacies of the protocol... It seems to me that introducing an arbitrary tx size validity may create more potential implementation bugs than it resolves. And certainly anyone implementing such a verifier must know many intricacies of the protocol. This does not remove one, it introduces another - as there is not only a bifurcation around tx size but one around the question of whether this rule is active. > 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 result 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 software to rely on this. 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. 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 justifying 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/msgid/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.com. ------=_Part_258521_1966216055.1719189330256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the responses Antoine.

> =C2=A0As discussed here i= t would let node implementations cache block failures at an earlier stage o= f validation. Not a large gain, but still nice to have.

It is no= t clear to me how determining the coinbase size can be done at an earlier s= tage of validation than detection of the non-null coinbase. The former requ= ires parsing the coinbase to determine its size, the latter requires parsin= g 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 i= nvalid.
(2) creates a consensus "seam" =C2=A0(complexity) in txs, wher= e < 64 bytes and > 64 bytes are potentially valid.
(3) can be li= mited to reading/skipping header (80 bytes) plus parsing 0 - 65 coinbase by= tes.

point check

(1) requires no change.
(2) cre= ates 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 wou= ld also avoid a large footgun for anyone implementing a software verifying = an SPV proof verifier and not knowing the intricacies of the protocol...
It seems to me that introducing an arbitrary tx size validity may = create more potential implementation bugs than it resolves. And certainly a= nyone implementing such a verifier must know many intricacies of the protoc= ol. This does not remove one, it introduces another - as there is not only = a bifurcation around tx size but one around the question of whether this ru= le is active.
=C2=A0
> Finally, it would get rid of a large fo= otgun in general.

I do not see this. I see a very ugly perpetua= l seam which will likely result in unexpected complexities over time.
=
> Certainly, unique block hashes would be a useful property for Bi= tcoin to have. It's not far-fetched to expect current or future Bitcoin-rel= ated software to rely on this.

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.<= br />
The only possible benefit that I can see here is the possible ve= ry small bandwidth savings pertaining to SPV proofs. I would have a very ha= rd time justifying adding any consensus rule to achieve only that result.
Best,
Eric

--
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/msg= id/bitcoindev/be78e733-6e9f-4f4e-8dc2-67b79ddbf677n%40googlegroups.com.=
------=_Part_258521_1966216055.1719189330256-- ------=_Part_258520_191179190.1719189330256--