1 2018-02-19 00:07:31	0|dx25|are there potentially license issues with porting bitcoin core code to other languages (e.g. bitcoinj with apache license)?
 2 2018-02-19 00:21:55	0|echeveria|it's not a port.
 3 2018-02-19 01:59:35	0|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
 4 2018-02-19 02:00:42	0|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)
 5 2018-02-19 03:09:44	0|dx25|luke-jr, was messing with supporting bech32 address format in bisq, which relies on bitcoinj
 6 2018-02-19 03:13:24	0|sipa|dx25: there are some PRs to the bech32 ref code for java
 7 2018-02-19 03:13:37	0|sipa|https://github.com/sipa/bech32
 8 2018-02-19 03:17:11	0|dx25|ah cool
 9 2018-02-19 03:18:14	0|FTBCraig|hi
10 2018-02-19 04:37:42	0|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
11 2018-02-19 04:38:08	0|eklitzke|the single blue dashed line is where master currently flushes a ton of data
12 2018-02-19 04:47:33	0|sipa|eklitzke: interesting, what did you change?
13 2018-02-19 04:49:41	0|eklitzke|really hacky, but this is basically it https://github.com/eklitzke/bitcoin/compare/probes...eklitzke:leveldb_tweaks
14 2018-02-19 04:50:03	0|eklitzke|i need to get the fd limits down and fix some other stuff, but good enough for proof of concept
15 2018-02-19 04:50:54	0|sipa|eklitzke: my longer term plan was to have a background thread that continuously flushes sufficiently old entries
16 2018-02-19 04:51:14	0|eklitzke|this is basically just tuning some buffer sizes and leveldb settings
17 2018-02-19 04:51:24	0|sipa|instead of doing the flushing within the critical path of validation
18 2018-02-19 04:52:01	0|gmaxwell|eklitzke: you're backing out all the partial batching stuff, which indeed slows things down slightly but avoids high peak memory usage.
19 2018-02-19 04:52:07	0|eklitzke|the other nice thing about this branch is now my flushes are down to 100mb or so
20 2018-02-19 04:52:17	0|eklitzke|so my branch is actually using less memory than master
21 2018-02-19 04:52:37	0|eklitzke|gmaxwell: ah but i have the cache size set much smaller in the first place
22 2018-02-19 04:53:14	0|sipa|interesting, and it's still faster
23 2018-02-19 04:53:26	0|eklitzke|the overhead isn't from writing, it's reading the leveldb entries from disk
24 2018-02-19 04:53:43	0|gmaxwell|eklitzke: what are you bechmarking on?
25 2018-02-19 04:53:46	0|eklitzke|that's why you see the sharp dropoff in progress on master once it does its first flush
26 2018-02-19 04:53:55	0|eklitzke|gmaxwell: gcp n1-standard-1 host with the default crappy disk
27 2018-02-19 04:54:06	0|eklitzke|and dbcache=2048 in both cases
28 2018-02-19 04:54:11	0|gmaxwell|:(
29 2018-02-19 04:55:00	0|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.)
30 2018-02-19 04:55:22	0|eklitzke|yeah i will measure on my laptop (which has an ssd), i don't think it will trash performance though
31 2018-02-19 04:55:39	0|eklitzke|i'll let you know when i've tested it more thoroughly
32 2018-02-19 05:01:04	0|gmaxwell|you may want to benchmark reindexes instead of actual IBDs to eliminate network variablity and delays from the results.
33 2018-02-19 05:01:30	0|eklitzke|i'm actually resting with -reindex-chainstate from a full node that was already synced
34 2018-02-19 05:01:35	0|gmaxwell|okay good!
35 2018-02-19 05:38:47	0|bitcoin-git|[13bitcoin] 15PlentifulEarth opened pull request #12480: Pull Request #1 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12480
36 2018-02-19 05:39:36	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #12480: Pull Request #1 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12480
37 2018-02-19 05:43:00	0|phantomcircuit|sipa, i couldn't see how you would do a partial flush without keeping track of which block height entries were modified at
38 2018-02-19 05:48:27	0|achow101|oh no, not this shit again: https://github.com/bitcoin/bitcoin/commits?author=satoshinnakamoto
39 2018-02-19 05:48:42	0|sipa|phantomcircuit: non-atomic flushing :)
40 2018-02-19 05:49:03	0|sipa|phantomcircuit: the on-disk format stores what the first and last block hash is that modification may have been written for
41 2018-02-19 05:49:17	0|sipa|at startup, the range between them is replayed
42 2018-02-19 05:49:49	0|sipa|phantomcircuit: https://github.com/bitcoin/bitcoin/pull/10148
43 2018-02-19 06:09:16	0|phantomcircuit|sipa, oh
44 2018-02-19 06:09:17	0|phantomcircuit|neat
45 2018-02-19 07:13:29	0|wumpus|rc4 binaries up https://bitcoincore.org/bin/bitcoin-core-0.16.0/test.rc4/
46 2018-02-19 07:15:28	0|Randolf|Thanks wumpus.
47 2018-02-19 07:22:38	0|wumpus|achow101: ughh, who's going to complain to github this time
48 2018-02-19 07:27:44	0|dongcarl|Probably not the best solution, but the easiest way without trusting GitHub is to link the email to the bitcoin org?
49 2018-02-19 08:07:30	0|realblockchainL|hello team
50 2018-02-19 08:08:42	0|realblockchainL|anyone online
51 2018-02-19 15:00:40	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #12482: [tests] bind functional test nodes to 127.0.0.1 (06master...062018/02/test-framework-bind) 02https://github.com/bitcoin/bitcoin/pull/12482
52 2018-02-19 15:42:02	0|achow101|wumpus: already started doing that
53 2018-02-19 16:15:24	0|anil|hello
54 2018-02-19 16:22:59	0|Randolf|Hello anil.
55 2018-02-19 19:13:39	0|anil|hello
56 2018-02-19 20:49:58	0|nman999|Could someone tell me how to get the BerkeleyDB 4.8 library installed in Debian Stretch?