is there any research about UTXOs that are not spendable without a fork?

[BrewMaster]

every node keeps a database of the chain's state that contains the transaction outputs that are not yet spent. but among these outputs there are some that can not be spent unless a fork changes the script rules.
i am wondering whether anyone has ever looked into this to see what percentage of them are unspendable. i am guessing it shouldn't be that high due to standard rules.

edit: here are two examples to understand what i'm talking about:
txid:outindex

Code:

6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8:0
OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG

result of HASH160 is 20 bytes and it will never be an "empty byte" or OP_0 so this script must always fail.

Code:

6e2c9ece8a7c29e81adfd03bc4c4914812107236fa42038d8e8013063f3d1af8:1
OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH

there is no OP_ENDIF anywhere after OP_IF

[1715122772]

1715122772

[1715122772]

1715122772

[1715122772]

1715122772

[DaCryptoRaccoon]

This topic might have some info in it that would shed some light on the TX's you have put above.

From what I see they were MTGOX coins.

From the old post it seems there was talk about pruning them or having a fork then re-introducing them into the supply both of which would not go well for bitcoin imo.

Any attempt to manipulate the supply or re-introduce lost or locked out coins would be a terrible idea for bitcoin.

Thought at the time I think they were worth around the 10k mark and worth a lot more in today's terms  I doubt the community would back such a plan.

https://bitcointalk.org/index.php?topic=671881.0

[BrewMaster]

to be clear the question is not about what we do with them but just about finding them.

since it was mentioned. another problem with pruning such outputs (apart from breaking immutability is that sometimes forks could change the way scripts work and make an unspendable script spendable or vise versa. for example take this output:

Code:

b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d:1
142a9bc5447d664c1d0141392a842d23dba45c4f13b175
2a9bc5447d664c1d0141392a842d23dba45c4f13 OP_CHECKLOCKTIMEVERIFY OP_DROP

this was a perfectly valid script at the time it was spent but it is invalid today.

[aliashraf]

there is no OP_ENDIF anywhere after OP_IF

Not sure, but I think OP_ENDIF is not exactly mandatory unlike the case with conventional scripting languages and there is a chance for such scripts to pass.

[gmaxwell]

i am wondering whether anyone has ever looked into this to see what percentage of them are unspendable. i am guessing it shouldn't be that high due to standard rules.

Andytoshi wrote a static analysis tool that was sound but incomplete... it would find scripts that could never be satisified, e.g. because of types/length mismatched.

IIRC other than those large MTGOX outputs there wasn't a whole lot more.  There is a large number of low value ones created by a p2pool bug and a smattering of other things.

While standardness might have helped, the big reason you don't find any is because people don't like throwing their coins away!

[BrewMaster]

there is no OP_ENDIF anywhere after OP_IF

Not sure, but I think OP_ENDIF is not exactly mandatory unlike the case with conventional scripting languages and there is a chance for such scripts to pass.

as far as i can tell from the source code, whenever any of these "ifs" are executed they must end with an OP_ENDIF otherwise the script evaluation will fail hence these output scripts can not be spent with existing consensus rules.

[aliashraf]

there is no OP_ENDIF anywhere after OP_IF

Not sure, but I think OP_ENDIF is not exactly mandatory unlike the case with conventional scripting languages and there is a chance for such scripts to pass.

as far as i can tell from the source code, whenever any of these "ifs" are executed they must end with an OP_ENDIF otherwise the script evaluation will fail hence these output scripts can not be spent with existing consensus rules.

Not exactly true. The input script is processed sequentially:
There is no pre-processing. When the processor encounters OP_IF it checks the value (boolean) on top of the stack if it is False (0) it ignores the next statement(s) up to a breakpoint and if it is not FALSE (any value other than 0), it continues executing the statements up to the next breakpoint, in both cases, we remember that we are in IF-Block-Processing mode and in the latter case reaching to a breakpoint means meeting one of the following conditions:

1- An Error occurs.

2- The script ends and the result is to be found on the top of the stack as a boolean. (surprise!)

3- An OP_ElSE is fetched. Now that we are processing a satisfied IF statement, we behave just like when there is a FLASE on top of the stack: ignoring the script up to the next breakpoint.

4- An OP_ENDIF is fetched: NOW we will end our IF-Block-Processing mode and go normal. For the sake of not triggering an error and failing, we need TO BE in IF-Block-Processing mode, hence a matching IF/NOT_IF clause should be under processing right now.

For nested IF clauses we do everything recursively.

From this, one could conclude that OP_IF can proceed without a matching OP_ENDIF! The opposite is not true tho, OP_ENDIF would fail without a matching OP_IF/OP_NOT_IF being visited already.

[BrewMaster]

From this, one could conclude that OP_IF can proceed without a matching OP_ENDIF! The opposite is not true tho, OP_ENDIF would fail without a matching OP_IF/OP_NOT_IF being visited already.

that doesn't sound right to me at all. according to any sources that i have ever read, OP_IFs can not exist without the closing argument (OP_ENDIF) and although i am not the best at reading core's source but it also confirms that.

every IF pushes a bool value in a vector (vfExec) that OP_ENDIF removes. that means if we have an OP_IF whether it has true or false it will put an item in that vector.
then the last line of evaluation when everything is done and over, will check if that vector is empty and if it weren't it means OP_ENDIF didn't run and fails the script evaluation:
https://github.com/bitcoin/bitcoin/blob/2b9a4a13324ac3f0adf712d01fb8f2ba914cdc8f/src/script/interpreter.cpp#L1144-L1145

[aliashraf]

From this, one could conclude that OP_IF can proceed without a matching OP_ENDIF! The opposite is not true tho, OP_ENDIF would fail without a matching OP_IF/OP_NOT_IF being visited already.

that doesn't sound right to me at all. according to any sources that i have ever read, OP_IFs can not exist without the closing argument (OP_ENDIF) and although i am not the best at reading core's source but it also confirms that.

every IF pushes a bool value in a vector (vfExec) that OP_ENDIF removes. that means if we have an OP_IF whether it has true or false it will put an item in that vector.
then the last line of evaluation when everything is done and over, will check if that vector is empty and if it weren't it means OP_ENDIF didn't run and fails the script evaluation:
https://github.com/bitcoin/bitcoin/blob/2b9a4a13324ac3f0adf712d01fb8f2ba914cdc8f/src/script/interpreter.cpp#L1144-L1145

You are right, I just checked the code. At the end, ScriptVerify function, it checks the conditional flow control stack to be empty. I overlooked that.