Does anyone know if there's testnet functionality to try this out ... if not Bitcoin testnet, what about an altcoin?)
https://github.com/viacoin/viacoin/pull/23
https://github.com/ElementsProject/elements/commits/checklocktimeverify
Cheers
Graham
Topic: OP_HODL - page 2. (Read 5652 times)
https://github.com/viacoin/viacoin/pull/23
https://github.com/ElementsProject/elements/commits/checklocktimeverify
Cheers
Graham
Does anyone know if there's testnet functionality to try this out? Or even just a single TxID on testnet I can refer to (EDIT: or if not Bitcoin testnet, what about an altcoin?)
It should be possible by running the latest bitcoin core from github under regtest.
Does anyone know if there's testnet functionality to try this out? Or even just a single TxID on testnet I can refer to (EDIT: or if not Bitcoin testnet, what about an altcoin?)
I'm still curious to know how many people have used this and to what purpose. It could make for some interesting stories.
No one can use this with bitcoin right now, until 95% of miners support it.
An example from https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Escrow
If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting "hit by a bus" they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party.
With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force.
With CLTV, they may set the following rules for spending the funds:
- At any time the funds can be spent by Alice's and Bob's signature
- 3 months (or other specified time) later, the funds can be spent by Lenny's signature and one of Alice's or Bob's signature
If Alice is hit by a bus, Bob can get the money back 3 months later with Lenny's help.
Nice! I didn't know bitcoin can do something like that. Things like that should be propagated more. Only when bitcoiners know about these things they can solve problems and show that bitcoin is attractive.
^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
I see Elements Project on that list. Is this a sidechain in the works?
I'm still curious to know how many people have used this and to what purpose. It could make for some interesting stories.
No one can use this with bitcoin right now, until 95% of miners support it.
-snip-
Is it still only in draft stage, or complete?
It is almost ready to start the miner voting, but it will still take a few months until we have enough miner support
I'm still curious to know how many people have used this and to what purpose. It could make for some interesting stories.
No one can use this with bitcoin right now, until 95% of miners support it.
An example from https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Escrow
If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting "hit by a bus" they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party.
With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force.
With CLTV, they may set the following rules for spending the funds:
- At any time the funds can be spent by Alice's and Bob's signature
- 3 months (or other specified time) later, the funds can be spent by Lenny's signature and one of Alice's or Bob's signature
If Alice is hit by a bus, Bob can get the money back 3 months later with Lenny's help.
*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!
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:
So yes, the merchant has nothing to fear.
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.
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:
Quote
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
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.
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.
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:
Quote
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
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.
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.
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?
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.
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.
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.
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 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.
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://bitcointalksearch.org/topic/what-is-a-bitcoin-soft-fork-in-laymens-terms-945977
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-
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://bitcointalksearch.org/topic/what-is-a-bitcoin-soft-fork-in-laymens-terms-945977
hero member
Activity: 560
Merit: 506
I prefer Zakir over Muhammed when mentioning me!
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-
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://bitcointalksearch.org/topic/what-is-a-bitcoin-soft-fork-in-laymens-terms-945977
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-
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.
hero member
Activity: 560
Merit: 506
I prefer Zakir over Muhammed when mentioning me!
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-
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.
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.
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.
hero member
Activity: 560
Merit: 506
I prefer Zakir over Muhammed when mentioning me!
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-
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-
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.
hero member
Activity: 560
Merit: 506
I prefer Zakir over Muhammed when mentioning me!
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.
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.
Jump to: