< bitcoin-git>
[bitcoin] rebroad opened pull request #9719: Allow abortion of ConnectBlock() when shutdown requested. (master...AbortConnectBlockAtShutdown) https://github.com/bitcoin/bitcoin/pull/9719
< bitcoin-git>
[bitcoin] theuni opened pull request #9720: net: fix banning and disallow sending messages before receiving verack (master...fix-ban) https://github.com/bitcoin/bitcoin/pull/9720
< bitcoin-git>
[bitcoin] rebroad opened pull request #9721: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/9721
< udiWertheimer>
Hey, Udi from Colu here, maintainers of the coloredcoins.org protocol. We are looking to start devoting some dev time to contribute to Bitcoin Core (just wherever we can help, not related to colored coins development).
< Chris_Stewart_5>
udiWertheimer: Awesome!
< udiWertheimer>
first steps I'm thinking of is getting to know the project and helping with reviewing open pull requests, then probably look for small open issues to work on, or missing tests. wondered if you guys have any suggestions for getting started?
< achow101>
udiWertheimer: look through the PRs page and see what you can review. take a look at what the current issues are and see if there is anything you can do with some of the open issues.
< BlueMatt>
ok, so it looks like all the last-minute race testing is starting to clean up, but that means we need review to get 0.14 branched and rc1 out the door.... https://github.com/bitcoin/bitcoin/milestone/21 has the list, plus #9708 would be nice
< cfields>
BlueMatt: want me to just close 9695? as far as i can tell it's just a dupe now
< BlueMatt>
cfields: meh, whatever, the point of splitting them is in case people complain about the copies in 9708 we can just merge 9707 and deal with it separately
< luke-jr>
BlueMatt: could your size be rounded up based on filesystem overhead?
< BlueMatt>
luke-jr: unless ext4+du rounds up a shitload?
< BlueMatt>
i mean it is many files
< BlueMatt>
but I think the const should incl reasonable overhead in any case?
< luke-jr>
du --apparent-size ?
< BlueMatt>
du -hs
< luke-jr>
try with --apparent-size
< luke-jr>
also, is -h using SI or 1024-based?
< BlueMatt>
no idea
< sipa>
109 GiB here, or 117 GB
< BlueMatt>
heh, that would do it
< sipa>
including chainstate and undo data
< BlueMatt>
oh
< BlueMatt>
oh, yes
< sipa>
which we should include, i think
< sipa>
undo data is 10%
< luke-jr>
so = 120?
< sipa>
du by default is 1024-based, unless you pass --si
< BlueMatt>
yes, 120
< luke-jr>
sipa: note chainstate is a separate number used also when pruning is enabled
< sipa>
ok
< BlueMatt>
i mean whatever, just has to be reasonable rounded up
< BlueMatt>
120 sounds good
< BlueMatt>
fine
< sipa>
oh, my numbers exclude chainstate
< sipa>
sorry
< sipa>
but include undo data
< sipa>
120 sounds good
< luke-jr>
sipa: does -prune limit undo data?
< luke-jr>
I guess so
< sipa>
it also deletes undo data, yes
< sipa>
and the ratio between blocks and undo data is pretty much constant
< BlueMatt>
is it a supported feature that if you do a getmempoolentry/getrawmempool/etc and a transaction shows up which applies to your wallet, a later call (immediately thereafter) to getbalance will show the balance including that transaction?
< BlueMatt>
or is it only supported that sendrawtransaction followed by a getbalance/listtransactions/etc/etc will be consistent?