gmaxwell, it doesn't seem to be IO or CPU bound, but I am using spinning rust, it seemed wasteful to eat up a large % of my ssd on bitcoin
gmaxwell, I had a 4G dbcache which was part of the reason the oom killer picked on bitcoin
That is really annoying chrome decided to eat up all the memory, but the oom killer took out bitcoin (while doing a reindex) and somehow the progress went from 99ish% to 85%, that is quite a bit of rollback
Would it be worth it to add a replay protection mechanism in Bitcoin where a NOP is replaced with <height> <blockhash> OP_CHECKBLOCKVERIFY which would fail if the hash of the block at the given height did not match <blockhash>? (It would probably require that <height> was less than <current height> - 100 to avoid nasty double spends at reorgs...)
well, p2pk is a bit different, because you do not create a bitcoin address for it
[bitcoin] laanwj closed pull request #11132: Document assumptions that are being made to avoid NULL pointer dereferences (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/11132
bitcoin/master 551d7bf Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences...
bitcoin/master fdc3293 practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences
https://github.com/bitcoin/bitcoin/issues/11373 should just be closed with "Your filesystem permissions have been set to prevent bitcoind from accessing its datadir, which prevents it from starting" (unless someone wants to change it to a "we need a better error message for this bug" issue)
how can i develop or contribute to bitcoin
can i get any useful ideas to implement to develop bitcoin
Reading the OP_RETURNTRUE discussion on bitcoin-dev it struck me that if we bump segwit script version at some point, old nodes will all accept the tx without looking, and new nodes will use the new script to verify. A miner running old version could mine txs with invalid scripts and old nodes would accept this block while new nodes would not. This would become a hardfork, no?
I don't really wanna waste anyone's time, but I've been trying to figure out the gitian build process lately and am having issues. I was following https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md and everything was fine down to "Getting and building the inputs". For one I had to cd into ../bitcoin/ for there to be a contrib/gitian-build.sh file (not mentioned, but no biggie),
[bitcoin] esotericnonsense opened pull request #11366: Trivial: RPC/getblockchaininfo: pruneheight is only present in pruned mode (master...2017-09-getblockchaininfo-docs) https://github.com/bitcoin/bitcoin/pull/11366
goatpig: if something like that went on for weeks it would be doubtful if bitcoin would continue to exist at the end of such an event, regardless tweaking forward assumevalid wouldn't be a high priority. ... losing it entirely isn't that big of a deal.
esotericnonsense: consider this, right now the chainstate on disk is 2.8gb adding the dbcache to the interval on syncing with defaults would end up with you needing to have 4GB free to sync bitcoin instead of 3.5.
on linux it lives in .config/Bitcoin/Bitcoin-Qt.conf for me
removing the bitcoin.conf was the first thing I tried but no luck. my mac os 10.12 system didn't have any issues at all. It's still syncing, then I'll try the older system again. Bet -resetguisettings will fix it.
jl2012: nCustomFeeRadio isn't in bitcoin.conf …
BashCo: can you pastebin the contents of ~/Library/Preferences/bitcoin-qt.plist (or something like that I think)