|
paulie_w (OP)
|
 |
September 06, 2012, 04:19:55 PM |
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
flatfly
Legendary
 Offline
Activity: 1078
Merit: 1016
760930
|
|
September 06, 2012, 04:24:14 PM |
|
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... |
|
|
|
|
|
Severian
|
|
September 06, 2012, 04:39:26 PM |
|
what if we could flag certain btc
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. |
|
|
|
|
flatfly
Legendary
Offline
Activity: 1078
Merit: 1016
760930
|
|
September 06, 2012, 04:45:12 PM |
|
what if we could flag certain btc
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... |
|
|
|
|
|
Severian
|
|
September 06, 2012, 04:48:50 PM |
|
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. |
|
|
|
|
|
sippsnapp
|
|
September 06, 2012, 04:50:14 PM |
|
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.
|
Πάντα ῥεῖ
Bitcoin + Altcoin node pool setup - pm
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
|
September 06, 2012, 04:50:51 PM |
|
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.
|
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
|
September 06, 2012, 04:52:39 PM |
|
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.
|
|
|
|
|
|
paulie_w (OP)
|
|
September 06, 2012, 04:54:02 PM |
|
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.
|
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1025
|
|
September 06, 2012, 05:04:17 PM |
|
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.
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. |
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1014
Strength in numbers
|
|
September 06, 2012, 05:24:46 PM |
|
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?
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone. |
|
|
|
nevafuse
|
|
September 06, 2012, 05:35:07 PM |
|
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. |
The only reason to limit the block size is to subsidize non-Bitcoin currencies
|
|
|
|
ice_chill
|
|
September 06, 2012, 05:42:02 PM |
|
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 ?
|
|
|
|
|
|
Explodicle
|
|
September 06, 2012, 05:49:58 PM |
|
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.
|
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
September 06, 2012, 05:57:21 PM |
|
All tx can go in the same block. 10 minutes later coins are in the last address.
|
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
September 06, 2012, 05:59:10 PM |
|
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 ?
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. |
|
|
|
|
|
Bitobsessed
|
|
September 06, 2012, 06:04:39 PM |
|
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.
|
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
September 06, 2012, 06:06:23 PM |
|
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.
|
|
|
|
|
flatfly
Legendary
Offline
Activity: 1078
Merit: 1016
760930
|
|
September 06, 2012, 06:26:56 PM |
|
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)? |
|
|
|
|
|
Explodicle
|
|
September 06, 2012, 07:31:45 PM |
|
All tx can go in the same block. 10 minutes later coins are in the last address.
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! |
|
|
|
|
|
