Log block hash in AcceptBlockHeader.
Right now, it is a bit hard to sync on plain testnet. This helped debugging.
Log block hash in AcceptBlockHeader.
Right now, it is a bit hard to sync on plain testnet. This helped debugging.
FYI: right now, the current master is not able to sync on plain testnet with
ERROR: AcceptBlockHeader: block 00000000000005354772cb50ea2decd1e9176724c41eb3427197943aea33194e is marked invalid
This is block 787391 (https://www.blocktrail.com/tBTC/block/00000000000005354772cb50ea2decd1e9176724c41eb3427197943aea33194e).
Yep, I noticed that testnet is forked too. Looks like the CSV fork activated and the 0.12.1 clients followed a different chain when block=00000000000005354772cb50ea2decd1e9176724c41eb3427197943aea33194e height=787391 encountered "ERROR: ConnectBlock: contains a non-BIP68-final transaction". The 0.12.1 chain is longer height wise, but has lower work so the older clients reject it right now. That wasn't the case last night. Last night, my client was not sync'ing to the most work chain because it was hitting the "Large reorg, won't direct fetch to ..." case in the headers message processing. That I thought was kind of interesting from the standpoint of what would happen if SPV mining created a bad chain 17 or so blocks long in production. My node seemed stuck at that point, just sitting there not really doing anything.
test ACK. before and after (from testnet):
2016-04-28 01:27:26 ERROR: AcceptBlockHeader: block is marked invalid
2016-04-28 01:32:43 ERROR: AcceptBlockHeader: block 00000000000005354772cb50ea2decd1e9176724c41eb3427197943aea33194e is marked invalid
utACK 61c0170
utACK.
utACK 61c0170