> On 12 Dec 2018, at 6:50 AM, Russell O'Connor <rocon...@blockstream.io> wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2...@xbt.hk > <mailto:jl2...@xbt.hk>> wrote: > The current proposal is that a 64-byte signature will be used for the default > “signing all” sighash, and 65-byte for other sighash types. The space saved > will allow a few more txs in a block, so I think it worths doing. However, > this also makes witness weight estimation more difficult in multisig cases. > > This idea of signing witness weight has been brought up before. I think the > concern is the difficulty to estimate the witness weight for complex scripts, > which need this feature most. So it will work when it is not needed, and will > not work when it is needed. > > Is there any script example that witness size malleability is unavoidable? > > I tend to think in opposite terms. Is there a proof that any script can be > transformed into an equivalent one that avoids witness weight malleability? > But I admit there is a trade off: If we don't allow for signature covers > weight, and we do need it, it will be too late to add. On the other hand if > we add signature covers weight, but it turns out that no Script ever needs to > use it, then we've added that software complexity for no gain. However, I > think the software complexity is relatively low, making it worthwhile. > > Moreover, even if witness weight malleability is entirely avoidable, it > always seems to come at a cost. Taking as an example libwally's proposed " > <https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2" > Script > <https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>, > it begins with "OP_DEPTH OP_1SUB OP_1SUB" spending 3 vbytes to avoid any > possible witness malleability versus just taking a witness stack item to > determine the branch, costing 1 or 2 (unmalleated) vbytes. Now to be fair, > under Taproot this particular script's witness malleability problem probably > goes away. Nonetheless, I think it is fair to say that Bitcoin Script was > designed without any regard given to scriptSig/witness malleability concerns > and the result is that one is constantly fighting against malleability > issues. Short of a wholesale replacement of Bitcoin Script, I do think that > having an option for signature covers weight is one of the best ways to > address the whole problem. > > Regarding your point about 64/65-byte signatures; I speculate that in most > protocols, all parties that are able to consider signing the weight, know > what sighash flags the other parties are expected to be using. However, your > point is well-taken, and if we choose to adopt the option of signatures > covering weight, we ought to make sure there exists a 65-byte signature that > performs the equivalent of a sigHashAll (of course, still covering that > particular sighash flag under the signature), to ensure that > anti-weight-malleability can be use even when the sighash flags that other > parties will use are unknown. Even with the extra vbytes in the signatures, > there may be a net weight savings by avoiding the need for anti-malleability > Script code. (It might also be reasonable to have participants create > signatures for a small range of different weight values? (Sorry in advance to > PSBT)).
I think the root cause of witness weight malleability is some opcodes accept variable size input (without affecting the output), and that input is provided by the puzzle solver. Going through the opcode list, I think such opcodes include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all arithmetic opcode that accepts CScriptNum (including CHECKMULTISIG) VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be the first opcode to interact with data directly provided by the puzzle solver. CHECKMULTISIG is fixed by BIP147. For the key number and sig number, they should be part of the script, so not malleable. DEPTH is a problem only if its inputs are not later examined by other opcodes. Again, this is pointless. The liberally example should be protected by the MINIMAL_IF policy, which requires the input of OP_IF be minimal. As you note, OP_IF could be replaced by taproot in many cases Non-minimal CScriptNum is also banned as BIP62 policy. For the purpose of preventing malicious third party witness bloating, all we need is the miners to enforce the policy. There is no reason for miners to accept size malleated txs, as that will reduce the usable block space. If they hate a tx, they would simply drop it, instead of wasting the block space.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
