what about allowing an owner to lock BTC to an address for a period of time?

[MysteryMiner]

So the attacker could lock the coins for arbitrary long time. This idea is a brainfart.

Tainted coins? 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.

[Transisto]

... 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.

[paulie_w]

thread over.

[kjj]

If the unlocked one has more fees, miners might just take it instead of the locked one.

Couldn't this same logic could be used for multisig as well?  And what are the trade offs of these "features"?  They all seem well intended, but I worry they will over complicate the protocol.  Creating more bugs & increasing the opportunity for someone to obfuscate ill-intended code.  Or create a fork.  KISS = keep it simple, stupid.  Bitcoin is already complicated enough.

You still have to satisfy the multisig script.

Ok, say you want to use nLockTime to send money to yourself in the future to prevent an attacker from stealing the timelocked coins.  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.  But, if the attacker can give it directly to a miner, and if their attack transaction has a higher fee than the honest transaction, the miner now has an incentive to include the unlocked one rather than the locked one, making your timelock moot.

But, if you use M-of-N, and less than M keys are in places where they can be stolen (like on paper in a safe or bank vault), it is impossible for an attacker to spend, and even if a miner was willing to throw it into a block for a cut, it still couldn't happen.

[ElectricMucus]

There already is a solution to this kind of problem without any tainted coins.

It would involve the possibility to "commit coins" to be payed to a certain address, requiring a third party (the exchange) to validate it. This way they exchange never as access to the coins at any point directly. Still that's a new feature which would have to be implemented in the blockchain.
(Wouldn't that be nice if that were the secret September announcement? )

[benjamindees]

Moved Here:  https://bitcointalk.org/index.php?topic=106298.0

[ElectricMucus]

What's it with the obsession over interest on some of you guys? 

[paulie_w]

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.

please stop hijacking threads.

unless you're doing it for the LOLs, then it's fine.

[Severian]

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.

[benjamindees]

please stop hijacking threads.

unless you're doing it for the LOLs, then it's fine.

Moved Here:  https://bitcointalk.org/index.php?topic=106298.0

[paulie_w]

sorry benjamindees, i guess i just didn't get it.

[MysteryMiner]

... 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.

The difference is that Bitcoins can be completely secured from theft, unlike physical items in house or even castle. If your bitcoins are stolen this is your and only your fault!

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.

[ElectricMucus]

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?

[paulie_w]

50 btc bounty to whoever hacks MysteryMiner's coins

[caveden]

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.

[caveden]

If your bitcoins are stolen this is your and only your fault!

Of course, the thief is totally innocent. 

[caveden]

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.

[kjj]

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.

[caveden]

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.

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.

[benjamindees]

Previous thread with the same idea.

Very old thread discussing nTimeLock.