I figure I need to link -levent somewhere in addition to bitcoind/bitcoin-cli in the Makefile.am, but noob so.
still, we need reasonable communication like "is bitcoin core eating your hdd? are you seeing a lot of outbound traffic and no inbound? are your bitcoin core ping times a few seconds? disable bloom filtering"
instagibbs: lol, eric vorhees, in a long post talking about why availability of 0conf is a good idea, a guy who is explicitly incredibly pissed off at core for various reasons, said this: "The current Bitcoin implementation, in my opinion, offered a very elegant balance between instant settlement and security. Zero-conf was always an option for merchants or individuals – it came with risk, but it was in many cases manageable, and bri
cfields, something w/ travis is strange on the 0.10 branch, https://travis-ci.org/bitcoin/bitcoin/jobs/103586898 . fukuchi.org is failing (download for qrencode) but it's not using the fallback - there isn't even an error for bitcoincore.org/dev.bitcoincore.org
can't see how this discussion should be in bitcoin-core-dev ... take it too bitcoin-dev or bitcoin-classic?
dcousens, ignore that. "timeout" doesn't effect RPC. I'm curious if it lasted longer than the specified RPC timeout though (set by bundling a timeout parameter via RPC or -rpcclienttimeout on bitcoin-cli)
wangchun: bluematt's concern is the following scenario: (1) hard-fork block size increase, (2) the bitcoin network is broken, (3) miners disagree with #2, (4) miners do NOT activate soft-fork to "change it back".
wangchun: there is no way to ensure agreement about reverting to 1 MB in the event of catastrophic failure...... bitcoin miners will still continue to mine, even if 32 MB breaks the network.
33M will clearly break bitcoin in many way
otherwise we end up with an infinite blocksize and bitcoin blows up :/