<@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...
< GitHub32>
[bitcoin] laanwj closed pull request #7326: [Trivial] Fix typo, wrong information in gettxout help text (master...patch-15) https://github.com/bitcoin/bitcoin/pull/7326
< GitHub104>
bitcoin/master 2cd004b Wladimir J. van der Laan: Merge pull request #7326...
< GitHub104>
bitcoin/master 3a9dfe9 paveljanik: Fix typo, wrong information in gettxout help text.
< GitHub195>
[bitcoin] MarcoFalke opened pull request #7332: [wallet] Clarify rpc help message with regard to rounding (master...Mf1601-docAmount) https://github.com/bitcoin/bitcoin/pull/7332
< GitHub37>
bitcoin/0.12 a36d79b Alex Morcos: Add sane fallback for fee estimation...
< GitHub88>
bitcoin/master d570a1f Luke Dashjr: doc/bips: Document BIP 125 support
2016-01-12
< MarcoFalke>
#bitcoin ?
< morcos>
I think it is reasonable in the interim to sign such messages Bitcoin Core but to be able to explain to people what the process for making a decision on them is
<@Luke-Jr>
Quent: please take this to #bitcoin or not at all
< Quent>
with his hate for spv wallets, for oconf transactions, for all that makes bitcoin convenient
< Quent>
because it applies to bitcoin first and foremost, what is self evidently good and in the interest of man shall prevail
< helo>
Quent: go toss a pebble if you want to change the world. this channel is for bitcoin core dev discussion.
< JackH>
#bitcoin
< JackH>
ok, on to bitcoin then
< instagibbs>
#bitcoin or stop
< gribble>
Error: You don't have the #bitcoin-core-dev,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
< Quent>
satoshi laid out how bitcoin is to scale, what he stated then remains relevant
< JackH>
as a Bitcoin business representative, this is THE most scary thing we can do with Bitcoin
< morcos>
any chance we could move this discussion back to bitcoin-dev? unless anyone wants to review #7296 or #7312 so we can move forward with getting 0.12 released?
< Quent>
on the other hand bitcoin has stronger incentive based self interest than any other altcoin
< brg444>
Bitcoin as a considerably stronger inertia than any other altcoins for very good reasons. It's important to take this in consideration when pondering the eventuality of a hard fork.
< instagibbs>
a closer example would be Bitcoin in the first or second year and Ethereum
< moli>
wangchun: yes, but they're altcoins with not as large markets as bitcoin
< zookolaptop>
Although of course, you could still be right, and one or another lucky break or special condition allowed Ethereum to succeed at that where Bitcoin wouldn't be able to do the same. Who knows.
< Luke-Jr>
morcos: if we had 100% of Bitcoin users convinced to do either a hardfork or softfork for segwit, the softfork would still be better
< jl2012>
they should only commit 32 bytes in bitcoin, and leave the rest of meta data in their own header
< morcos>
wangchun: Everyone in core would prefer to see segwit as a hard fork rather than a soft fork. but we take very seriously the notion that we should not be forcing the rules of bitcoin to change for people who might not agree
< wangchun>
Should we ACK Bitcoin Classic? I think it might be a good thing...
< GitHub195>
[bitcoin] paveljanik opened pull request #7326: [Trivial] Fix typo, wrong information in gettxout help text (master...patch-15) https://github.com/bitcoin/bitcoin/pull/7326
< sipa>
wumpus: i do think we need some clearly visible policy about which versions the bitcoin core project maintains and will issue bug fix releases for
< MarcoFalke>
Luke-Jr, even though a merge commit (or rebase) may appear trivial, I don't think we should put the burden on laanwj to go through that. (Not to mention it is hard to verify if any conflicts were solved during the final merge into bitcoin/bitcoin)
< GitHub3>
bitcoin/0.11 00aefcc Wladimir J. van der Laan: Merge pull request #7259...
< GitHub174>
[bitcoin] theuni opened pull request #7322: c++11: add scoped enum fallbacks to CPPFLAGS rather than defining them locally (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7322