00:07 < dx25> are there potentially license issues with porting bitcoin core code to other languages (e.g. bitcoinj with apache license)?

00:21 < echeveria> it's not a port.

01:59 < 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

02:00 < 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)

03:09 < dx25> luke-jr, was messing with supporting bech32 address format in bisq, which relies on bitcoinj

03:13 < sipa> dx25: there are some PRs to the bech32 ref code for java

03:13 < sipa> https://github.com/sipa/bech32

03:17 < dx25> ah cool

03:18 < FTBCraig> hi

04:37 < 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

04:38 < eklitzke> the single blue dashed line is where master currently flushes a ton of data

04:47 < sipa> eklitzke: interesting, what did you change?

04:49 < eklitzke> really hacky, but this is basically it https://github.com/eklitzke/bitcoin/compare/probes...eklitzke:leveldb_tweaks

04:50 < eklitzke> i need to get the fd limits down and fix some other stuff, but good enough for proof of concept

04:50 < sipa> eklitzke: my longer term plan was to have a background thread that continuously flushes sufficiently old entries

04:51 < eklitzke> this is basically just tuning some buffer sizes and leveldb settings

04:51 < sipa> instead of doing the flushing within the critical path of validation

04:52 < gmaxwell> eklitzke: you're backing out all the partial batching stuff, which indeed slows things down slightly but avoids high peak memory usage.

04:52 < eklitzke> the other nice thing about this branch is now my flushes are down to 100mb or so

04:52 < eklitzke> so my branch is actually using less memory than master

04:52 < eklitzke> gmaxwell: ah but i have the cache size set much smaller in the first place

04:53 < sipa> interesting, and it's still faster

04:53 < eklitzke> the overhead isn't from writing, it's reading the leveldb entries from disk

04:53 < gmaxwell> eklitzke: what are you bechmarking on?

04:53 < eklitzke> that's why you see the sharp dropoff in progress on master once it does its first flush

04:53 < eklitzke> gmaxwell: gcp n1-standard-1 host with the default crappy disk

04:54 < eklitzke> and dbcache=2048 in both cases

04:54 < gmaxwell> :(

04:54 < 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.)

04:55 < eklitzke> yeah i will measure on my laptop (which has an ssd), i don't think it will trash performance though

04:55 < eklitzke> i'll let you know when i've tested it more thoroughly

05:01 < gmaxwell> you may want to benchmark reindexes instead of actual IBDs to eliminate network variablity and delays from the results.

05:01 < eklitzke> i'm actually resting with -reindex-chainstate from a full node that was already synced

05:01 < gmaxwell> okay good!

05:38 < bitcoin-git> [bitcoin] PlentifulEarth opened pull request #12480: Pull Request #1 (master...master) https://github.com/bitcoin/bitcoin/pull/12480

05:39 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #12480: Pull Request #1 (master...master) https://github.com/bitcoin/bitcoin/pull/12480

05:43 < phantomcircuit> sipa, i couldn't see how you would do a partial flush without keeping track of which block height entries were modified at

05:48 < achow101> oh no, not this shit again: https://github.com/bitcoin/bitcoin/commits?author=satoshinnakamoto

05:48 < sipa> phantomcircuit: non-atomic flushing :)

05:49 < sipa> phantomcircuit: the on-disk format stores what the first and last block hash is that modification may have been written for

05:49 < sipa> at startup, the range between them is replayed

05:49 < sipa> phantomcircuit: https://github.com/bitcoin/bitcoin/pull/10148

06:09 < phantomcircuit> sipa, oh

06:09 < phantomcircuit> neat

07:13 < wumpus> rc4 binaries up https://bitcoincore.org/bin/bitcoin-core-0.16.0/test.rc4/

07:15 < Randolf> Thanks wumpus.

07:22 < wumpus> achow101: ughh, who's going to complain to github this time

07:27 < dongcarl> Probably not the best solution, but the easiest way without trusting GitHub is to link the email to the bitcoin org?

08:07 < realblockchainL> hello team

08:08 < realblockchainL> anyone online

15:00 < bitcoin-git> [bitcoin] Sjors opened pull request #12482: [tests] bind functional test nodes to 127.0.0.1 (master...2018/02/test-framework-bind) https://github.com/bitcoin/bitcoin/pull/12482

15:42 < achow101> wumpus: already started doing that

16:15 < anil> hello

16:22 < Randolf> Hello anil.

19:13 < anil> hello

20:49 < nman999> Could someone tell me how to get the BerkeleyDB 4.8 library installed in Debian Stretch?