Blockchain replay

[GoogleCodeExporter]

Hi,

I've quite a consistency problem with my wallet and my transactions.

I'm developing in eclipse + maven + tomcat and this combination doesn't support 
any 'graceful shutdown' for the tomcat. That means, the ContextListener 
destroyContext-Method is not execuded in order to save everything and shutdown 
nicely.

For this reason, it gives me a bad feeling to implement a thread which auto 
saves the wallet every e.g. 1s or so ...

Of course, I could delete the H2 database which stored the blockchain, but I 
have to restart quite often because I'm in active development, currently. 
Deleting the block-chain takes (in the bitcoin test-net) almost 5min.

I read some postings proposing there should be a blockchain replay feature and 
honestly, I don't understand why there isn't one yet.

Imho this is the only way to get a consistent start ... Initialize the wallet, 
clear all transactions and replay the complete chain which are stored at the H2 
database.

Are there any plans to implement such a feature?

If I did it myself, could someone give me tips where possible problems could be?

All the best,
Thomas

Original issue reported on code.google.com by shufp...@gmail.com on 20 Apr 2013 at 7:30

[GoogleCodeExporter]

Which particular case are you afraid of? You can save your wallet manually 
after important operations, like creating a key or signing a transaction. If 
the issue is that you need to shutdown during blockchain replay, bitcoinj 
should just repeat replay of any missed blocks. I say "should" because atm I 
think work on this is not completely finished.

Anyway, your setup is not that unusual. For example, Android apps can also be 
shutdown without prior notice, although its rare. So I agree bitcoinj should be 
prepared for this kind of situation.

Original comment by andreas....@gmail.com on 21 Apr 2013 at 9:26

[GoogleCodeExporter]

Yes, the H2 fully verifying block store is slow. For development you could just 
use SPV mode connected to a local Satoshi client, then it'll be much faster. 
You can always use the fully verifying mode in production, but because of its 
new/experimental status I'd suggest always connecting your app to a trusted 
Satoshi client and then SPV vs full doesn't matter much anymore.

The reason for the auto-save delays are that when you're catching up with the 
chain the wallet can change very quickly and re-serializing it to disk every 
time is slow, so it can become the bottleneck on slow devices like phones. What 
you could do instead is use autoSave mode with a timeout of zero. Then any time 
the wallet changes it will be serialized and saved to disk automatically, not 
on a background thread.

It should reduce your problems a lot. However remember that bitcoinj is not 
really designed for servers. It is designed for smart phones, and that's always 
been my priority and it will stay that way for a while. If you want to use it 
in a server-side app, be prepared to send me patches ;) Jim Burton has 
implemented a ReplayManager for MultiBit, I suppose you could start by looking 
at how that works. Automatically replaying wallets that are behind would be a 
great feature but it's not quite so trivial to support.

Original comment by hearn@google.com on 22 Apr 2013 at 10:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just wanted to inform you that the issue could be closed. I decided to go 
with the original satoshi client because it does - after submitting one patch 
to the project - what I need for reliably receiving transactions. Moreover, 
it's the reference software and it runs detached from my tomcat-instance which 
makes some things clearer to me.

Thank you for your help!

Original comment by shufp...@gmail.com on 1 May 2013 at 8:24

[GoogleCodeExporter]

Sounds good. I'll close this because automatically syncing wallets and chain 
files if killed processes cause them to get out of sync is a feature that's 
requested elsewhere in the bug tracker already. It just hasn't been the top 
priority for smartphone clients.

Original comment by hearn@google.com on 2 May 2013 at 9:43

• Changed state: WontFix