{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-30\n📝 Original message:The CLEANSTACK rule should be eliminated, and instead the number of items on the stack should be incorporated into the signature hash. That way any script with a CHECKSIG is protected from witness extension malleability, and those rare ones that do not use signature operations can have a “DEPTH 1 EQUALVERIFY” at the end. This allows for much simpler tail-call evaluation as you don’t need to pass arguments on the alt-stack.\n\n\u003e On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e I've put together a first draft for what I hope to be a good next step for \n\u003e Segwit and Bitcoin scripting:\n\u003e    https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki\n\u003e \n\u003e This introduces 5 key changes:\n\u003e \n\u003e 1. Minor versions for witnesses, inside the witness itself. Essentially the \n\u003e witness [major] version 1 simply indicates the witness commitment is SHA256d, \n\u003e and nothing more.\n\u003e \n\u003e The remaining two are witness version 1.0 (major 1, minor 0):\n\u003e \n\u003e 2. As previously discussed, undefined opcodes immediately cause the script to \n\u003e exit with success, making future opcode softforks a lot more flexible.\n\u003e \n\u003e 3. If the final stack element is not exactly true or false, it is interpreted \n\u003e as a tail-call Script and executed. (Credit to Mark Friedenbach)\n\u003e \n\u003e 4. A new shorter fixed-length signature format, eliminating the need to guess \n\u003e the signature size in advance. All signatures are 65 bytes, unless a condition \n\u003e script is included (see #5).\n\u003e \n\u003e 5. The ability for signatures to commit to additional conditions, expressed in \n\u003e the form of a serialized Script in the signature itself. This would be useful \n\u003e in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the \n\u003e whole replay protection argument by introducing it early to Bitcoin before any \n\u003e further splits.\n\u003e \n\u003e This last part is a big ugly right now: the signature must commit to the \n\u003e script interpreter flags and internal \"sigversion\", which basically serve the \n\u003e same purpose. The reason for this, is that otherwise someone could move the \n\u003e signature to a different context in an attempt to exploit differences in the \n\u003e various Script interpretation modes. I don't consider the BIP deployable \n\u003e without this getting resolved, but I'm not sure what the best approach would \n\u003e be. Maybe it should be replaced with a witness [major] version and witness \n\u003e stack?\n\u003e \n\u003e There is also draft code implementing [the consensus side of] this:\n\u003e    https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1\n\u003e \n\u003e Thoughts? Anything I've overlooked / left missing that would be \n\u003e uncontroversial and desirable? (Is any of this unexpectedly controversial for \n\u003e some reason?)\n\u003e \n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}