A 3-of-3 that turns into a 2-of-3 after 90 days

[kanishk779]

I had a doubt about the bitcoin script encoded from the miniscript of the above mentioned spending policy. The below is output generated by the current policy compiler.

<key_1> OP_CHECKSIG OP_SWAP <key_2> OP_CHECKSIG OP_ADD OP_SWAP <key_3>
OP_CHECKSIG OP_ADD OP_SWAP OP_DUP OP_IF
<a032> OP_CHECKSEQUENCEVERIFY OP_VERIFY
OP_ENDIF
OP_ADD 3 OP_EQUAL

Why do we need the last OP_ADD ?

I assume the stack state before running this script to be as follows (the first element is on top of the stack)

<sig1> <sig2> <sig3> <some_number>

at this point, I also don't understand what this some_number should be. Does it act like true-false, or is the sequence number of the transaction? If it is not true or false, the last OP_ADD operation looks invalid to me.

I referred this BIP which explains the working for CSV. Also, I assumed that the successful execution of CSV will act as a NOP (as mentioned in the above BIP).

[apoelstra]

@kanishk779 this is a pretty cool construction. It took me a bit to reverse-engineer what Miniscript is doing here but it is correct:

First, we have this CHECKSIG ADD SWAP idiom, which takes an accumulator, adds the result of CHECKSIG (which will be 0 if the signature failed or 1 if it passed), and then moves it one space back in the stack to make room for the next signature. After each of these, the second-to-top stack element will contain a count of how many signatures have passed, and the top stack element will be a witness for the next check.

After several of these we have the construction DUP IF <timelock check> ENDIF. This takes as witness either a 0 or 1. If it's a 0 the whole block is skipped and 0 is left on the stack; if it's a 1 then the timelock is checked and a 1 is left on the stack. As you observe, the CSV doesn't affect the stack at all; instead the DUP IF block is what leaves the "result" on the stack.

The final ADD takes this 0 or 1 and adds it to the accumulator, and then 3 EQUAL checks that exactly 3 of the preceding checks passed.

[apoelstra]

I just noticed the second VERIFY in the output. This looks like a bug. What program did you get this output from?

[darosior]

@apoelstra

I just noticed the second VERIFY in the output. This looks like a bug.

How so? I think the Script here is a thresh(3,c:pk_k(key_1),sc:pk_k(key_2),sc:pk_k(key_3),sdv:older(a032)), and the VERIFY (v:) is needed to use the d: wrapper with older().
Also note how if the CSV passes the VERIFY will always pass as the argument to older() must always be >=1.

[kanishk779]

@apoelstra your answer makes sense. So the some_number I was talking about initially is the witness that you mention, which will be either 1 or 0. This wiki describes the OP_CSV opcode as :

Marks transaction as invalid if the relative lock time of the input (enforced by BIP 0068 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP 0112.

I have got this output from the official miniscript website.
By second VERIFY I assume you mean OP_VERIFY after the OP_CSV which itself contains a verify .
So according to me the second OP_VERIFY just removes the value from the top of the stack (since we know it will be positive value we just pushed on the stack for the OP_CSV, the <a032> in our case). Instead of that we can also use the DROP operation, as described in BIP 0112.

[apoelstra]

Yep, I see. I forgot that CSV VERIFY was the correct idiom, because of course CSV can't pop its own value from the stack.

[apoelstra]

By the way -- thank you very much for filing this issue. In studying your script I found a serious security issue in Miniscript (see #360 for more info) which we were able to fix over the last 24 hours.