using nLockTime for lost online wallets

[willphase]

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

[1714155236]

1714155236

[1714155236]

1714155236

[jackjack]

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

[makomk]

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.

[willphase]

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]

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

[Mike Hearn]

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]

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.