OP_HODL

[BlindMayorBitcorn]

I'd like to start a thread about this. So sue me.

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki


Abstract

This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future.


Freezing Funds

In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.

[1715578396]

1715578396

[1715578396]

1715578396

[1715578396]

1715578396

[gjhiggins]

^Has anyone here done this yet? Or know of anyone who has? And why and how?

supcoin - https://github.com/supcoin/supcoin/commit/81e19c1b93da202479dfcb9eb84d7fd89c9db599

viacoin - https://github.com/viacoin/viacoin/pull/23

ziftrcoin - https://github.com/ZiftrCOIN/ziftrcoin/commit/42c932f50313a59cb1791e186417116fd71516d6

see also https://github.com/ElementsProject/elements/tree/checklocktimeverify

“how” is embodied in the source; I'm not in a position to comment on “why”.


Cheers

Graham

[NorrisK]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

[RustyNomad]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

Thought the same thing. Have not read any of the technical details yet so not sure whether such an option is available or not. If not then this can be a very risky thing to do. Not just for fat finger problems like you describe but also if things change i.e. you might want to lock in some coins for your kids but things can change over time resulting in you having to unlock said coins.

[BillyBobZorton]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

Thought the same thing. Have not read any of the technical details yet so not sure whether such an option is available or not. If not then this can be a very risky thing to do. Not just for fat finger problems like you describe but also if things change i.e. you might want to lock in some coins for your kids but things can change over time resulting in you having to unlock said coins.

I think a good ol password is better. With the password you can take the decision to spend them or not. Even with the benefit of forcing you to hold long term so you can become rich, i still don't like the idea of not having the option to hold with my own will. I don't like this feeling of "being forced to hold" so to speak.

[Amph]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

it could be better if it was time based and you just need your private key that are holding the funds and nothing else

let's say that you want your fund to be available in one year at most, because you have a desease that will kill you in a short time

[unamis76]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

Imagine sending 50BTC with a 0.001BTC fee, and you end up sending 0.001BTC and a 50BTC fee...

I don't know if it is possible to have a safeguard, but something like that would invalidate/wouldn't be more secure than a password in what concerns fund security, theft could still occur, and the fear of having funds confiscated would still be present.

Imagine you're taking a one month trip, and you want to make sure nobody touches your funds... If the safeguard key was found, funds could be spent anyways.

[Muhammed Zakir]

I don't even know how it's done. Are there special wallets to pull this kind of trick off?

You can use http://coinb.in/#newTransaction.

GreenAddress online wallet use this nLockTime feature to secure users' funds.

[RealBitcoin]

I don't even know how it's done. Are there special wallets to pull this kind of trick off?

You can use http://coinb.in/#newTransaction.

GreenAddress online wallet use this nLockTime feature to secure users' funds.

Yea but thats a poor version of it, With that you can only make it so that the TX is stored on that website and they will broadcast it later, but the TX is already made.

So perhaps you can delay it, but if you send another TX before that, it will be invalid after. Because you need all outputs/inputs to make a new TX.

[Muhammed Zakir]

I don't even know how it's done. Are there special wallets to pull this kind of trick off?

You can use http://coinb.in/#newTransaction.

GreenAddress online wallet use this nLockTime feature to secure users' funds.

Thank you.

Sorry. Both GreenAddress and Coinb.in uses nLockTime not OP_CHECKLOCKTIMEVERIFY.

I don't even know how it's done. Are there special wallets to pull this kind of trick off?

You can use http://coinb.in/#newTransaction.

GreenAddress online wallet use this nLockTime feature to secure users' funds.

Yea but thats a poor version of it, With that you can only make it so that the TX is stored on that website and they will broadcast it later, but the TX is already made.

You are wrong. You can get the time locked transaction(s) both to your email or from the transactions details and you can broadcast it yourself if you want. For making broadcasting easy, they have made a website -- http://greenaddress.github.io/gentle/. You can download that website from Github so that you can redeem even when the website is down. https://github.com/greenaddress/gentle

So perhaps you can delay it, but if you send another TX before that, it will be invalid after. Because you need all outputs/inputs to make a new TX.

No. OP_CHECKLOCKTIMEVERIFY will make other transaction(s) which spend the same input invalid.

P.S. If you are wondering the difference between nLockTime and OP_CHECKLOCKTIMEVERIFY, see

