{"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-01\n📝 Original message:On Sun, Oct 1, 2017 at 3:27 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e \u003e On Oct 1, 2017, at 12:05 PM, Russell O'Connor \u003croconnor at blockstream.io\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e Given the proposed fixed signature size, It seems better to me that we\n\u003e create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.\n\u003e\n\u003e For what benefit? If your script actually uses all the items on the stack,\n\u003e and if your script is not written in such a way as to allow malleability\n\u003e (which cannot be prevented in general), then they’re equivalent. Using\n\u003e weight instead of depth only needlessly restricts other parties to select a\n\u003e witness size up-front.\n\u003e\n\nCreating a Bitcoin script that does not allow malleability is difficult and\nrequires wasting a lot of bytes to do so, typically when handling issues\naround non-0-or-1 witness values being used with OP_IF, and dealing with\nnon-standard-zero values, etc.  Adding a witness weight flag cuts through\nthe worst of all this, and makes script design enormously simpler and makes\nscripts smaller and cheaper.\n\n\n\u003e And to be clear, signing witness weight doesn’t mean the witness is not\n\u003e malleable. The signer could sign again with a different ECDSA nonce. Or if\n\u003e the signer is signing from a 2-of-3 wallet, a common scenario I hope, there\n\u003e are 3 possible key combinations that could be used. If using MBV, a\n\u003e 3-element tree is inherently unbalanced and the common use case can have a\n\u003e smaller proof size.\n\u003e\n\u003e Witnesses are not 3rd party malleable and we will maintain that property\n\u003e going forward with future opcodes.\n\u003e\n\u003e \u003e Mark, you seem to be arguing that in general we still want weight\n\u003e malleability even with witness depth fixed, but I don't understand in what\n\u003e scenario we would want that.\n\u003e\n\u003e Any time all parties are not online at the same time in an interactive\n\u003e signing protocol, or for which individual parties have to reconfigure their\n\u003e signing choices due to failures. We should not restrict our script\n\u003e signature system to such a degree that it becomes difficult to create\n\u003e realistic signing setups for people using best practices (multi-key, 2FA,\n\u003e etc.) to sign. If I am a participant in a signing protocol, it would be\n\u003e layer violating to treat me as anything other than a black box, such that\n\u003e internal errors and timeouts in my signing setup don’t propagate upwards to\n\u003e the multi-party protocol.\n\u003e\n\u003e For example, I should be able to try to 2FA sign, and if that fails go\n\u003e fetch my backup key and sign with that. But because it’s my infrequently\n\u003e used backup key, it might be placed deeper in the key tree and therefore\n\u003e signatures using it are larger. All the other signers need care is that\n\u003e slot #3 in the witness is where my Merkle proof goes. They shouldn’t have\n\u003e to restart and resign because my proof was a little larger than anticipated\n\u003e — and maybe they can’t resign because double-spend protections!\n\u003e\n\nI'll argue that I don't want my counter-party going off and using a very\ndeeply nested key in order to subvert the fee rate we've agreed upon after\nI've signed my part of the input.  If we are doing multi-party signing of\ninputs we need to communicate anyways to construct the transaction.  I see\nno problem with requiring my counter-party to choose their keys before I\nsign so that I know up front what our fee rate is going to be.  If they\nlose their keys and need a backup, they should have to come back to me to\nresign in order that we can negotiate a new fee rate for the transaction\nand who is going to be covering how much of the fee and on which inputs.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171001/a587d6ba/attachment.html\u003e"}