< 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?
< fanquake> progmag is there something missing that you think should be in there?
< fanquake> *promag
< fanquake> I've added some additional PRs
< meshcollider> fanquake: maybe #11708
< gribble> https://github.com/bitcoin/bitcoin/issues/11708 | Add P2SH-P2WSH support to signrawtransaction and listunspent RPC by MeshCollider · Pull Request #11708 · bitcoin/bitcoin · GitHub
< fanquake> meshcollider added
< cluelessperson> does the regtest mode not accept rpcport options?
< cluelessperson> or datadir?
< eck> it will use a datadir relative to the one you specify
< eck> actually i take that back
< cluelessperson> because with the regtest, it seems to be still using 8332 (which is taken)
< sipa> that seems wrong; the regtest default RPC port is 18443
< cluelessperson> 2017-12-29 07:31:05 Binding RPC on address port 8332 failed.
< sipa> then perhaps it's not actually in regtest mode?
< sipa> or you explicitly configured the port number?
< cluelessperson> sipa: at the top of "regtest.conf" is regtest=1
< sipa> regtest.conf?
< sipa> there is no such config file, unless you're explicitly configuring it with a -conf= command line argument
< sipa> generally you should specify the network on the command line
< cluelessperson> sipa: /var/bitcoin/bitcoind/source/bitcoin/src/bitcoind "-conf=/etc/bitcoind/regtest.conf"
< sipa> ah, ok!
< cluelessperson> :P
< sipa> i'm not sure you can change the network in the config file still, as usually the config file is only determined after choosing the network
< cluelessperson> sipa: it works for testnet=1 :P
< cluelessperson> sipa: /var/bitcoin/bitcoind/source/bitcoin/src/bitcoind "-conf=/etc/bitcoind/testnet.conf"
< sipa> interesting
< sipa> and regtest.conf does not contain any rpcport=8332 line?
< cluelessperson> I had an rpcport=18331, then I tried rpcport=28332, but then I removed it, same output, 8332
< cluelessperson> sipa: I'll try specifying it
< cluelessperson> sipa: yeah, so it DOES start in regtest most, but it completely ignores the conf
< cluelessperson> most/mode
< sipa> cluelessperson: very strange
< cluelessperson> sipa: to be clear, it seems regtest works when options are specified as arguments, but not when a conf file is given
< sipa> i can't imagine that's specific to regtest
< cluelessperson> sipa: https://hastebin.com/raw/seqacuneyu These unit files all work, except regtest
< cluelessperson> until I add -regtest in there on the ExecStart line
< sipa> what is the contents of those confog files?
< cluelessperson> sipa: https://hastebin.com/raw/xipacapexe
< sipa> cluelessperson: very curious
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
< 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?
< bitcoin-git> [bitcoin] sipa pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/5180a86c96bc...d9fdac130a5e
< bitcoin-git> bitcoin/master 818075a Matt Corallo: Create new mutex for orphans, no cs_main in PLV::BlockConnected...
< bitcoin-git> bitcoin/master 66aa1d5 Matt Corallo: Refactor ProcessGetData in anticipation of avoiding cs_main for ABC
< bitcoin-git> bitcoin/master a734896 Matt Corallo: Avoid cs_main in net_processing ActivateBestChain calls
< bitcoin-git> [bitcoin] sipa closed pull request #11824: Block ActivateBestChain to empty validationinterface queue (master...2017-12-11822-debug) https://github.com/bitcoin/bitcoin/pull/11824
< 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.
< bayatloo> Hi
< bayatloo> can i develop Bitcoin with c#
< provoostenator> bayatloo: https://github.com/MetacoSA/NBitcoin (though outside scope of this channel, I believe they use Gitter for chat)
< 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
< aj> that's a bcash block isn't it?
< provoostenator> That's an old one, but shouldn't it complain about the very first one, given the EDA?
< sipa> ossifrage: it's an invalid block, and your client is correctly rejecting it
< ossifrage> sipa, yeah, but it was forwarded to my by a node that also should have rejected it?
< provoostenator> Their first block was 478558, your log is about 478577. Not sure when their first EDA kicked in.
< sipa> ossifrage: it could be a bcash node you're connected to
< sipa> or a retarded node
< provoostenator> Nvm, their replay protection makes even the first block invalid. So why did your node not ban that other node when it got 478558?
< ossifrage> Most of the bad blocks are coming from /SuperBitcoin:
< ossifrage> and /SpuerBitcoin:
< provoostenator> Probably these guys: https://github.com/superbitcoin/SuperBitcoin/commits/master I wonder if they're doing anything worthy of #bitcoin-airdrop-code-shenanigans
< ossifrage> I'm more curious why nodes claiming to be Satoshi based are forwarding bad blocks
< Slackus> help I cannot speak on #bitcoin
< Slackus> i am +q
< Slackus> oh sorry nvm
< provoostenator> They currently use the same sighash_fork_id as bcash.
< provoostenator> What's the fastest EC2 configuration to an IBD? I was thinking about memory optimized r3.4xlarge with 320 GB SSD. sipa?
< provoostenator> (16 CPU's)
< jb55> I really need to set up distcc or something for testing prs :S my poor laptop is struggling
< provoostenator> jb55: ccache helps too
< jb55> provoostenator: oh nice I've never used that before, will give it a spin
< luke-jr> FYI, apparently ME neutering leaves the CPU with microcode-level vulnerabilities that compromise Qubes-like setups
< phantomcircuit> luke-jr, ?
< luke-jr> phantomcircuit: rumour from 24c3
< luke-jr> 34c3*
< provoostenator> It would be nice to be able to use sendrawtransaction during IBD, i.e. with some sort "don't check, just relay it"
< provoostenator> (I'm checking some replay protection behavior in airdrop coins, and rather not have to wait for those things to fully sync)
< bitcoin-git> [bitcoin] puchu opened pull request #12051: add missing debian contrib files to tarball (master...master) https://github.com/bitcoin/bitcoin/pull/12051
< sipa> provoostenator: use submittx
< tril> hey
< bitcoin-git> [bitcoin] cuckoocoin opened pull request #12052: 0.12 (0.11...0.12) https://github.com/bitcoin/bitcoin/pull/12052
< bitcoin-git> [bitcoin] fanquake closed pull request #12052: 0.12 (0.11...0.12) https://github.com/bitcoin/bitcoin/pull/12052
< provoostenator> sipa: thanks