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. :(
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.
warren: it's all ugly, bitcoin core is currently not intended for system level operation.
warren: what happens if a second datadir is specified to bitcoin-cli?
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/
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.
warren: this channel should be for bitcoin core exclusive discussion.
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
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
dcousens: #bitcoin maybe?
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 )
That's a very hard problem that I don't think bitcoin can solve by choice of db.
bsm117532: jeff has a branch with bitcoin core running on sqlite3
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
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?
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.
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.
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
bitcoin/master 143d173 Eric Lombrozo: Use BOOST_CHECK_MESSAGE() rather than BOOST_CHECK() in alerts_tests.cpp and initialize strMiscWarning before calling PartitionCheck()."
(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. :) )
somehow i had restored a snapshot of bitcoin dir that only had 183k blocks in it
unbatched? hmm, doing a sqlite transaction per bitcoin transaction is certainly going to kill sqlite performance
after running a while, bitcoin-shutoff is taking a long time in sqlite3_close - possibly due to the lack of checkpoints
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.
[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
jonasschnelli: if only we didn't have this pesky economy thing that relies on bitcoin
sipa: that sounds perfect for our bitcoin <1.0 version. :)
jonasschnelli: yes, testing bitcoin core using <alternative database> :P it shouldn't be that much work; presumably jeff will report back on that soon
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
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.
serious: what would be the overhead to run bitcoin-qt/core in a vm on windows?
I believe more people have stopped running bitcoin core on windows than currently run it.
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.
i thought gmaxwell was declaring sipa a risk to bitcoin there