Re: Issue 256 in bitcoinj: skip initial download to blockchain checkpoints

[bitc...@googlecode.com]

Updates:
Summary: skip initial download to blockchain checkpoints

Comment #3 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Just checked how long intial setup would take if it is running on a decent
platform like my 2 core development machine (Intel CPU, Ubuntu 12.10 on
SSD) using wallet-tool. Outcome: nearly 2 hours.

Is there anything we can do to improve this substantially besides
implementing skipping download to checkpoints?

[bitc...@googlecode.com]

Comment #4 on issue 256 by he...@google.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Huh? Was that with full verification switched on or something?

Doing a full getheaders sync should take much, much less than two hours if
conditions are good. It may be that you were connected to a slow node.

[bitc...@googlecode.com]

Comment #5 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

I was using

java -Xmx4g -server -jar target/bitcoinj-tools-0.7-SNAPSHOT.jar
--action=CREATE

followed by

java -Xmx4g -server -jar target/bitcoinj-tools-0.7-SNAPSHOT.jar
--action=SYNC

Now, I'm running a second try with an added --mode=SPV, but frankly it does
not look like it's running much faster, if at all.

[bitc...@googlecode.com]

Comment #6 on issue 256 by he...@google.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Could you run with --debuglog and show us the speeds you're getting/peers
you're connecting to?

Syncing all headers like that requires downloading 16mb of data and doing a
few hashes, a few disk writes. I haven't timed it lately, but 2 hours is
way too long unless you're on a really crappy connection or connected to a
really slow node.

How fast does it sync if you run with --peers=127.0.0.1 and connect to a
local synced bitcoin-qt instance?

[bitc...@googlecode.com]

Comment #7 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Syncing without --peers yields about 50-150 blocks per second (in the
2009,2010 era of the block chain). So it would take at least 35 minutes. I
suspect numbers to be much lower from 2011 on.

Trying to sync with --peers=127.0.0.1 does not work, it looks like it does
not try to connect, according to ~/.bitcoin/debug.log. I can telnet
127.0.0.1 8333 however, so bitcoin-qt would accept connections.

[bitc...@googlecode.com]

Comment #8 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Perhaps the wallet is saving too often. It appears its saving 4-5 times a
second. Bitcoin Wallet saves only once a second.

Why is it saving at all? Just to record the current chain height?

[bitc...@googlecode.com]

Comment #9 on issue 256 by he...@google.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

50-150 blocks per second implies you aren't using getheaders, I think. I
wonder if fast catchup is broken in the case where there are no keys. Could
you try adding a key, deleting the chain file and trying again?

Maybe I broke --peers in the single peer case. I'll look soon.

Yes, the wallet contains the last chain height it saw. When transactions
are changing it's more important to save often. The whole auto-save system
is unsatisfying in many ways though. It can certainly be improved.

[bitc...@googlecode.com]

Comment #10 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

I think it would be a good idea to enhance the following debug log output
to include downloadBlockBodies:

log.info("{}: blockChainDownload({}) current head = {} downloadBlockBodies
= {}", new Object[] { toString(), toHash.toString(),
chainHead.getHeader().getHashAsString(), downloadBlockBodies });

And no, I'm not downloading block bodies. Doesn't matter if I have 0 or 1
key in my wallet.

[bitc...@googlecode.com]

Comment #11 on issue 256 by he...@google.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

I used to see 1000-2000 blocks per second when using getheaders. I'll
re-profile some time. Anyway yes, allowing disconnected chains is important
but it won't be in for 0.7 .... a project for later.

[bitc...@googlecode.com]

Comment #12 on issue 256 by andreas....@gmail.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

Just opened issue 271 for the bug in PeerGroup.addAddress(), which breaks
--peers.

However, now I'm connected to localhost and still only get 200 blocks/s for
the early era.

[bitc...@googlecode.com]

Updates:
Status: Fixed
Owner: he...@google.com

Comment #14 on issue 256 by he...@google.com: skip initial download to
blockchain checkpoints
http://code.google.com/p/bitcoinj/issues/detail?id=256

This is now possible, but you have to opt in with CheckpointManager

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings