topic: describe consensus cleanup #2643
Conversation
murchandamus
force-pushed
the
2026-02-describe-consensus-cleanup
branch
from
cd44e58 to
c4ac1f9
Compare
murchandamus
force-pushed
the
2026-02-describe-consensus-cleanup
branch
from
c4ac1f9 to
58a5b83
Compare
| transactions are prevented by introducing limits on signature operations | ||
| that curb this malicious use but far exceed organic uses. | ||
| - Merkle tree weakness: the construction of the merkle tree on a block’s | ||
| transactions is ambiguous membership of transactions with stripped sizes of |
There was a problem hiding this comment.
"is ambiguous membership of transactions" reads weird
There was a problem hiding this comment.
Oops, I forgot a word in rephrasing.
darosior
left a comment
darosior
left a comment
There was a problem hiding this comment.
Some nits. Looks good overall. Impressive conciseness skills.
|
Thanks for the review, @darosior. I made changes based on your suggestions. Please let me know what you think, if you have a chance. |
|
Thanks @murchandamus! I pushed some changes to improve the formatting and work in related topic links to the new text. |
| - **Time warp bug**: an [off-by-one error][topic time warp] in the difficulty adjustment algorithm | ||
| permits a majority hashrate attacker to arbitrarily increase block cadence. | ||
| This is mitigated by limiting the permitted timestamps for the first block | ||
| in difficulty periods and requiring that at an entire difficulty period has |
There was a problem hiding this comment.
I think
| in difficulty periods and requiring that at an entire difficulty period has | |
| in difficulty periods and requiring that an entire difficulty period has |
| - **Merkle tree weakness**: the construction of the merkle tree on a block’s | ||
| transactions treats transactions with witness-stripped sizes of | ||
| 64 bytes indistinguishably from inner nodes. Forbidding such transactions prevents two ways of | ||
| creating [fake transaction inclusion proofs][topic merkle tree vulnerabilities]. |
There was a problem hiding this comment.
For the record technically one way allows to forge an inclusion proof and the other only allows to malleate a valid blocks into an invalid one, but i think it's fine. Maybe if you want to be more technically accurate at the expense of being less immediately clear about the impact, you could say "two ways of malleating the content of a valid block".
There was a problem hiding this comment.
Thanks, I went with “two ways of misrepresenting the content of a valid block”.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks for the formatting update and the review. I fixed the extraneous word and the imprecision.
| - **Merkle tree weakness**: the construction of the merkle tree on a block’s | ||
| transactions treats transactions with witness-stripped sizes of | ||
| 64 bytes indistinguishably from inner nodes. Forbidding such transactions prevents two ways of | ||
| creating [fake transaction inclusion proofs][topic merkle tree vulnerabilities]. |
There was a problem hiding this comment.
Thanks, I went with “two ways of misrepresenting the content of a valid block”.
3 participants
I took a stab at providing a few more details in the the Consensus Cleanup description.