< dx25> are there potentially license issues with porting bitcoin core code to other languages (e.g. bitcoinj with apache license)?
< echeveria> it's not a port.
< luke-jr> dx25: there aren't really many possible license issues with MIT license in the first place; literally all you need to do is keep the copyright notices and not steal credit XD
< luke-jr> dx25: (and as echeveria correctly pointed out, your example is wrong since bitcoinj is not a port at all; also note it is completely insecure to rely on by itself)
< dx25> luke-jr, was messing with supporting bech32 address format in bisq, which relies on bitcoinj
< sipa> dx25: there are some PRs to the bech32 ref code for java
< dx25> ah cool
< FTBCraig> hi
< eklitzke> sipa: this is somewhat preliminary, but this is how my branch that changes how ccoinscacheview works is looking (the dashed lines are flush events): https://monad.io/ibd.png
< eklitzke> the single blue dashed line is where master currently flushes a ton of data
< sipa> eklitzke: interesting, what did you change?
< eklitzke> really hacky, but this is basically it https://github.com/eklitzke/bitcoin/compare/probes...eklitzke:leveldb_tweaks
< eklitzke> i need to get the fd limits down and fix some other stuff, but good enough for proof of concept
< sipa> eklitzke: my longer term plan was to have a background thread that continuously flushes sufficiently old entries
< eklitzke> this is basically just tuning some buffer sizes and leveldb settings
< sipa> instead of doing the flushing within the critical path of validation
< gmaxwell> eklitzke: you're backing out all the partial batching stuff, which indeed slows things down slightly but avoids high peak memory usage.
< eklitzke> the other nice thing about this branch is now my flushes are down to 100mb or so
< eklitzke> so my branch is actually using less memory than master
< eklitzke> gmaxwell: ah but i have the cache size set much smaller in the first place
< sipa> interesting, and it's still faster
< eklitzke> the overhead isn't from writing, it's reading the leveldb entries from disk
< gmaxwell> eklitzke: what are you bechmarking on?
< eklitzke> that's why you see the sharp dropoff in progress on master once it does its first flush
< eklitzke> gmaxwell: gcp n1-standard-1 host with the default crappy disk
< eklitzke> and dbcache=2048 in both cases
< gmaxwell> :(
< gmaxwell> I expect your changes trash performance on anything that isn't IO starved. (FWIW, I complete a IBD sync in 3.5 hours here.)
< eklitzke> yeah i will measure on my laptop (which has an ssd), i don't think it will trash performance though
< eklitzke> i'll let you know when i've tested it more thoroughly
< gmaxwell> you may want to benchmark reindexes instead of actual IBDs to eliminate network variablity and delays from the results.
< eklitzke> i'm actually resting with -reindex-chainstate from a full node that was already synced
< gmaxwell> okay good!
< bitcoin-git> [bitcoin] PlentifulEarth opened pull request #12480: Pull Request #1 (master...master) https://github.com/bitcoin/bitcoin/pull/12480
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12480: Pull Request #1 (master...master) https://github.com/bitcoin/bitcoin/pull/12480
< phantomcircuit> sipa, i couldn't see how you would do a partial flush without keeping track of which block height entries were modified at
< sipa> phantomcircuit: non-atomic flushing :)
< sipa> phantomcircuit: the on-disk format stores what the first and last block hash is that modification may have been written for
< sipa> at startup, the range between them is replayed
< phantomcircuit> sipa, oh
< phantomcircuit> neat
< Randolf> Thanks wumpus.
< wumpus> achow101: ughh, who's going to complain to github this time
< dongcarl> Probably not the best solution, but the easiest way without trusting GitHub is to link the email to the bitcoin org?
< realblockchainL> hello team
< realblockchainL> anyone online
< bitcoin-git> [bitcoin] Sjors opened pull request #12482: [tests] bind functional test nodes to (master...2018/02/test-framework-bind) https://github.com/bitcoin/bitcoin/pull/12482
< achow101> wumpus: already started doing that
< anil> hello
< Randolf> Hello anil.
< anil> hello
< nman999> Could someone tell me how to get the BerkeleyDB 4.8 library installed in Debian Stretch?