Bitcoin Forum
November 12, 2024, 01:32:50 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Delayed Access  (Read 919 times)
FreeMoney (OP)
Legendary
*
Offline Offline

Activity: 1246
Merit: 1016


Strength in numbers


View Profile WWW
January 12, 2012, 10:24:44 PM
 #1

Given the easy and irreversible nature of Bitcoin transactions I sometimes worry about being coerced into giving up my stash. Leaving them in someone else's control is not a good solution, and the way most are set the attacker would just demand whatever it is I use to get access.

It would be good to put my funds behind some work. The first thing that comes to mind is forgetting/hiding from myself the last ~5 chars of an encryption password. Then the attackers have the trouble of keeping me for a day or whatever and don't know immediately if I've lied to them about the known part. Of course they might just think I'm lieing about the whole thing in which case I might as well be.

My idea is also weak because they will know when they've searched the whole space, it would be better to have average time of a day, but not evenly distributed so they'd only know for sure after whatever length of time I was willing to maximally wait to get to my funds normally.

This also helps against drunk shopping and gambling and gifting. Different funds could be under different time locks as appropriate. Really, a setup where 1% of funds become available every hour might work well.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
January 12, 2012, 10:48:44 PM
Last edit: January 12, 2012, 11:14:35 PM by DeathAndTaxes
 #2

Essentially you are asking about a cryptographic problem knows as "time lock encryption".

Obviously whatever time requirement you set can't be overcome by you (or anyone else) so it would only be useful for a "storage wallet".  However you could have the private key be a SHA-256 hash CHAIN (w/ a lot of iterations) of a memorized passphrase.  

For example you make your passphrase "this is my password, no seriously stop hitting me with that wrench".  Lets say you have a chip (GPU/CPU/FPGA/etc) that can perform 1 GH/s sequentially (note GPUs operate in parallel so sequential speed is much lower so you would need to do some benchmarking).  Lets also say you KNOW you will not need access to the funds for at least a week.

1 * 10^9 * 60 * 60 * 24 * 7 = 2.52 x 10^13.  Simply make the private key the SHA-256 hash of the hash of the hash of the hash .... 2.52 x10^13 iterations ... of the hash of your passphrase.

Spend the 1 week to produce the private key from the passphrase (but don't record it anywhere).  Next generate the public address like normal.  Now record the public address, passphrase, and # of iterations somewhere safe (like on plastic or metal card in a safe).  Erase any copy of the private key (best done on say a linux live cd to ensure no copy remains).

Now you can deposit money at will by sending to the address but to remove funds requires knowing the passphrase AND performing 2.52 x 10^13 sequential SHA-256 hashes.  Given the input of each hash is the output of the prior hash the problem can't be executed in parallel.  The only thing that would speed things up is if the attacker has say a 2 GH/s (single chip not parallel execution) processor.   Then it would take ~4 days instead of 7.  4GH/s would take ~2 days.

Even if attacker got a hold of say Deep bit = 3000 GH/s they couldn't speed up the solution because each hash is dependent on the one before.  Deepbit is "fast" because Bitcoin hashing is only dependent on the prior block so all quadrillions of hashes of the current block are independent.  Periodically (say every couple years) you should create a new address w/ more iterations and move the funds to ensure you stay ahead of Moore's law.

A chained hash is a very simple form of timelock encryption.  The main drawback is to get 7 days in security requires 7 days to lock.  There are more complex algorithms which allows you to use parallel resources to "lock" the secret but it can only be unlocked sequentially and that allows you to speed up the locking time without risking a faster unlocking.

http://www.gwern.net/Self-decrypting%20files
FreeMoney (OP)
Legendary
*
Offline Offline

Activity: 1246
Merit: 1016


Strength in numbers


View Profile WWW
January 12, 2012, 10:54:36 PM
 #3

Right, repeated hashing is way better than what I said.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Revalin
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
January 12, 2012, 11:06:18 PM
 #4

You can create transactions that require multiple signatures to spend.  Thus you can store coins in a way that requires both your memorized password and a co-signing from someone (perhaps an online wallet provider or a friend) who agrees to delay signing all your spends.

Further you can create a transaction that will allow spending by ( (you + friend) or (just your emergency backup key) ), and store that emergency backup key somewhere secure.  This protects you against your friend losing the key.

This isn't commonly done now, but I'm sure it will be in the future.  Do you have an immediate need?

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
FreeMoney (OP)
Legendary
*
Offline Offline

Activity: 1246
Merit: 1016


Strength in numbers


View Profile WWW
January 12, 2012, 11:21:18 PM
 #5

You can create transactions that require multiple signatures to spend.  Thus you can store coins in a way that requires both your memorized password and a co-signing from someone (perhaps an online wallet provider or a friend) who agrees to delay signing all your spends.

Further you can create a transaction that will allow spending by ( (you + friend) or (just your emergency backup key) ), and store that emergency backup key somewhere secure.  This protects you against your friend losing the key.

This isn't commonly done now, but I'm sure it will be in the future.  Do you have an immediate need?

This is nice now while were all free and happy. But how firm is the agreement when he's emailed pictures of my broken face? And he's not immune to capture either. Plus if we're held separately we'll each deceive ourselves into thinking they still can't get the funds because of the other one being free and cave earlier than normal.

Never know when the need will arise.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Revalin
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
January 12, 2012, 11:47:21 PM
 #6

It all depends on the level of security you need.  Your original question was for a 1 day time lock.  Anyone who would mail said pictures would be willing to simply hold you for 24 hours as well.  If you have enough BTC that this is a serious concern, you need a cosigning service that provides a matching level of security.

If you have less than USD$1M in BTC just store the bulk of your savings in a safe deposit box with a two-party access contract.  Anyone who can get access to it would be better off simply holding up the bank and taking the fiat.  If you have tens of millions of USD-equivalent you should look at a high security facility instead of your local bank branch.

That's just for now...  there aren't very many people with wallets that large.  If the need arises I'm quite sure that high security timelock cosigning services will be created.

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!