You are thinking how to make hammer work also as a saw.
It's a useful skill.
Topic: what about allowing an owner to lock BTC to an address for a period of time? (Read 3442 times)
September 08, 2012, 05:05:02 AM
It's a useful skill.
September 07, 2012, 08:12:46 AM
You are thinking how to make hammer work also as a saw.
September 07, 2012, 08:04:52 AM
Newly mined coins aren't valid until 100 blocks have passed
...
Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
...
Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
So, theoretically, couldn't the same limit be placed on spending the output of a time locked transaction, to prevent this?
Right now, you can validate a block with no prior knowledge of any of the transactions in it. If you are thinking what I think you are thinking, it would require that every node have perfect knowledge of all transactions on the network before it could be sure a block was valid. Or maybe you are thinking something else, I'm not sure.
September 07, 2012, 07:11:37 AM
Censorship is like Michael Jackson's anal bleaching - at some point it got out of control.
lol, I like that one is that your creation?If your bitcoins are stolen this is your and only your fault!
Of course, the thief is totally innocent.
To original topic - the time locked transactions are possible right now - the coins are locked from spending for approx 10 minutes until they are in a block. I dont see any need for Bitcoin to to all sorts of things for any life situation. Bitcoins are purely for transactions, use web based services such as mybitcoin.com or mtgox for any additional "features" such as freezing your own coins from withdrawal and so on.
September 07, 2012, 05:02:45 AM
Newly mined coins aren't valid until 100 blocks have passed
...
Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
...
Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
So, theoretically, couldn't the same limit be placed on spending the output of a time locked transaction, to prevent this?
September 07, 2012, 04:25:21 AM
September 07, 2012, 03:38:13 AM
We put a lot of effort into avoiding the possibility of invalidating a chain of transactions. Newly mined coins aren't valid until 100 blocks have passed (120 in practice, but the hard requirement is only 100). If not for that requirement, a miner could create some coins, spend them, the recipient could spend them, etc, and then a shallow reorg would invalidate the coinbase, and break the whole chain. People should wait for sufficient confirmations to avoid the problem, but they don't, so the network makes it impossible.
Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid.
And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid.
And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
The same "invalidating chain of transactions" scenario may already happen if people accept 1 or 0 confirmation transactions. The difference with coinbase is that the money totally vanishes in a reorg, while in these scenarios it doesn't disappear, it may still be included in a future block. And still, I'm not even that sure the protocol itself should forbid coinbase from being spent right away. Perhaps people should be allowed to take the risk of accepting a transaction whose money may suddenly disappear. I believe miners in a pool would appreciate if they could withdraw their money right away, for example.
Anyways, just wondering. I realize people will not want to touch this, and they have a good reason not to.
September 07, 2012, 03:15:28 AM
No, there is no way to get the block number in a script. People keep asking for it, but it wasn't left out by accident, it is missing for a reason. (Please think about how the network handles block reorgs for a while before you ask...)
Pardon my ignorance, but all I know about reorgs is that the block that loses the race gets ignored. Its transactions are not valid anymore and must be included in another block.
Why does that makes it impossible to get the block number, or other block header data, in a script? I mean, I understand it might be complicated and perhaps not worthwhile doing. But it's not impossible, is it?
We put a lot of effort into avoiding the possibility of invalidating a chain of transactions. Newly mined coins aren't valid until 100 blocks have passed (120 in practice, but the hard requirement is only 100). If not for that requirement, a miner could create some coins, spend them, the recipient could spend them, etc, and then a shallow reorg would invalidate the coinbase, and break the whole chain. People should wait for sufficient confirmations to avoid the problem, but they don't, so the network makes it impossible.
Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid.
And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
You create a transaction that will not be valid for a month (whatever) and broadcast it. Then an attacker gets in and steals the private key for that address. They can create a new transaction that sends the money to their own address. Honest nodes will consider that a double spend and refuse to relay it.
No... honest nodes should consider the legit owner is cancelling the transaction.
nLockTime shouldn't be used to protect against private key loss. Since you'll have to secure the target key of the transaction anyway, why don't you secure the current key the same way?
I might be remembering it wrong, it's been a while since I looked into nLockTime. Either way, we both come to the same conclusion: timelocking can't work.
September 07, 2012, 03:01:16 AM
You create a transaction that will not be valid for a month (whatever) and broadcast it. Then an attacker gets in and steals the private key for that address. They can create a new transaction that sends the money to their own address. Honest nodes will consider that a double spend and refuse to relay it.
No... honest nodes should consider the legit owner is cancelling the transaction.
nLockTime shouldn't be used to protect against private key loss. Since you'll have to secure the target key of the transaction anyway, why don't you secure the current key the same way?
The most notable use case I see for nLockTime is inheritance. You transfer your money to your heirs in a time locked transaction. But it's still your money, you may cancel the transaction and spend the money some other way. In case you die before doing it, then your heirs will eventually get the money.
September 07, 2012, 02:52:52 AM
If your bitcoins are stolen this is your and only your fault!
Of course, the thief is totally innocent.
September 07, 2012, 02:51:09 AM
No, there is no way to get the block number in a script. People keep asking for it, but it wasn't left out by accident, it is missing for a reason. (Please think about how the network handles block reorgs for a while before you ask...)
Pardon my ignorance, but all I know about reorgs is that the block that loses the race gets ignored. Its transactions are not valid anymore and must be included in another block.
Why does that makes it impossible to get the block number, or other block header data, in a script? I mean, I understand it might be complicated and perhaps not worthwhile doing. But it's not impossible, is it?
nLockTime has some issues. For example, if you lose your keys, the network could see two transactions spending the same output, one locked until some time in the future, and one not locked. If the unlocked one has more fees, miners might just take it instead of the locked one.
That's exactly how I pictured nLockTime should work: you should be able to cancel the scheduled transaction.
It does not solve what OP wants, of course.
September 06, 2012, 10:32:58 PM
50 btc bounty to whoever hacks MysteryMiner's coins
September 06, 2012, 09:16:16 PM
Censorship is like Michael Jackson's anal bleaching - at some point it got out of control.
lol, I like that one is that your creation? September 06, 2012, 09:05:41 PM
... Code your own client that will refuse tx containing ever growing list of "tainted" coins. Or better send your tainted coins to me, because "normal" clients and miners will ignore such censorship crap.
I guess being victim of a theft help having compassion for others who got stolen.I hope not everyone is as "normal" as you are.
None have succeeded in my challenge of stealing my bitcoins. I run pirated version of Microsoft Windows, I never had installed antivirus on my box, this is insecure setup in security "experts" opinion. Yet I have my box almost 24/7 online and have not even made backup wallet for my approx 350 coins.
You start with rejecting few addresses of know thefts and then expand the list of "tainted" coins. It's like Youtube first started to remove porno from channels and now it removes videos with Hitler. Censorship is like Michael Jackson's anal bleaching - at some point it got out of control.
September 06, 2012, 08:52:38 PM
sorry benjamindees, i guess i just didn't get it.
September 06, 2012, 08:01:16 PM
please stop hijacking threads.
unless you're doing it for the LOLs, then it's fine.
unless you're doing it for the LOLs, then it's fine.
Moved Here: https://bitcointalksearch.org/topic/what-about-allowing-an-owner-to-lock-btc-to-an-address-part-ii-bitcoin-bonds-106298
September 06, 2012, 07:54:03 PM
What's it with the obsession over interest on some of you guys?
Some folks just can't let go of the old modes of thinking.
September 06, 2012, 07:27:14 PM
This is an idea for those who think that Bitcoin must either take over the world, or die.
It would create the concept of Bitcoin "bonds". You could create a mechanism for individuals who are interested in seeing the exchange value of Bitcoins rise, to pay interest on the bonds. Perhaps, with a sophisticated multisig contract, it could be done in a de-centralized way. It almost doesn't even matter what the interest rate is, since there will be plenty of people who are holding Bitcoins for the long term anyways, and would be happy to lock their Bitcoins in exchange for more in the future.
The concept is that Bob pays 1 BTC, and in exchange receives a transaction that time-locks 10000 of Alice's Bitcoins, for a year. At the end of the year, Alice gets 10001 BTC back. I have no doubt there are people who would do this.
I wonder whether this is Gavin's "secret idea". It would add stability. It's sophisticated enough to be on his level. And it's fairly obvious based on recent events.
It would create the concept of Bitcoin "bonds". You could create a mechanism for individuals who are interested in seeing the exchange value of Bitcoins rise, to pay interest on the bonds. Perhaps, with a sophisticated multisig contract, it could be done in a de-centralized way. It almost doesn't even matter what the interest rate is, since there will be plenty of people who are holding Bitcoins for the long term anyways, and would be happy to lock their Bitcoins in exchange for more in the future.
The concept is that Bob pays 1 BTC, and in exchange receives a transaction that time-locks 10000 of Alice's Bitcoins, for a year. At the end of the year, Alice gets 10001 BTC back. I have no doubt there are people who would do this.
I wonder whether this is Gavin's "secret idea". It would add stability. It's sophisticated enough to be on his level. And it's fairly obvious based on recent events.
please stop hijacking threads.
unless you're doing it for the LOLs, then it's fine.
September 06, 2012, 07:23:18 PM
What's it with the obsession over interest on some of you guys?
Jump to: