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 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 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 intricacies 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 confused with a 64 bytes transaction.
I do not see this. I see a very ugly perpetual seam which will likely result in unexpected complexities over time.
What makes you think making 64 bytes transactions invalid could result in unexpected complexities? And why do you think it's likely?
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.
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 have the same hash.
Best,
Antoine
On Monday, June 24th, 2024 at 2:35 AM, Eric Voskuil <eric@voskuil.org> wrote:
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.
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/jJLDrYTXvTgoslhl1n7Fk9-pL1mMC-0k6gtoniQINmioJpzgtqrJ_WqyFZkLltsCUusnQ4jZ6HbvRC-mGuaUlDi3kcqcFHALd10-JQl-FMY%3D%40protonmail.com.