Re: [bitcoin-dev] Version 1 witness programs (first draft)

[Mark Friedenbach <mark@friedenbach.org>]

> On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor@blockstream.io> wrote:
> 
> Creating a Bitcoin script that does not allow malleability is difficult and requires wasting a lot of bytes to do so, typically when handling issues around non-0-or-1 witness values being used with OP_IF, and dealing with non-standard-zero values, etc.

Script validation flags of the correct place to do this. We already have policy validation flags that check for these things. They were not made consensus rules with Segwit v0 mainly due to concern over scope creep in an already large overhaul, of my memory is correct. Script versions and quadratic hashing fixes where the minimum necessary to allow segwit to activate safely while still enabling future upgrades that would otherwise have been hard forks. We knew that we would be later changing the EC signature scheme to be something that supported signature aggregation, and that would be more appropriate time to discuss such changes. As we are considering to do now (although witness versions means we don’t need to omnibus the script upgrade here either, so a v1 before signature aggregation is ready is fine IMHO).

In any case if there is any general witness malleability due to opcode semantics that it’s not fixed by one of our existing policy flags, that is a bug and I would encourage you to report it.
> I'll argue that I don't want my counter-party going off and using a very deeply nested key in order to subvert the fee rate we've agreed upon after I've signed my part of the input.  If we are doing multi-party signing of inputs we need to communicate anyways to construct the transaction.  I see no problem with requiring my counter-party to choose their keys before I sign so that I know up front what our fee rate is going to be.  If they lose their keys and need a backup, they should have to come back to me to resign in order that we can negotiate a new fee rate for the transaction and who is going to be covering how much of the fee and on which inputs.

Arguing that every single user should be forced to restart an interactive signing session. That’s a very strong statement based on something that I would say is a preference that depends on circumstances.

What about an optional commitment to witness size in bytes? The value zero meaning “I don’t care.” I would argue that it should be a maximum however, and therefor serialized as part of the witness. The serialization of this would be very compact (1 plus the difference between actual and maximum, with zero meaning not used.)