Bitcoin Forum

perhaps this is a way to deal with the tainted/stolen coin problem:

what if we could flag certain btc with something like "this cannot be transferred from this address within X period" (able to be changed by the owner)? for example, in a long-term savings situation, this would allow even an unprotected walled, assuming all coins were marked, to be safe for a period of time.

of course protecting the data relating to when it becomes un-protected would be important information for hackers to have to do time-based attacks/extractions on wallet files, so unless that is figured out maybe this is useless.

but, just thinking out loud...

That's a feature I for one would LOVE to see.
But I have no idea how complex it would be to implement properly...

Who's the "we"? What if "we" don't like your politics, your religion or "we" think you're funny looking and want to shut your coins down?

The danger of centralization is far greater than the danger of decentralization.

I think by "we" paulie means the owner of a given BTC address, so no centralization is involved...

Ah. Sorry for misunderstanding the gist.

Now that I get it, I'm on the fence. I'll have to mull it over.

I like this idea very much indeed.
Beside that, the puplic should be aware of how many bitcoins are locked and how long.
Considered a huge amount of coins is locked up, this of course is a price driver.

Not exactly what you mean, but there's this feature, not yet enabled unfortunately, called nLockTime. It would allow you to specify a minimum block height for a transaction. For example, you say a transaction X should not enter the blockchain before block 210K. You may release the tx now, but it won't be accepted until then.

Question: is there a way, in bitcoin script, to get the block number?

If this was possible it would be possible to make what OP asks with a custom transaction script.

that sounds like it could be the basis of the feature, especially if something could be embedded into it to have it automatically transfer to another address after that block. because there is a danger in this though, isn't there, of losing the wallet.dat file in the meantime.

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

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.

The "right" way to do this is with P2SH M-of-N, and make sure that less than M keys are online waiting to be stolen.  It also has the advantage that you don't need to guess the proper duration for the lock.

What does the owner need in order to change the lock? Why would he be able to keep this safe but not the private key of the address?

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.

Only issue is that emergencies happen in life and you might need the money, if you lock the money in a bank for example for 5 years so you can get increased interest rate, you can still take it out but will be hit with a fine.
What if you need the Bitcoins in an emergency ?

To force yourself to wait at least X blocks:
Create x private keys
Create one offline transaction per key, sending the entire sum to the next address in series
Delete all but the last private key
Send the offline transactions to a bunch of different servers, all of which are set to automatically relay each transaction

That way, it's impossible to spend anything until every transaction has been processed, which will take ~10 minutes per key. So for 12 days you would need 24*6*12 keys.

All tx can go in the same block. 10 minutes later coins are in the last address.

Which is why Bitcoin won't eliminate banks.  The role of banks may change but some people want a trusted, bonded, and insured third party to secure their wealth for them.  Long before fiat and FDIC there were banks. 

This does not solve the problem of exchange operators having a hot wallet.  What happens with large withdrawals.  This sounds like a decent idea for people that want to hoard their coins without worrying about them being hacked.  On the other hand, encrypting your wallet sounds like it does about the same thing.  For businesses that need BTC on hand at a moments notice, I do not think that this would solve their problems.  Or solve any of the problems with exchanges getting hacked.

I am not sure what advantages a time locked address has over an offline address?  I am just not seeing it.

However there are encryption algorithms which are time lock encryption.

Generate a private key & address.
Record the address.
Encrypt the private key with a time lock algorithm which requires x time.
Erase the private key.

The above 4 steps should likely be done on an offline non-persistent environment (i.e. live LINUX).

Start solving the time lock encryption problem.
You will have the private key after x time.*

* It isn't possible to specify the exact time as it will depend on hardware but time lock encryption algorithms are designed to make parallel work impossible (i.e. 2x GPU provides no more speed than 1x GPU).  The single processor may get more powerful over time so if x is very long you may need to compensate for Moore's law. 

Interesting... Do you know of any specific time-lock encryption open-source apps (on Linux or Windows)?

Damn, that's true. I guess you could send each tx to a different set of independent servers, but that's still not 100% secure.  :-\ At least I learned something today, thanks!

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.

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.

thread over.

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.

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? :) )

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

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

please stop hijacking threads.

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

Some folks just can't let go of the old modes of thinking.

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

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

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.

lol, I like that one is that your creation?

50 btc bounty to whoever hacks MysteryMiner's coins

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?


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.

Of course, the thief is totally innocent.  ::)

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.

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.


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.

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.

Previous thread (https://bitcointalk.org/index.php?topic=81675.0) with the same idea.

Very old thread (https://bitcointalk.org/index.php?topic=1786.5) discussing nTimeLock.

So, theoretically, couldn't the same limit be placed on spending the output of a time locked transaction, to prevent this?

Partially. I added the censorship thing to this, the MJ bleaching was probably from efukt.com long time ago.This is how computers work. Some people are smarter and makes computers to do unexpected things for amusement or abusement. Get over it or return to using mechanical Iron Felix.

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.

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.

You are thinking how to make hammer work also as a saw.

It's a useful skill.

http://www.deviljohn.net/fixerupper/ashopisborn/07.dado.jpg