{"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-19\n📝 Original message:\u003e On Sep 18, 2017, at 8:09 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \n\u003e On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev \n\u003e wrote:\n\u003e\u003e After the main discussion session it was observed that tail-call semantics\n\u003e\u003e could still be maintained if the alt stack is used for transferring\n\u003e\u003e arguments to the policy script.\n\u003e \n\u003e Isn't this a bug in the cleanstack rule?\n\nWell in the sense that \"cleanstack\" doesn't do what it says, sure.\n\nHowever cleanstack was introduced as a consensus rule to prevent a\npossible denial of service vulnerability where a third party could\nintercept any* transaction broadcast and arbitrarily add data to the\nwitness stack, since witness data is not covered by a checksig.\n\nCleanstack as-is accomplishes this because any extra items on the\nstack would pass through all realistic scripts, remaining on the stack\nand thereby violating the rule. There is no reason to prohibit extra\nitems on the altstack as those items can only arrive there\npurposefully as an action of the script itself, not a third party\nmalleation of witness data. You could of course use DEPTH to write a\nscript that takes a variable number of parameters and sends them to\nthe altstack. Such a script would be malleable if those extra\nparameters are not used. But that is predicated on the script being\nspecifically written in such a way as to be vulnerable; why protect\nagainst that?\n\nThere are other solutions to this problem that could have been taken\ninstead, such as committing to the number of items or maximum size of\nthe stack as part of the sighash data, but cleanstack was the approach\ntaken. Arguably for a future script version upgrade one of these other\napproaches should be taken to allow for shorter tail-call scripts.\n\nMark\n\n* Well, almost any. You could end the script with DEPTH EQUAL and that\n  is a compact way of ensuring the stack is clean (assuming the script\n  finished with just \"true\" on the stack). Nobody does this however\n  and burning two witness bytes of every redeem script going forward\n  as a protective measure seems like an unnecessary ask."}