<@wumpus>
this weekend I recovered a node that was crashing with database corruption errors (after, I think, a hard poweroff corrupted it - the log was padded with sudden \0\0\0\0\0\0) simply by deleting leveldb's .log file.
<@wumpus>
after that and restarted, the node succesfully picked up verification again, phew, no reindex
<@wumpus>
error was "error in middle of record" in log_reader
<@wumpus>
maybe such an automatic recovery would be possible in some cases, when only the log is corrupt and not any ldb files, it'd just amount to a rollback
< jnewbery>
provoostenator: Yes, agree that 4000 lines is probably too much log. I'd ACK a PR to reduce it. (counter argument is that this is only printed when a script fails, so we want as much logging as possible)
< jonasschnelli>
hmm... localhost p2p getblocks transfer rate up to block 250000 is roughly 70MB/s (SSD with usual rate of 300MB/s). Reasonable overhead.
<@wumpus>
jonasschnelli: any idea where the overhead is? the deserialize->serialize round trip?
<@wumpus>
or just 'random seeking and reading' wrt i/o, because this concerns such small blocks
< bitcoin-git>
bitcoin/master 67bf2aa Chun Kuan Lee: qt:Show the entire Window when double clicking on taskbar
< bitcoin-git>
bitcoin/master 8609ddb Wladimir J. van der Laan: Merge #12999: qt: Show the Window when double clicking the taskbar icon...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12999: qt: Show the Window when double clicking the taskbar icon (master...qt-fix) https://github.com/bitcoin/bitcoin/pull/12999
< Chris_Stewart_5>
If a node receives blocks in an order like: 1,2,4,3 (where 4 references previous block hash of 3) on the p2p network, will zmq relay 4 after it has successfully connected it with 3?
< sipa>
Chris_Stewart_5: no, it just notifies for new tips
< sipa>
as ZMQ is not reliable, you shouldn't use it as more than a notification service anyway
< sipa>
Chris_Stewart_5: actually, i think that can't happen
< sipa>
as we always fetch blocks in order
< Chris_Stewart_5>
sipa: Wouldn't 4 end up as the cannonical tip?
< sipa>
but a similar scenario can occur during a reorg
< sipa>
in which case ZMQ will just report the new tip after the reorg, and not the intermediary blocks (afaik, not entirely sure)
< Chris_Stewart_5>
so basically if there is a reorg that is like 6 blocks deep, you will just be notified of the new tip of that reorg, *not* all the intermittent blocks that happened in the reorg correct?
< skeees>
In the current state you'll be notified after every ActivateBestChainStep()
< skeees>
which will definitely give you the new tip
< skeees>
possibly some of the block in between, but not guaranteed every single one
< skeees>
the notifications will be pushed to zmq in order (i don't know what ordering guarantees zmq gives you though)
< Chris_Stewart_5>
skeees: Thanks! :-)
< sipa>
Chris_Stewart_5: you basically can't rely on ZMQ to relay you everything regardless
< sipa>
you can use it as a notification that there are new things you should look at (through rpc or rest)
< sipa>
(and IMHO it was a mistake to make it relay full blocks in the first place, as it confusingly gives you the impression it will give you everything)
< bitcoin-git>
[bitcoin] sipa opened pull request #13062: Make script interpreter independent from storage type CScript (master...201804_spaninterpret) https://github.com/bitcoin/bitcoin/pull/13062
< bitcoin-git>
[bitcoin] promag closed pull request #11402: Use shared pointer for wallet instances (master...2017-09-wallet-shared-pointer) https://github.com/bitcoin/bitcoin/pull/11402
< promag>
jnewbery: you might want to rebase on top of #13063
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #13065: Let travis to run verify-commits.sh without errors (master...verify-commits) https://github.com/bitcoin/bitcoin/pull/13065