-snip-
BIP65's OP_CHECKLOCKTIMEVERIFY is about a script instruction to create a transaction whose outputs are unspendable until some particular block (or time).  nLockTime is a transaction that cannot be put into the block chain in the first place until some particular block (or time).  Both of these are of the "not yet" variety rather than the "not any more" variety.
 -snip-

[SebastianJu]

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend? I guess not all wallets will be updated to show that.

And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?

Sounds risky and without matching advantage.

[Muhammed Zakir]

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend?

You won't receive locked coins.

-snip-
And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?
 -snip-

Transaction is invalid, so the block will be invalid.

[SebastianJu]

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend?

You won't receive locked coins.

Then when is that opcode implemented? I think opcodes can only be implemented in a transaction. Which means you actually have to send a transaction. Or is there some failsafe that only allows to send to the same address? Would still sound exploitable.

-snip-
And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?
 -snip-

Transaction is invalid, so the block will be invalid.

Sounds like a risk to miners. I believe there are not few miners that dont follow the latest updates so close that it could not be a problem.

[Muhammed Zakir]

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend?

You won't receive locked coins.

Then when is that opcode implemented? I think opcodes can only be implemented in a transaction. Which means you actually have to send a transaction. Or is there some failsafe that only allows to send to the same address? Would still sound exploitable.

Opcodes are added in transaction script.  Script decides how the next person wanting to spend the Bitcoins being transferred can gain access to them.*

I think I misunderstood your question. I thought you asked what if a user receives locked Bitcoin. No person would receive locked coins. To answer your question: the coins will be locked until preset time has reached. After that, the person will be able to spend those coins.

* Line from Bitcoin wiki.

-snip-
And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?
 -snip-

Transaction is invalid, so the block will be invalid.

Sounds like a risk to miners. I believe there are not few miners that dont follow the latest updates so close that it could not be a problem.

Majority of miners need to use version that supports this opcode for acceptance and enforcement. If majority uses new version, obviously, others will (eventually) update their clients for incentive. CMIIW.

Useful links:

 • http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
 • https://bitcoin.org/en/developer-guide#term-soft-fork
 • https://en.bitcoin.it/wiki/Softfork
 • https://en.bitcoin.it/wiki/Script
 • https://bitcoin.org/en/developer-guide#consensus-rule-changes
 • https://bitcointalk.org/index.php?topic=945977.0

[SebastianJu]

Thanks for your help. You have a habit in this.

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

Wow... so what happens when this OPCODE is implemented and you receive coins you cant spend?

You won't receive locked coins.

Then when is that opcode implemented? I think opcodes can only be implemented in a transaction. Which means you actually have to send a transaction. Or is there some failsafe that only allows to send to the same address? Would still sound exploitable.

Opcodes are added in transaction script.  Script decides how the next person wanting to spend the Bitcoins being transferred can gain access to them.*

I think I misunderstood your question. I thought you asked what if a user receives locked Bitcoin. No person would receive locked coins. To answer your question: the coins will be locked until preset time has reached. After that, the person will be able to spend those coins.

* Line from Bitcoin wiki.

-snip-
And what happens when a miner doesnt know this opcode and implements the transaction in a block? Would the block become invalid by the nodes?
 -snip-

Transaction is invalid, so the block will be invalid.

Sounds like a risk to miners. I believe there are not few miners that dont follow the latest updates so close that it could not be a problem.

Majority of miners need to use version that supports this opcode for acceptance and enforcement. If majority uses new version, obviously, others will (eventually) update their clients for incentive. CMIIW.

Useful links:

 • http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
 • https://bitcoin.org/en/developer-guide#term-soft-fork
 • https://en.bitcoin.it/wiki/Softfork
 • https://en.bitcoin.it/wiki/Script
 • https://bitcoin.org/en/developer-guide#consensus-rule-changes
 • https://bitcointalk.org/index.php?topic=945977.0

[jl2012]

Thanks for your help. You have a habit in this.

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

You should have told the payer not to do so. If the payer insisted to do so without your consent, he breached the contract and you (as merchant) should not deliver the product.

With P2SH, a CLTV address will look like an ordinary bitcoin address (starting with 3). Therefore, in your example, the payer actually deliberately sent the bitcoin to a different address.

[jl2012]

U would like to have some sort of safeguard key to unfreeze my funds.. Imagine locking the coins for 100 years instead of 10 years... :p

