š
Original date posted:2017-09-19
š Original message:> On Sep 18, 2017, at 8:09 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for transferring
>> arguments to the policy script.
>
> Isn't this a bug in the cleanstack rule?
Well in the sense that "cleanstack" doesn't do what it says, sure.
However cleanstack was introduced as a consensus rule to prevent a
possible denial of service vulnerability where a third party could
intercept any* transaction broadcast and arbitrarily add data to the
witness stack, since witness data is not covered by a checksig.
Cleanstack as-is accomplishes this because any extra items on the
stack would pass through all realistic scripts, remaining on the stack
and thereby violating the rule. There is no reason to prohibit extra
items on the altstack as those items can only arrive there
purposefully as an action of the script itself, not a third party
malleation of witness data. You could of course use DEPTH to write a
script that takes a variable number of parameters and sends them to
the altstack. Such a script would be malleable if those extra
parameters are not used. But that is predicated on the script being
specifically written in such a way as to be vulnerable; why protect
against that?
There are other solutions to this problem that could have been taken
instead, such as committing to the number of items or maximum size of
the stack as part of the sighash data, but cleanstack was the approach
taken. Arguably for a future script version upgrade one of these other
approaches should be taken to allow for shorter tail-call scripts.
Mark
* Well, almost any. You could end the script with DEPTH EQUAL and that
is a compact way of ensuring the stack is clean (assuming the script
finished with just "true" on the stack). Nobody does this however
and burning two witness bytes of every redeem script going forward
as a protective measure seems like an unnecessary ask.
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-07 18:05:38
in reply to nevent1qā¦yxl0
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 18:05:38Event JSON
{
"id": "1d2fa798b7fe7dd71862db979ba2853bff9e9e7d31521a600703fbd8ab1544ac",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686161138,
"kind": 1,
"tags": [
[
"e",
"2a468f3688518e7a7f729ce11aaac86d8191608db6d8228100ef68169ab48586",
"",
"root"
],
[
"e",
"061310e631f6e45eb7a281884dc1f3c629604c3f7ae8ef20bb80ed9e5acfd07b",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "š
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.",
"sig": "6f2fbcb124d0cb686c6450c7bd6a5dbb88a918f766c92aedcfafe9a57639d85e29b44164eedab084725a400119d812c18185eec88379f9ccee7fd80de782bb3c"
}