{"type":"rich","version":"1.0","author_name":"npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","author_url":"https://nostr.ae/npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-09-22\n📝 Original message:\u003e\n\u003e There are other solutions to this problem that could have been taken\n\u003e instead, such as committing to the number of items or maximum size of\n\u003e the stack as part of the sighash data, but cleanstack was the approach\n\u003e taken.\n\n\nThe lack of signed maximum segwit stack size was one of the objections to\nsegwit I presented last year. This together with the unlimited segwit stack\nsize.\n\nHowever, committing to the maximum stack size (in bytes) for an input is\ntricky. The only place where this could be packed is in sequence_no, with a\nsoft-fork. E.g. when transaction version is 2 and and only when lock_time\nis zero.\n\nFor transactions with locktime \u003e0, we could soft-fork so transactions add a\nlast zero-satoshi output whose scriptPub contains OP_RETURN and followed by\nN VarInts, containing the maximum stack size of each input.\nNormally, for a 400 byte, 2-input transaction, this will add 11 bytes, or a\n2.5% overhead.\n\n\n\n\n\n\n\n\n\u003e Arguably for a future script version upgrade one of these other\n\u003e approaches should be taken to allow for shorter tail-call scripts.\n\u003e\n\u003e Mark\n\u003e\n\u003e * Well, almost any. You could end the script with DEPTH EQUAL and that\n\u003e   is a compact way of ensuring the stack is clean (assuming the script\n\u003e   finished with just \"true\" on the stack). Nobody does this however\n\u003e   and burning two witness bytes of every redeem script going forward\n\u003e   as a protective measure seems like an unnecessary ask.\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/cc607dfd/attachment-0001.html\u003e"}