Imagine sending 50BTC with a 0.001BTC fee, and you end up sending 0.001BTC and a 50BTC fee...

I don't know if it is possible to have a safeguard, but something like that would invalidate/wouldn't be more secure than a password in what concerns fund security, theft could still occur, and the fear of having funds confiscated would still be present.

Imagine you're taking a one month trip, and you want to make sure nobody touches your funds... If the safeguard key was found, funds could be spent anyways.

Fat-finger trading is not uncommon even in traditional stock market and cost millions or billions dollar of loss. However, safeguarding should be done in UI (wallet) level, not in the underlying protocol.

[SebastianJu]

Thanks for your help. You have a habit in this.

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

You should have told the payer not to do so. If the payer insisted to do so without your consent, he breached the contract and you (as merchant) should not deliver the product.

With P2SH, a CLTV address will look like an ordinary bitcoin address (starting with 3). Therefore, in your example, the payer actually deliberately sent the bitcoin to a different address.

Normally the addresses with 3 are multisig addresses. Do you say that the opcode is solving itself at one point in time because the time is somehow delivering the second key to spend the address? Then locking coins with the opcode only works when sending them to special bitcoin addresses that were created that way? A merchant does not have to fear anything then?

[jl2012]

Thanks for your help. You have a habit in this.

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

You should have told the payer not to do so. If the payer insisted to do so without your consent, he breached the contract and you (as merchant) should not deliver the product.

With P2SH, a CLTV address will look like an ordinary bitcoin address (starting with 3). Therefore, in your example, the payer actually deliberately sent the bitcoin to a different address.

Normally the addresses with 3 are multisig addresses. Do you say that the opcode is solving itself at one point in time because the time is somehow delivering the second key to spend the address? Then locking coins with the opcode only works when sending them to special bitcoin addresses that were created that way? A merchant does not have to fear anything then?

There is no restriction with the content of those "3" addresses. Multisig is the most common use case but it's simply common and we can do many fancy things with "3" addresses. CLTV is an example.

If the payer tries to manipulate the CLTV settings, it will become a different "3" address so the merchant is not mandated to honor the payment. Consider the following conversation:

Merchant: Please send 1BTC to 3xxxxxx and I will deliver the product
Customer: I have sent you 1BTC
M: No, I don't see any bitcoin in 3xxxxxx
C: Oh, I sent it to 3yyyyyy. This is also your address, but with different CLTV parameter
M: I'm sorry but 3yyyyyy is not my address. The only address I told you was 3xxxxxx. I'm not going to deliver the product until I see 1BTC in 3xxxxxx

So yes, the merchant has nothing to fear.

[SebastianJu]

*lol* Ok. Then i think i understood it correctly and there is no risk involved at all. The usecase is only for someone who owns the private key of the receiving address. No possible risk involved.

Thanks for explaining!

Thanks for your help. You have a habit in this.

So you say its really part of a transaction and can bind the coins that might be owned by a seller then.

What i would like to know, cant this be used to scam someone? Its not like a chargeback would be possible. But it sounds dangerous. I mean i surely dont want to receive coins that i find out, cant spend till 2017 or so.

You should have told the payer not to do so. If the payer insisted to do so without your consent, he breached the contract and you (as merchant) should not deliver the product.

With P2SH, a CLTV address will look like an ordinary bitcoin address (starting with 3). Therefore, in your example, the payer actually deliberately sent the bitcoin to a different address.

Normally the addresses with 3 are multisig addresses. Do you say that the opcode is solving itself at one point in time because the time is somehow delivering the second key to spend the address? Then locking coins with the opcode only works when sending them to special bitcoin addresses that were created that way? A merchant does not have to fear anything then?

There is no restriction with the content those "3" addresses. Multisig is the most common use case but it's simply common and we can do many fancy things with "3" addresses. CLTV is an example.

If the payer tries to manipulate the CLTV settings, it will become a different "3" address so the merchant is not mandated to honor the payment. Consider the following conversation:

Merchant: Please send 1BTC to 3xxxxxx and I will deliver the product
Customer: I have sent you 1BTC
M: No, I don't see any bitcoin in 3xxxxxx
C: Oh, I sent it to 3yyyyyy. This is also your address, but with different CLTV parameter
M: I'm sorry but 3yyyyyy is not my address. The only address I told you was 3xxxxxx. I'm not going to deliver the product until I see 1BTC in 3xxxxxx

So yes, the merchant has nothing to fear.