< meshcollider>
warren: translation fixes have to be done on transifex, could you let them know so they can make an account there and join the (German?) translation team?
< aj>
cluelessperson: your regtest.conf doesn't have a -rpcallowip setting? that'll make it ignore rpcbind
< aj>
cluelessperson: hmm, i get similar behaviour switching from cmd line args to -conf though, weird
< provoostenator>
Hooray, QT was using 37 GB RAM again during index (dbcache=5000). It was using 18 threads. I'll cherry-pick #11824 to see if that helps.
< aj>
cluelessperson: hmm, no i don't; i only get dodgy behaviour when bitcoind doesn't see my conffile; is /etc/bitcoind/regtest.conf unreadable by the bitcoind user maybe?
< provoostenator>
This is also the second time that it completely redownloads the blockchain after I force-quit during an re-index. In this case I had copied the blocks folder over from a backup and that files are still there. It turns out you really have to launch with -reindex=1, or I guess it won't even look for those files?
< provoostenator>
Reindexing again now with that potential fix branch, I'll keep an eye on it.
< xiedeacc>
what's CCoinsViewDB::GetHeadBlocks for? I have google a lot, there exists little information
< xiedeacc>
159
< xiedeacc>
160 //! Retrieve the range of blocks that may have been only partially written.
< xiedeacc>
161 //! If the database is in a consistent state, the result is the empty vector.
< xiedeacc>
162 //! Otherwise, a two-element vector is returned consisting of the new and
< xiedeacc>
163 //! the old block hash, in that order.
< xiedeacc>
confused with this comment
< meshcollider>
cluelessperson: does your debug.log have a "Using config file regtest.conf" line, just to confirm its reading the right file?
< echeveria>
provoostenator: force quitting while syncing will cause you problems, you should expect that.
< provoostenator>
I did have to replace blocks/blk00000.dat with the backup, because that got overridden when I relaunched without -reindex. echeveria: I know, but there's not much else you can do if your system need 5 minutes just to wake up the screen because some application decided to OOM :-)
< provoostenator>
(well actually, not OOM)
< sipa>
xiedeacc: i saw you also asked this on stackexchange; i will answer there
< xiedeacc>
ok thanks a lot
< sipa>
provoostenator: it's expectes that your node needs to redo the work since the last flush, and with large dbcache flushing is very infrequwnt - so that may mean redoing frok scratch
< bitcoin-git>
[bitcoin] martinus opened pull request #12048: Use best-fit strategy in Arena, now O(log(n)) instead O(n) (master...faster_arena) https://github.com/bitcoin/bitcoin/pull/12048
< provoostenator>
sipa: that would explain re-indexing from scratch, right? But why does it start restart the whole chain download?
< sipa>
provoostenator: because its knowledge about what blocks it has on disk is part of the flush
< sipa>
perhaps that can be improved though
< provoostenator>
Could it check to see if any block****.dat files are present?
< sipa>
we could flush the block index more frequently than the chainstate
< provoostenator>
Maybe when you launch with -reindex, it should do a quick flush at the beginning?
< provoostenator>
Because I don't mind it doing the index again, I just don't want it to do a full download just because I forgot to pass -reindex=1
< sipa>
provoostenator: you're right
< provoostenator>
Mmm, actually I only copied the block****.dat files over, which I'm guess don't include the headers. So the fact that it's downloading the headers might be unlreated. Although when I start with -reindex=1 it reindexes first and then downloads the headers, whereas when I launched without that flag it immedidately fetches the headers.
< sipa>
provoostenator: the index is in blocks/index/
< sipa>
without that, you'll need reindex to scan for blocks that you may have that aren't in the index
< provoostenator>
Oh ok, nvm, I deleted that the second time around.
< provoostenator>
So first time I copied /blocks including index, ran -reindex=1 until it ran out of memory. I then restarted without -reindex and it began downloading headers. I then deleted the index subdirectory and restored blcok00001.dat from my backup (but didn't restore index from that backup). It then reindexed and now it's downloading headers.
< provoostenator>
(using -reindex=1 in that last attempt)
< provoostenator>
Regarding our discussion a few days ago around Lightning implementations needing txindex=1. Turns out c-lightning doesn't, LND found a way to avoid needing it when using RPC and that bitcoind already doesn't need it when using the neutrino protocol: https://github.com/lightningnetwork/lnd/issues/527
< provoostenator>
So no urgent need to make txindex faster, work with pruned nodes, or find some other RPC workaround to help these lightning integrations afaik. Haven't talked to Eclair yet.
< bitcoin-git>
[bitcoin] 251Labs opened pull request #12050: Implements a virtual destructor on the BaseRequestHandler class. (master...patch/BaseRequestHandler-virtual-dtor) https://github.com/bitcoin/bitcoin/pull/12050
< ossifrage>
Any idea what fork is causing this leakage: ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000000000000000000639be19a0123a1c99d9fef89f0b8ac055a77f4ef86ae3b, bad-diffbits, incorrect proof of work (code 16)
< ossifrage>
[I have 102 of those in my logs]
< ossifrage>
Huh, the most recent one came from a node claiming to be 0.15.1