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 :/
My bringing up that repo was exclusively to point out to patrick and sipa that fixing the trickling was a meaningful enough improvement in privacy that people attacking the privacy of Bitcoin Core users are trying to undermine it.
so when if people are running Bitcoin code from different places, are they possibly running on the same blockchain or different blockchains? Is there an "official" Bitcoin blockchain, or are these "forks" all running on their own networks? So confused
bitcoin.org has more info on wallets etc
jabd: bitcoin.org is neither official for Bitcoin *nor* for Bitcoin Core
Luke-Jr: on bitcoin.org, I can see lots of mentions of "Bitcoin Core", but I can't see anywhere it links to bitcoincore.org?
jabd: Bitcoin has no canonical/official anything.
i'm just getting into bitcoin now... where is the canoncial source? I'm getting a bit confused with all of the fork discussions from the past couple of weeks... maybe another way I should put this is - who is canonical upstream? Is github official, should I only pull from https://bitcoin.org/en/download or bitcoinclassic.com?
hi now that we are in bitcoin-core-dev channel, can I suggest something to the core dev's openly
Luke-Jr: apparently libstdc++ uses a single address to notate that a string is "empty", and avoids freeing it in that case. If the addresses end up being different, an empty string allocated on the bitcoin side would attempt to be freed by the lib
cfields: maybe bitcoin-cli is so simple that it doesn't instantise std::string sufficiently on its own