< gmaxwell>
I expect most of the work related to my NBD suggestion will be discovering that all filesystems are broken, and being unable to get results against bitcoin until the file systems are fixed. :(
< GitHub21>
[bitcoin] laanwj opened pull request #6917: leveldb: Win32WritableFile without memory mapping (master...2015_10_leveldb_win_nomap) https://github.com/bitcoin/bitcoin/pull/6917
< GitHub118>
[bitcoin] sipa closed pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< GitHub92>
[bitcoin] sipa opened pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< wumpus>
and not sure bitcoin core should be resilient to motherboard-bends-while-application-is-running crashes :-)
< wumpus>
cfields: what would be the best way to include the windows determinism postprocessing in the gitian build (in https://github.com/bitcoin/bitcoin/pull/6900) - call it from the descriptor or 'make'?
< GitHub7>
[bitcoin] sdaftuar opened pull request #6915: [Mempool] Improve removal of invalid transactions after reorgs (master...fix-reorg-handling) https://github.com/bitcoin/bitcoin/pull/6915
< GitHub139>
[bitcoin] sipa opened pull request #6914: [WIP] Add pre-allocated vector type and use it for CScript (master...prevector) https://github.com/bitcoin/bitcoin/pull/6914
< gmaxwell>
Seperate subject; https://github.com/bitcoin/bitcoin/pull/6902 I feel that changes like this make the software more opaque. Now to understand whats being done there you must read two places instead of one. If you only look at policy.h you will likely erroniously believe it applies to p2sh somehow.
< gmaxwell>
warren: it's all ugly, bitcoin core is currently not intended for system level operation.
< gmaxwell>
warren: what happens if a second datadir is specified to bitcoin-cli?
< warren>
Would it be bad if the system-level systemd service were named something like bitcoinsys.service, with a selinux context bitcoinsys_t, and a bitcoin-cli wrapper named something like /usr/bin/bitcoinsys_cli that only adds the --datadir /path/to/system/datadir/
< gmaxwell>
warren: as far as selinux policy, I think it's unfortunate that you cannot confine bitcoin core to have no access outside of its own directory.
< gmaxwell>
warren: this channel should be for bitcoin core exclusive discussion.
< GitHub7>
[bitcoin] MarcoFalke reopened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
< GitHub107>
[bitcoin] jtimon opened pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
< GitHub71>
[bitcoin] jtimon opened pull request #6907: Chainparams: Use a regular factory for creating chainparams (master...chainparams-factory-0.12.99) https://github.com/bitcoin/bitcoin/pull/6907
< wumpus>
right it's the minimum *per KB*, all fees in bitcoin core are per kB
< sipa>
but it was somehow part of the wider bitcoin irc meeting, which took place in #bitcoin-dev an hour ago
< wumpus>
this channel has a very narrow scope: code changes to the bitcoin core project
< MarcoFalke>
Do those channels have different scopes? I remember bitcoin-dev is deprecated?
< jgarzik>
already covered in #bitcoin-dev meeting
< GitHub171>
[bitcoin] MarcoFalke closed pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
< GitHub81>
[bitcoin] gmaxwell opened pull request #6906: Reject invalid pubkeys when reading ckey items from the wallet. (master...ckey_pubkey_check) https://github.com/bitcoin/bitcoin/pull/6906
< GitHub129>
[bitcoin] MarcoFalke opened pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
< GitHub33>
[bitcoin] dajohi opened pull request #6902: policy: Add new constant MAX_STANDARD_MULTISIG_KEYS (master...multisig_keys) https://github.com/bitcoin/bitcoin/pull/6902
< wumpus>
majority plays no role in bitcoin - if *your* node forks from the block chain, that's a risk to you
< mcelrath>
Is bitcoin anymore consensus-dependent on leveldb? If we swap it out with sqlite or lmdb, will it still be consensus critical? (and can it be made non-consensus critical?)
< dcousens>
I can put bitcoin-qt on a old gaming rig if necessary, have to dust it off a little but, if its worth it
< CodeShark>
I don't really fricking care, personally - I don't really run a bunch of bitcoin core instances on windows - I'm just repeating what I've heard from others
< wumpus>
I don't want to hear "leveldb is broken on windows" every day, this is not tea time with bitcoin-dev, we should be constructive here
< Luke-Jr>
dcousens: #bitcoin maybe?
< bsm117532>
Quick git question...I did a push -f to overwrite my previous commit, because I like having clean histories. I could have also made a second commit on this PR. Does anyone care? Would github have squashed them anyway? (Re: https://github.com/bitcoin/bitcoin/pull/6899 )
< bsm117532>
That's a very hard problem that I don't think bitcoin can solve by choice of db.
< sipa>
bsm117532: jeff has a branch with bitcoin core running on sqlite3
< sipa>
if we need to change something to our leveldb tree, the correct way is submit it as a PR to the bitcoin/leveldb repo, and then bitcoin core can update to a new version
< bsm117532>
AFAICT, when I clone bitcoin, I don't get the bitcoin/leveldb repo. I get bitcoin/src/leveldb which is entirely separate. Am I wrong about that?
< gmaxwell>
aj: rethinking this resulted in coming up with the seggregated witness approach thats in elements alpha, and which may be possible to soft-fork into bitcoin.
< gmaxwell>
aj: well they're one in the same in Bitcoin Core; these changes are accomplished via validation flags. To make them non-standard we add the new restrictions to the set of flags used to verify transactions going into the mempool.
< GitHub73>
[bitcoin] sipa closed pull request #6776: Support -checkmempool=N, which runs checks once every N transactions (master...fraccheck) https://github.com/bitcoin/bitcoin/pull/6776
< GitHub163>
[bitcoin] giacecco closed pull request #6885: Instructions on how to make the Homebrew OpenSSL headers visible... (master...master) https://github.com/bitcoin/bitcoin/pull/6885
< GitHub176>
[bitcoin] Diapolo opened pull request #6893: forward-declare univalue in rpcclient + remove include in rpcserver.cpp (master...univalue) https://github.com/bitcoin/bitcoin/pull/6893
< wumpus>
2GB should certainly be enough. See e.g. https://github.com/bitcoin/bitcoin/issues/6658 , worst contender main.cpp uses 1.2MB while compiling (on gcc 4.8). Adding swap may help though, linux' memory management works better if swap is enabled even if you don't need the extra memory
2015-10-26
< GitHub108>
[bitcoin] laanwj closed pull request #6881: Debug: Add option for microsecond precision in debug.log (master...add-microsecond-timestamps) https://github.com/bitcoin/bitcoin/pull/6881
< GitHub138>
bitcoin/master 7bbc7c3 Suhas Daftuar: Add option for microsecond precision in debug.log
< GitHub138>
bitcoin/master 2b62551 Wladimir J. van der Laan: Merge pull request #6881...
< GitHub52>
bitcoin/master 143d173 Eric Lombrozo: Use BOOST_CHECK_MESSAGE() rather than BOOST_CHECK() in alerts_tests.cpp and initialize strMiscWarning before calling PartitionCheck()."
< gmaxwell>
(a failure to make this optimization is part of what contributes to miners mining on other miners work without validating-- they go and 'optimize' at a layer higher than Bitcoin, and as a resut complex details like validation go out the window. :) )
< GitHub175>
[bitcoin] jonasschnelli opened pull request #6889: fix locking issue with new mempool limiting (master...2015/10/fix_mempool_lock) https://github.com/bitcoin/bitcoin/pull/6889
< GitHub161>
[bitcoin] laanwj closed pull request #6566: BIP-113: Mempool-only median time-past as endpoint for lock-time calculations (master...medianpasttimelock) https://github.com/bitcoin/bitcoin/pull/6566
< GitHub168>
bitcoin/master ff057f4 Wladimir J. van der Laan: Merge pull request #6566...
< GitHub168>
bitcoin/master dea8d21 Mark Friedenbach: Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints...
< GitHub168>
bitcoin/master 9d55050 Mark Friedenbach: Add rules--presently disabled--for using GetMedianTimePast as endpoint for lock-time calculations...
< GitHub173>
[bitcoin] laanwj closed pull request #6813: Support gathering code coverage data for RPC tests with lcov (master...btc-test-lcov-rpc) https://github.com/bitcoin/bitcoin/pull/6813
< GitHub137>
bitcoin/master 8e3a27b dexX7: Require Python for RPC tests, when using lcov...
< GitHub137>
bitcoin/master d425877 dexX7: Remove coverage and test related files, when cleaning up...
< GitHub137>
bitcoin/master 4d2a926 dexX7: Ignore coverage data related and temporary test files
< jcorgan>
somehow i had restored a snapshot of bitcoin dir that only had 183k blocks in it
< wumpus>
unbatched? hmm, doing a sqlite transaction per bitcoin transaction is certainly going to kill sqlite performance
< wumpus>
after running a while, bitcoin-shutoff is taking a long time in sqlite3_close - possibly due to the lack of checkpoints
< jgarzik>
wumpus, One concern with the current implementation is the 'ORDER BY' - a sort - in the CDBIterator class. Once fully sync'd to current bitcoin block height, failing to store in an always-sorted container may create lumpy bitcoind behavior whenever CDBIterator is used... maybe.
< GitHub65>
[bitcoin] giacecco opened pull request #6885: Instructions on how to make the Homebrew OpenSSL headers visible... (master...master) https://github.com/bitcoin/bitcoin/pull/6885
< BlueMatt>
sipa: indeed, not sure what phantomcircuit is seeing is unexpected or not, but the graphs in the ml related to https://github.com/bitcoin/bitcoin/issues/6876 are not expected at all
< phantomcircuit>
while true;do bitcoin-cli getblocktemplate > /dev/null;done
2015-10-23
< jgarzik>
cfields, a DNS seed can build a picture of bitcoin users etc.
< GitHub95>
[bitcoin] btcdrak opened pull request #6884: Backport #6566, median-past locktime, rebased against 0.11 (0.11...mpl-0.11) https://github.com/bitcoin/bitcoin/pull/6884
< GitHub65>
[bitcoin] petertodd opened pull request #6883: Add BIP65 CHECKLOCKTIMEVERIFY to release notes (master...cltv-release-notes-v0.12.0) https://github.com/bitcoin/bitcoin/pull/6883
< maaku>
I am leaving bitcoin core development for a while, not sure how long. If someone wants to take over pushing for #6312, #6564, and #6566 please contact me.
< GitHub0>
[bitcoin] sdaftuar opened pull request #6881: Debug: Add option for microsecond precision in debug.log (master...add-microsecond-timestamps) https://github.com/bitcoin/bitcoin/pull/6881
< GitHub54>
[bitcoin] gavinandresen closed pull request #6880: New -logtimerelative option to do millisec debug.log timestamps (master...millisec_debuglog) https://github.com/bitcoin/bitcoin/pull/6880
< GitHub199>
[bitcoin] gavinandresen opened pull request #6880: New -logtimerelative option to do millisec debug.log timestamps (master...millisec_debuglog) https://github.com/bitcoin/bitcoin/pull/6880
< GitHub136>
[bitcoin] laanwj opened pull request #6877: rpc: Add maxmempool and effective min fee to getmempoolinfo (master...2015_10_mempool_effective_fee) https://github.com/bitcoin/bitcoin/pull/6877
< jgarzik>
jcorgan, naming? 2015_sqlite branch should not include any leveldb naming in the bitcoin->sqlite path. it _does_ build leveldb. it _does not_ link leveldb to bitcoind.
< GitHub159>
[bitcoin] jgarzik opened pull request #6873: [cleanup] leveldbwrapper becomes more generic 'dbwrapper' module (master...2015_dbwrapper) https://github.com/bitcoin/bitcoin/pull/6873
2015-10-22
< GitHub51>
[bitcoin] TheBlueMatt opened pull request #6872: Remove UTXO cache entries when the tx they were added for is removed/does not enter mempool (master...limitucache) https://github.com/bitcoin/bitcoin/pull/6872
< sipa>
jonasschnelli: if only we didn't have this pesky economy thing that relies on bitcoin
< jonasschnelli>
sipa: that sounds perfect for our bitcoin <1.0 version. :)
< gmaxwell>
jonasschnelli: yes, testing bitcoin core using <alternative database> :P it shouldn't be that much work; presumably jeff will report back on that soon
< gavinandresen>
a bug bounty worked for the last leveldb corruption issue we had (if i recall correctly). I'm still holding some bitcoin in the core dev expenses fund
< jonasschnelli>
Luke-Jr: the idea would be to bundle bitcoin-qt/core on windows together with vbox and a tiny distro. This would eliminate some ugly platform dependents.
< jonasschnelli>
serious: what would be the overhead to run bitcoin-qt/core in a vm on windows?
< gmaxwell>
I believe more people have stopped running bitcoin core on windows than currently run it.
< gmaxwell>
jonasschnelli: I think it would be a bad idea, its a very widely used platform and dropping it would be a major move against the ability of people to independnantly run, audit, etc. the bitcoin system.
< maaku>
i thought gmaxwell was declaring sipa a risk to bitcoin there
< GitHub122>
[bitcoin] MarcoFalke closed pull request #6866: [trivial] fix white space in rpc help messages (master...MarcoFalke-2015-rpcWhitespace) https://github.com/bitcoin/bitcoin/pull/6866
< wumpus>
also bitcoin's databases are not an external interface, don't query them directly unless it's to write troubleshooting/recovery tools
< wumpus>
ok, it would not be strange if it is happening while running tar on the datadir that bitcoin was running in, those files are deleted and recreated all the time
< wumpus>
yes, that doesn't sound good. Were you tarring while bitcoin running?
< Luke-Jr>
perhaps relevant: tar: /home/usbarmory/.bitcoin.bak/chainstate/1463292.ldb: File shrank by 2020259 bytes; padding with zeros
< Luke-Jr>
wumpus: the leveldb in question is under ~/.bitcoin.bak
< Luke-Jr>
wumpus: if you in fact want such a corrupt bitcoin dir, I can probably get one for oyu
< Luke-Jr>
[08:13:52] <phantomcircuit> can confirm bitcoin core requires reindex on power failure under windows <-- I can confirm it requires reindex on power failure under Linux..
< GitHub36>
[bitcoin] MarcoFalke opened pull request #6866: [trivial] fix white space in rpc help messages (master...MarcoFalke-2015-rpcWhitespace) https://github.com/bitcoin/bitcoin/pull/6866
< gmaxwell>
You can use it in a softfork manner without updating. Actually the bitcoin protocol _used_ to relay extra data outside of transactions but that got removed.
< gmaxwell>
I'd previously gone around to miner software and p2pool and had them fix it, even before it had been brought up in bitcoin core.
< gmaxwell>
jgarzik: now that we've removed all the gratitious sleeps from the networking, nagle is almost certantly slowing our performance. Consider how chatting the bitcoin protocol is. It likely also makes the traffic more bursty, which isn't good for other users sharing the network.