Bitcoin Forum

I'm working on a wallet solution to use 2/3 multisig with timelock.

A and B can spend the UTXO together before the timelock, but C can only spend the UTXO with A or B after the timelock expires.

So I wrote the script as below, is it correctly implemented as the requirement?


Thank you

Looks correct to me but you can always test things like this on the TestNet (https://en.bitcoin.it/wiki/Testnet) to be more sure, specially when it comes to setting the time value in the timelock.
Also what you called "OP_PUSHNUM_2" and "OP_PUSHNUM_1" should be OP_2 and OP_1 respectively with 0x52 and 0x51 as their byte representations.

Thank you, the bitcoin-cli script ASM is


I used the number 2 and 1, not OP_2 or OP_1, as I understand from the tutorial https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/10_4_Scripting_a_Multisig.md#create-a-raw-multisig

According to this tutorial https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/11_3_Using_CSV_in_Scripts.md#create-a-csv-relative-time

I calculated the relative lock time of 1 hour as below


But one thing confused me is the miniscript sample https://bitcoin.sipa.be/miniscript/

For 90 days, it uses 12960 in miniscript, and the compiled sequence is a032, that's too small a number.

For the nSequence value in the miniscript example, it's using relative block number instead of time, that's why it's such a small number.

very impressive.
But can people tell all the spend conditions from the blockchain?

taproot? what wallet can send coins from taproot addresses to others?

In the timelock branch:


You would have to put C's signature in the last cosigner of the output in order for the script to work properly, correct?

Other than that, this script looks well-formed to me.


Sparrow Wallet can do that. I think maybe Bitcoin Core can do that now too, because Ordinals claim to use that feature. And it's always possible to construct Taproot transactions with spend paths by hand if you are sufficiently masochist  :)

Yes, when timelock expired, to spend the output with key_C, the script is like


Is this correct?

I think no wallets support real custom scripting yet, at least Bitcoin Core is only able to watch those custom script address, can't spend from them.

Bitcoin Core supports custom script with output descriptors, that's the miniscript from blockstream, it has full capability to support all popular opcodes. But still, most of output descriptors support in Bitcoin Core are limited to watch only, the core devs have some ongoing issues to solve this.

https://github.com/bitcoin/bitcoin/pull/24149 This PR makes miniscript completely solvable in Bitcoin Core, merged last month, and it's just the miniscript support in the code level, not full bitcoin-cli support yet, maybe in a few months.

Now it looks like full descriptors support arrived with Bitcoin Core 25.0 https://github.com/bitcoin/bitcoin/releases/tag/v25.0

So now I'm going to use this descriptor script to achieve the same goal.

This produces the asm

Are you able to spend the coins by btc core? The cli seems pretty cumbersome to use.

After changed to this miniscript solution, I'm able to spend the coins with both Bitcoin Core cli and Ledger Nano X.

Based on your description, it seems like you want to create a script that enforces a 2-of-3 multisig with a timelock. A and B can spend the UTXO together before the timelock, but after the timelock expires, C can spend the UTXO with either A or B.

The script you provided is almost correct, but there's a small mistake. Here's the corrected version:




In the script above, replace <timelock> with the desired timelock value (in blocks or seconds) and <key_A>, <key_B>, and <key_C> with the respective public keys or their corresponding script hashes.

The modified script enforces the following conditions:

If the condition inside OP_IF is true (timelock has not expired):
The top stack element should be the number 2 (indicating a 2-of-2 multisig condition between A and B).
If the condition inside OP_ELSE is true (timelock has expired):
The top stack element should be the timelock value.
C's public key or script hash should successfully verify using OP_CHECKSIGVERIFY.
Finally, <key_A>, <key_B>, and the number 2 are used for the final 2-of-2 multisig check.
Remember to provide the actual values for <timelock>, <key_A>, <key_B>, and <key_C> when implementing this script in a real-world scenario .

Hi, thank you for suggestion. But I don't understand how the OP_ELSE branch makes key_C and key_A enough to unlock the script? Because from your explanation, key_C should verify, then both key_A and key_B should do the 2-of-2 multisig check.

And I also don't get how is this 2-of-2 multisig produced, since the OP_ELSE branch doesn't provide a threshold number for the OP_CHECKMULTISIG. That's why I provide the number 1 before ENDIF to make 1 key_A key_B 2 CHECKMULTISIG.

BTW, I have changed the script to miniscript, any suggestions to this?

In the ELSE branch, the sequence number is being verified, and if that's correct, then key_C is verified (and should be the top-most item on the witness data stack). If key_C is verified successfully, then OP_CHECKSIGVERIFY pushes True, which is actually represented as 1 according to  https://en.bitcoin.it/wiki/Script#Constants .

So this 1 value means that only one of key_A or key_B need to be present below key_C in the stack, in order for OP_CHECKMULTISIG to succeed. In other words, the ELSE branch converts the signing into Verify key_C + 1-of-2 multisig, as opposed to 2-of-2 multisig (without Key_C) in the IF branch.

I hope you understand it now.

Thank you! Any comments on the miniscript version?

I don't fully know Miniscript so there's not much I can say about the one-line version, but if the script immediately below it is the result of compiling the Miniscript to Script, then I must say it's significantly larger than the original script, and so I can't advise using it if this is going to be used hundreds of times (you, or the user who is making it, will have to pay extra fees per tx).

I agree it's more expensive, but miniscript is the only option to get wallets support.

I tried. Sparrow cannot spend from a taproot address. it can only create taproot addresses.

Sorry to hijack but can anyone help with spending a transaction from a time lock address???

I accidentally made the time lock 7140000 instead of 714000 and that means I have to wait 120 years to spend the coins. Please can anyone help????

If you created the script correctly then there is no way to spend these coins and nobody can help. The Bitcoin protocol is solid and will not allow these coins to move until block #7140000
Otherwise the only chance you have is if you made a mistake (wrong locktime value, using a branch that could be skipped, etc.) in which case you can post your full redeem script (like the ones you see in this topic) containing the OP codes, the locktime value and your public key here for people to see if there is any chance.

The maximum timelock allowed in Bitcoin is 0xffff, about 455 days. So you can't make a timelock of 120 years.

OP_CLTV is different from OP_CSV (absolute vs relative). It allows for the locking of Bitcoin to be evaluated either by unix time or block height, the latter for which is up to >9000 years while the former is until 2106.

This is almost certainly the same address which another used claimed to have created in this thread:
https://bitcointalk.org/index.php?topic=5455368.msg62364885#msg62364885
Archive - https://ninjastic.space/post/62364375

It seems that a scammer might be selling the private key to this timelocked address to multiple users who then realize they are unable to claim the coins and come here looking for help.

You are right, forgot about the absolute timelock value.