Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-11 📝 Original message:On Sun, Dec 9, 2018 at ...
📅 Original date posted:2018-12-11
📝 Original message:On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012 at 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)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181211/1f119c76/attachment.html>;
📝 Original message:On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012 at 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)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181211/1f119c76/attachment.html>;