search

rhirhi90 / bitcoin-wallet

Automatically exported from code.google.com/p/bitcoin-wallet
0 stars 0 forks source link

Keys from the future #227

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
If a user freshly installs and starts the app with a clock in the future, the 
app will create a key "from the future". If the user receives a payment on that 
key shortly after, the wallet will see it but it will be "lost" after a replay 
(due to the checkpoints).

The app compares the clock to a reference from the web, but it can only do so 
with a delay (or even fail if no network is available).

Original issue reported on code.google.com by andreas....@gmail.com on 26 Sep 2013 at 10:03

GoogleCodeExporter commented 9 years ago 
Concrete example:

Address 1G3Xw6BZ9Kg7z7m6wJQsJpM7Cpu479ra5D - according to a wallet dump sent by 
the user the key creation time is 1380045736 (24 Sep 2013 18:02:16 GMT).

According to 
https://blockchain.info/address/1G3Xw6BZ9Kg7z7m6wJQsJpM7Cpu479ra5D, the first 
transaction was received on 2013-09-24 17:39:34 and included in a block on 
2013-09-24 17:52:41. Both times are well before the claimed key creation date.

I also wonder because block times are allowed to drift to some amount, are we 
taking this into account when picking the correct checkpoint and switching from 
headers-only download to bloom-filter based download?

Original comment by andreas....@gmail.com on 26 Sep 2013 at 11:13

GoogleCodeExporter commented 9 years ago 
Right, there should be some padding on the fast catchup time to handle the case 
of replay+clock drift.

Peers also export their local times, and bitcoind will cross-check your local 
clock against peer reported time. It'd be good if we did the same.

Original comment by hearn@google.com on 30 Sep 2013 at 8:27