Given the proposed fixed signature size, It seems better to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.

Mark, you seem to be arguing that in general we still want weight malleability even with witness depth fixed, but I don't understand in what scenario we would want that.

It strikes me that is most scenarios all parties signing an input would do so after an execution path through the script has been agreed upon by all parties, in which case the witness weight can be fixed.
In rare cases where the smart contract requires that some parties sign in advance of the decision about the execution path (for example, I'm thinking about delegation here, but I want to keep my remarks general), we wouldn't want to fix the witness depth either.

A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would modify the transaction's fee/weight priority (at least for that one input), and greatly reduce the overall attack surface of witness malleability issues.

On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Clean stack should be eliminated for other possible future uses, the most obvious of which is recursive tail-call for general computation capability. I’m not arguing for that at this time, just arguing that we shouldn’t prematurely cut off an easy implementation of such should we want to. Clean stack must still exist as policy for future soft-fork safety, but being a consensus requirement was only to avoid witness malleability, which committing to the size of the witness also accomplishes.

Committing to the number of witness elements is fully sufficient, and using the number of elements avoids problems of not knowing the actual size in bytes at the time of signing, e.g. because the witness contains a merkle proof generated by another party from an unbalanced tree, and unbalanced trees are expected to be common (so that elements can be placed higher in the tree in accordance with their higher expected probability of usage). Other future extensions might also have variable-length proofs.

> On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke@dashjr.org> wrote:
>
> Should it perhaps commit to the length of the serialised witness data instead
> or additionally? Now that signatures are no longer variable-length, that'd be
> possible...
>
> As far as tail-call needs are concerned, CLEANSTACK wouldn't have been checked
> until AFTER the tail-call in the first draft. But I suppose eliminating it for
> other possible future purposes is still useful.
>
> Luke

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev