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