Bitcoin Forum
December 11, 2016, 12:06:29 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: using nLockTime for lost online wallets  (Read 1262 times)
willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
August 03, 2011, 10:28:57 PM
 #1

With bitomat losing their wallet, and bitcoins being lost as a result, this can potentially be solved by using the nLockTime field in the transaction.  See here under 'lock_time'.  This field allows you to specify a minimum unix_time or block count that the transaction won't be accepted into the blockchain before.  This is usually set to 0 by clients meaning that it is always valid.

What would happen is:

 - User deposits money in an exchange/bank, specifying the lifetime of the deposit (e.g. 1 month) and a 'return address'.
 - Exchange/Bank adds bitcoins to the users' account, and also returns a signed transaction to 'return address' with nLockTime set to the block or time matching the lifetime of the deposit.  User then keeps this stored transaction safe.
 - The exchange/bank can rely on the bitcoins remaning valid until the lifetime has been exceeded
 - Once lifetime is reached, the exchange/bank marks the bitcoins as 'invalid' and cancels any pending balance/bids/asks based on the deposit.
 - At this point, the exchange/bank can either automatically send the money back to the user using 'return address', or perhaps offer the the user the option of keeping the money in the bank/exchange by the exchange/bank moving the bitcoins to a new wallet with a new lifetime, resulting in a new transaction record the user keeps.  The old transaction record can now be destroyed.  Alternatively the user can withdraw the bitcoins merely by placing the stored transaction into the blockchain, or by withdrawing from the bank/exchange as normal.

The exchange/bank has no risk of the user withdrawing the bitcoins before the lifetime so can happily base bid/offer/balance until the lifetime arrives, at which point the bitcoins cannot safely be used because the user could at any time from then place the transaction into a block chain.  For support for part-bitcoin transactions (e.g. 10BTC deposit, with 0.1 BTC quantum) several pending transactions at different values (e.g. factors of 2 of satoshi) can be returned during the deposit.  (Note: For this split-bitcoin stored transaction to work, the exchange/bank would have to use a modified bitcoin client that pays txout change to the sending address.)

Note: This does not solve malicious exchange/banks since a malicious exchange/bank could just transfer the balance to another wallet and the stored transaction would never be accepted.

This is purely to solve the situation where a bank/exchange loses their wallet, then it's simply a matter of the user waiting until the lifetime hits then enacting the transaction(s).  This merely means that there would be a recourse for lost wallets e.g. bitomat.

Thoughts?

Will

1481457989
Hero Member
*
Offline Offline

Posts: 1481457989

View Profile Personal Message (Offline)

Ignore
1481457989
Reply with quote  #2

1481457989
Report to moderator
1481457989
Hero Member
*
Offline Offline

Posts: 1481457989

View Profile Personal Message (Offline)

Ignore
1481457989
Reply with quote  #2

1481457989
Report to moderator
1481457989
Hero Member
*
Offline Offline

Posts: 1481457989

View Profile Personal Message (Offline)

Ignore
1481457989
Reply with quote  #2

1481457989
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481457989
Hero Member
*
Offline Offline

Posts: 1481457989

View Profile Personal Message (Offline)

Ignore
1481457989
Reply with quote  #2

1481457989
Report to moderator
1481457989
Hero Member
*
Offline Offline

Posts: 1481457989

View Profile Personal Message (Offline)

Ignore
1481457989
Reply with quote  #2

1481457989
Report to moderator
jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 03, 2011, 10:37:44 PM
 #2

Nice idea, but banks don't lose their wallets. Never

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 03, 2011, 10:41:47 PM
 #3

Assuming that nLockTime behaves as it's supposed to that should mostly work. The only issue is that your scheme for dealing with partial change is unworkable. Bitcoin transactions don't just spend from an address alone - they have to be created to spend from a particular txout of a particular transaction, and there's no way you can create in advance a transaction that spends the change txout of a future transaction that you don't yet know the contents of.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
willphase
Hero Member
*****
Offline Offline

Activity: 770


View Profile
August 03, 2011, 10:48:22 PM
 #4

Assuming that nLockTime behaves as it's supposed to that should mostly work. The only issue is that your scheme for dealing with partial change is unworkable. Bitcoin transactions don't just spend from an address alone - they have to be created to spend from a particular txout of a particular transaction, and there's no way you can create in advance a transaction that spends the change txout of a future transaction that you don't yet know the contents of.

Yes - this is very correct.  For the scheme to work, the bank/exchange would have to accept the bitcoins then immediately split in into several smaller out transactions, and return a 'stored transaction' for each of these out transactions, otherwise immediately they spent any of the bitcoins the stored transaction would invalidate.

Perhaps another option would be to simply email the user a new transaction record every time the exchange/bank performs any transaction.  Not sure how feasible this would be.  After all, an exchange implementing this would probably just not lose their wallet in the first place.

Will

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
August 04, 2011, 03:59:47 AM
 #5

You can use the alternate SIGHASH modes to sign inputs separately so that inputs can be added/removed without invalidating the entire transaction. So a new refund transaction wouldn't have to be issued every time BTC is spent: only a new input to refund the change would need to be signed.

There's a way to do something like this without trusting the exchange:
https://bitcointalk.org/index.php?topic=25786.0

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
August 04, 2011, 09:32:53 AM
 #6

Yes, I think a better model is just to do "high-frequency trading" by resigning transactions with higher sequence numbers. This was described by both Satoshi and hashcoin. You'd need to run software on your computer that is in constant contact with the exchange so it can request coins from your wallet on demand.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 04, 2011, 04:15:37 PM
 #7

You can use the alternate SIGHASH modes to sign inputs separately so that inputs can be added/removed without invalidating the entire transaction. So a new refund transaction wouldn't have to be issued every time BTC is spent: only a new input to refund the change would need to be signed.
If you do it that way you can't change the total amount paid out by the outputs of the transaction to match. (While I think there may be a mode that doesn't sign the outputs that opens a huge security hole.) It's probably better just to create a fresh transaction.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!