Some resources and notes for locking scripts

[raphjaph]

• https://github.com/SachinMeier/bitcoinex/blob/master/lib/taproot.ex
• https://github.com/Larkhell/redeem-script-generator/blob/main/src/index.js
• https://github.com/paulmillr/scure-btc-signer/blob/main/src/utils.ts#L100
• https://gist.github.com/lifofifoX/2fb7fe22f1cb17fd71bf8fc43fb6fe58
• https://github.com/paulmillr/scure-btc-signer/blob/main/src/utils.ts#L100

[samedcildir]

I believe it would be better to use OP_CHECKSEQUENCEVERIFY insted of OP_CHECKLOCKTIMEVERIFY since firstly block timestamps can be manipulated and secondly it would make more sense to lock bitcoin native assets using bitcoin-time aka block-height.

BiS Artifacts collection utilizes the locking mechanism below:
The inscription gets its current location using /r/inscription endpoint and also it knows its genesis transaction using the first part of inscription id. Then it uses /r/gettx to get the transaction information and tracks itself backwards until it reaches to genesis tx. Then it populates an array of script pub keys that it has been held by, and if the address is a P2TR address, it calculates the corresponding P2TR lock output script that locks the utxo for 1 year. The script format is: <wait_block_count> OP_CHECKSEQUENCEVERIFY OP_DROP <tweaked_pubkey> OP_CHECKSIG where tweaked_pubkey can be calculated from script pub key by removing the first two bytes and wait_block_count is 6 * 24 * 365 assuming an average of 10 minute block time. This script is the only script leaf in the tap tree and internalPubkey of the locking wallet is selected as 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 which is defined as unspendable in BIP-341 which locks the key-spending-path. Since we know all of the information using on-chain data, we can detect if this inscription is sent from a P2TR wallet to its corresponding P2TR 1-year lock wallet.
This is an example locked version
you can find the locking tx here
This is an example not yet locked version

Also an example of locking-unlocking with 5 block lock:
Locking TX
Unlocking TX
You can see the unlocking script in the second transaction. Note that this one was using another internalPubkey (we've selected a different one at first but then changed it to the one in BIP-341)

A point to keep in mind: https://bitcointalk.org/index.php?topic=1313175.0 lock-time is signed integer so it needs zero padding for values that start with bit 1.

[lifofifoX]

secondly it would make more sense to lock bitcoin native assets using bitcoin-time aka block-height

You can use block height with OP_CLTV and absolute heights are conceptually simpler than relative ones. You can check out my implementation on https://tx.dev/utxo/timelock

[samedcildir]

I didn't know that we could use block height with CLTV. However if we use absolute block height, the lock wallet address will change for every locked utxo and it would be much harder to implement it with current indexers and wallets. If we use relative block height with a few pre-selected standard heights, it would mean the indexer only needs to track a few extra wallet addresses which would be very easy to implement.

Also with absolute block height limit, since users cannot control which block height the transaction will be mined, they may not be able to lock it the exact amount of blocks needed and probably one of the most requested feature which is staking will require a certain amount of lock to give something in return.

[lifofifoX]

@samedcildir Good point re: address discovery!

And OP_CSV definitely makes more sense from staking point of view. I'm thinking about this more from primary mint POV, where you'd want all assets to unlock at the same time.