BIP 54: clarify 64-byte transactions item description and rationale#2159
Conversation
As Eric points out on the mailing list: 1. the rationale section should mention and address the "seam" objection directly rather than burying it in a footnote; 2. the full node consensus split issue should not be used as sole rationale for invalidating 64-byte txs (but it's fair to point out it's fixed as a nice to have byproduct). ML thread: https://gnusha.org/pi/bitcoindev/43996cb3-9133-4627-8944-5fe08427be68n@googlegroups.com/T/#md66e252f0748f4ef7569d5e15d42631e12b66c0b,
jonatack
added
the
BIP Update by Owner
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
LGTM. Perhaps @JeremyRubin or @evoskuil could take a look?
|
Alright, i went further into rewriting the rationale. I removed the description of the source of malleability (inner node / leaf node) since it is already discussed in the motivation. I focused on discussing arguments in favour of the invalidation, and objections / alternatives. I relegated the discussion of the caching consensus bug to a footnote, since really it is largely orthogonal to this proposal. |
|
Since this rule is about reducing the complexity of SPV verification, the motivation should detail what that is. Presently its only described as a marginal reduction in complexity that requires a mitigation. Reading this fresh my first question would be, what specifically is the complexity/mitigation that this new rule will eliminate. I provided that high level description in the resolved comments above. How else can people weigh the tradeoff being proposed: new consensus rule or existing mitigation. I'm not taking a position on that question, but that is the question and should be presented clearly. |
|
I think really the issue is that SPV verifiers need to know a mitigation is necessary in the first place. Invalidating 64-byte transactions remove this footgun at the protocol level, so that applications do not have to care / know about it. This is what is stated in the motivation:
|
|
That's fine, but it's an opinion on a tradeoff. The actual mitigation that is being replaced should be described with sufficient detail for people to make an informed decision. One could also raise the real possibility that a specific size transaction being invalid is also a footgun, as transaction creation (and validation) must avoid it. |
|
I know of at least three mitigations: request an additional Merkle proof for the coinbase transaction and compare depths, reject proofs with inner nodes that deserialize to a Bitcoin transaction, and use modified Merkle proofs (request the preimage of the second SHA256, instead of the result of the double-SHA256). Each have their own tradeoffs, but they all have one thing in common: they are hacks to get around the root cause that the existence of 64-byte transactions make regular Merkle proofs insecure and implementers have to know about it. |
|
Also, this is not an opinion on a tradeoff. This is a fact: invalidating 64-byte transactions removes the need to know that a mitigation is necessary, and the cost of implementing it. |
There is no harm in presenting all three, and any others. I chose a simple one that requires no change to existing server behaviors (which is therefore presumably already in use).
This is an opinion. The objective here is to lay out the option, not to impose a preference or to lead people to it. Others may believe that the issue here is the imposition of a new consensus rule, with its own costs, in order to simplify SPV implementation. |
|
Re-reading, I'll admit to being initially confused if the word "mitigation," as used in this BIP, is referring to the same thing throughout (fixes proposed by the BIP), and where not, propose using a different term (or vice versa). |
|
Rephrased my use of mitigation for the currently available SPV verifier workarounds, and added a footnote that lists all three along with a link to a detailed discussion for each. |
Jon pointed that i use "mitigation" to refer both to the items of this BIP, and for the existing workarounds to make SPV verifiers safe in the presence of 64-byte txs. This commit rephrases the latter usage.
darosior
force-pushed
the
2505_64b_clarifications_and_rationale
branch
2 times, most recently
from
72d8275 to
f1f1c36
Compare
Agree. |
ariard
left a comment
ariard
left a comment
There was a problem hiding this comment.
generally i agree with jeremy to be careful with the "seam" introduced.
| tree depth in the header's version field[^8], which would make one workaround for a known | ||
| vulnerability easier to deploy. The authors believe it is preferable to address the root cause by | ||
| invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to | ||
| rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes |
There was a problem hiding this comment.
"or even know one is necessary in the first place"
i think this is considering only one viewpoint of the discussion, namely in my understanding the fact that for a SPV verifier with the new 64-byte witness-stripped serialized size transaction rejection rule, there is no more necessary knowledge of the vulnerability in itself or the mitigation. this is correct for consensus validation purpose of chain data.
i don't think it's true for any class of usage leveraging pre-signed transactions among multi-party. for this class of usage, where a transaction malleable by a party with competing interest might have to be cached by a client, the software client for sanity purpose has a clear design requirement to now implement the new rejection rule. while it was indeed a matter of policy check and not consensus ones, failing to do so already provoked issues in the past for some lightning implem (e.g CVE-2020-26895).
so i don't think the statement is correct when it's saying the "users do not have to know about the vulnerability or its workaround in the first place". if you've a software client caching pre-signed transactions on top of a SPV client (e.g bip157 + lightning) carefulness about not accepting a transaction input vector turning the result as a 64 byte tx will become necessary, at least in my opinion. e.g influencing the multi-party tx size by playing on the ECDSA signature size.
4 participants
A recent ML post pointed that not repeating across the BIP how the witness-stripped serialized size is considered for 64-byte transactions invalidation was confusing to some people. This makes the text a bit heavier, but in this PR we change two places to spell it out explicitly, in addition to the preexisting specifications section. Another modification was requested in the ML post, which i believe is incorrect and have responded to there.
A response on that same ML thread requested the rationale section to be clearer as to the motivation for invalidating 64-byte transactions. In particular, the point that it introduces a "seam" that may be surprising should be discussed and addressed in the main section instead of a footnote. Also, it should be clarified that full node consensus failure cannot be the main motivation for invalidating 64-byte transactions since it is better addressed alternatively. Both are done in the second commit of this PR.