< GitHub24>
[bitcoin] laanwj closed pull request #6700: bloom_tests: Do not depend on specific serialisations (master...bloom_tests_not_ser) https://github.com/bitcoin/bitcoin/pull/6700
< GitHub67>
[bitcoin] MarcoFalke opened pull request #7381: [walletdb] Fix syntax error in key parser (master...Mf1601-walletdbKeyparserFix) https://github.com/bitcoin/bitcoin/pull/7381
< randy-waterhouse>
can't see how this discussion should be in bitcoin-core-dev ... take it too bitcoin-dev or bitcoin-classic?
< gijensen>
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)
< kanzure>
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".
< kanzure>
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.
< BlueMatt>
33M will clearly break bitcoin in many way
< BlueMatt>
otherwise we end up with an infinite blocksize and bitcoin blows up :/
< bsm117532>
Thanks btcdrak. Looked briefly, this looks like it's probably about as useful as the #bitcoin IRC channel (very low signal/noise, no serious dev discussion)...
< btcdrak>
instagibbs: it's also for Bitcoin Core community to gather
< GitHub3>
[bitcoin] laanwj closed pull request #7281: Improve CheckInputs() comment about sig verification (master...2016-01-improve-checkinputs-comment) https://github.com/bitcoin/bitcoin/pull/7281
< GitHub104>
bitcoin/master f9fd4c2 Wladimir J. van der Laan: Merge pull request #7281: Improve CheckInputs() comment about sig verification...
< GitHub104>
bitcoin/master fd83615 Peter Todd: Improve CheckInputs() comment about sig verification
< GitHub73>
[bitcoin] toby opened pull request #7376: Payments: Allow zero value OP_RETURN in PaymentRequests (master...zeropayments) https://github.com/bitcoin/bitcoin/pull/7376
<@wumpus>
michagogo: no, no clue, I had some problems with LXC myself hence https://github.com/bitcoin/bitcoin/pull/7060 , but haven't heard anyone else about it (and shouldn't be macosx specific either)
< GitHub99>
bitcoin/0.12 351ffd8 James O'Beirne: Fix help, add RPC tests for getblockheader...
< GitHub101>
[bitcoin] laanwj closed pull request #7232: [RPC] getblock: Added help text for chainwork value (master...getblockhelp) https://github.com/bitcoin/bitcoin/pull/7232
< GitHub177>
bitcoin/master ae20172 Wladimir J. van der Laan: Merge pull request #7232...
< GitHub177>
bitcoin/master 94bdd71 Gregory Sanders: Added help text for chainwork value
< GitHub60>
[bitcoin] laanwj closed pull request #7208: Make max tip age an option instead of chainparam (master...2015_12_maxtipage) https://github.com/bitcoin/bitcoin/pull/7208
< GitHub71>
bitcoin/master 47c5ed1 Wladimir J. van der Laan: Merge pull request #7208...
< GitHub71>
bitcoin/master 64360f1 Wladimir J. van der Laan: Make max tip age an option instead of chainparam...
< gmaxwell>
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.
< jabd>
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
< p15>
bitcoin.org has more info on wallets etc
< Luke-Jr>
jabd: bitcoin.org is neither official for Bitcoin *nor* for Bitcoin Core
< jabd>
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?
< Luke-Jr>
jabd: http://bitcoincore.org for stuff by the Core dev team, including scaling plans for Bitcoin
< Luke-Jr>
jabd: Bitcoin has no canonical/official anything.
< jabd>
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?
< JackH>
hi now that we are in bitcoin-core-dev channel, can I suggest something to the core dev's openly
< cfields>
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
< Luke-Jr>
cfields: maybe bitcoin-cli is so simple that it doesn't instantise std::string sufficiently on its own
< GitHub193>
[bitcoin] MarcoFalke opened pull request #7334: [qt] coincontrol workaround is still needed in qt5.4 (fixed in qt5.5) (master...Mf1601-qt55Workaround) https://github.com/bitcoin/bitcoin/pull/7334
< GitHub52>
bitcoin/0.12 5771b71 Wladimir J. van der Laan: doc: Remove BIP65 mention from release notes...