{"type":"rich","version":"1.0","author_name":"npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","author_url":"https://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-10-02\n📝 Original message:On Sun, Oct 1, 2017 at 4:39 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e\n\u003e \u003e On Oct 1, 2017, at 12:41 PM, Russell O'Connor \u003croconnor at blockstream.io\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e Creating a Bitcoin script that does not allow malleability is difficult\n\u003e and requires wasting a lot of bytes to do so, typically when handling\n\u003e issues around non-0-or-1 witness values being used with OP_IF, and dealing\n\u003e with non-standard-zero values, etc.\n\u003e\n\u003e Script validation flags of the correct place to do this. We already have\n\u003e policy validation flags that check for these things. They were not made\n\u003e consensus rules with Segwit v0 mainly due to concern over scope creep in an\n\u003e already large overhaul, of my memory is correct. Script versions and\n\u003e quadratic hashing fixes where the minimum necessary to allow segwit to\n\u003e activate safely while still enabling future upgrades that would otherwise\n\u003e have been hard forks. We knew that we would be later changing the EC\n\u003e signature scheme to be something that supported signature aggregation, and\n\u003e that would be more appropriate time to discuss such changes. As we are\n\u003e considering to do now (although witness versions means we don’t need to\n\u003e omnibus the script upgrade here either, so a v1 before signature\n\u003e aggregation is ready is fine IMHO).\n\u003e\n\nScript validation isn't the correct place to do this.  The reason is that\nscript operations are not aware of whether the stack items they are\nprocessing are witness malleable items or Script computed values.  Let me\ntake OP_IF as one example.  When OP_IF operates directly on witness data,\nit is subject to witness malleability, and therefore one needs to add extra\ncode around that to prevent witness malleability.  On the other hand, when\nOP_IF operates on computed data, it isn't subject to malleability and can\nsafely process non-zero-or-one values. If OP_IF were restricted to\nrequiring canonical inputs, then for the cases that OP_IF operates on\ncomputed data, they will need to add extra code to canonicalize their\ninputs.  I don't think there is a correct answer here.  That is because I\nbelieve this isn't the correct place to aim to restrict witness\nmalleability.\n\nOTOH, signatures are a fine place to aim to restrict witness malleability.\nIn fact, if signatures could securely cover all witness data, I think\neveryone here would jump at the opportunity to implement that.  However,\nsince that isn't known to be possible, we are left with doing the best we\ncan, which is to have signatures cover weight (or bytes).  This prevents\nthe worst effects of witness malleability and does so without burdening\nScript development.  (This also requires signatures have a fixed size, so\nit is understandable that signature-covers-weight wasn't included in Segwit\nv0 scripts).\n\n\n\u003e In any case if there is any general witness malleability due to opcode\n\u003e semantics that it’s not fixed by one of our existing policy flags, that is\n\u003e a bug and I would encourage you to report it.\n\u003e \u003e I'll argue that I don't want my counter-party going off and using a very\n\u003e deeply nested key in order to subvert the fee rate we've agreed upon after\n\u003e I've signed my part of the input.  If we are doing multi-party signing of\n\u003e inputs we need to communicate anyways to construct the transaction.  I see\n\u003e no problem with requiring my counter-party to choose their keys before I\n\u003e sign so that I know up front what our fee rate is going to be.  If they\n\u003e lose their keys and need a backup, they should have to come back to me to\n\u003e resign in order that we can negotiate a new fee rate for the transaction\n\u003e and who is going to be covering how much of the fee and on which inputs.\n\u003e\n\u003e Arguing that every single user should be forced to restart an interactive\n\u003e signing session. That’s a very strong statement based on something that I\n\u003e would say is a preference that depends on circumstances.\n\u003e\n\u003e What about an optional commitment to witness size in bytes? The value zero\n\u003e meaning “I don’t care.” I would argue that it should be a maximum however,\n\u003e and therefor serialized as part of the witness. The serialization of this\n\u003e would be very compact (1 plus the difference between actual and maximum,\n\u003e with zero meaning not used.)\n\n\nI would be fine your suggestion above, though I think Luke's suggestion of\nhaving both SIGHASH_WITNESS_SIZE and SIGHASH_WITNESS_DEPTH flag is better\nbecause it is simpler.\n\nThose people worried about restarting interactive signing session in the\nunlikely event of parties not knowing what keys they are planning to use\ncan use just the SIGHASH_WITNESS_DEPTH flag.  Those people worried about\ncounterparties fiddling with fee rates can use both flags.  The choice\ndoesn't even need to be made at script commitment time.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171002/36c4797d/attachment.html\u003e"}