From: Eric Voskuil <eric@voskuil•org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Date: Sun, 23 Jun 2024 17:35:30 -0700 (PDT) [thread overview]
Message-ID: <be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com> (raw)
In-Reply-To: <yt1O1F7NiVj-WkmnYeta1fSqCYNFx8h6OiJaTBmwhmJ2MWAZkmmjPlUST6FM7t6_-2NwWKdglWh77vcnEKA8swiAnQCZJY2SSCAh4DOKt2I=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2780 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 3281 bytes --]
next prev parent reply other threads:[~2024-06-24 1:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 18:10 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-03-26 19:11 ` [bitcoindev] " Antoine Riard
2024-03-27 10:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-03-27 18:57 ` Antoine Riard
2024-04-18 0:46 ` Mark F
2024-04-18 10:04 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-04-25 6:08 ` Antoine Riard
2024-04-30 22:20 ` Mark F
2024-05-06 1:10 ` Antoine Riard
2024-06-17 22:15 ` Eric Voskuil
2024-06-18 8:13 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-18 13:02 ` Eric Voskuil
2024-06-21 13:09 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-24 0:35 ` Eric Voskuil [this message]
2024-06-27 9:35 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-06-28 17:14 ` Eric Voskuil
2024-06-29 1:06 ` Antoine Riard
2024-06-29 1:31 ` Eric Voskuil
2024-06-29 1:53 ` Antoine Riard
2024-06-29 20:29 ` Eric Voskuil
2024-06-29 20:40 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be78e733-6e9f-4f4e-8dc2-67b79ddbf677n@googlegroups.com \
--to=eric@voskuil$(echo .)org \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox