< GitHub134>
[bitcoin] JeremyRubin opened pull request #8513: Fix a type error that would not compile on OSX. (master...fix-osx-break) https://github.com/bitcoin/bitcoin/pull/8513
< GitHub140>
[bitcoin] leijurv closed pull request #8506: Trivial: Standardize spelling of "serialize" and "optimize" in mining.cpp and main.cpp (master...serialise-typo) https://github.com/bitcoin/bitcoin/pull/8506
< GitHub47>
[bitcoin] leijurv closed pull request #8507: Trivial: Standardize spelling of "optimization" vs "optimisation" in main.cpp (master...optimization-typo) https://github.com/bitcoin/bitcoin/pull/8507
< GitHub93>
[bitcoin] leijurv opened pull request #8507: Trivial: Standardize spelling of "optimization" vs "optimisation" in main.cpp (master...optimization-typo) https://github.com/bitcoin/bitcoin/pull/8507
< wumpus>
to be clear I really like this funcitonality in the GUI, and possible in bitcoin-cli, but let's not conflate this with hypothetical JSON-RPC nested commanding
< TD-Linux>
they submitted a BIP draft to bitcoin-dev which only reserved the bit with no documentation of what it did
< murch>
Lightsword: Don't let yourself quote like that. You'll face endless harrassment on Reddit. :p I'm having a hard time finding the Bitcoin Classic release notes.
< murch>
By the way, while there are still lots of well-informed people reading this. Does anyone else have another list of realistic spending values for Bitcoin Nodes? I'd love to have a second scenario to test my coin selection simulation on.
< pigeons>
i asked before too, got answers about gavin making changes for CIA, "only real bitcoin address starts with a 1", etc
< luke-jr>
jtimon: to answer your earlier question best I can: I think they perceive 0.5.3 as the last release before the Bitcoin Foundation "got involved" (I know the BCF was never involved, but they're conspiracy nuts)
< gmaxwell>
e.g. if you update your bitcoin node and then days/weeks later it starts doing thing with segwit commitments that breaks your miners or pooling software, that is preferable. You would prefer the break to happen at upgrade time.
< GitHub104>
[bitcoin] jtimon opened pull request #8498: Optimization: Minimize the number of times it is checked that no money... (master...0.13-consensus-inputs) https://github.com/bitcoin/bitcoin/pull/8498
< jtimon>
kanzure: https://github.com/bitcoin/bitcoin/pull/8493 looks like a long branch (because it has many tiny steps commits that could be squashed) but it's only +373 −94 , please check it out
< GitHub7>
[bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< GitHub52>
bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
< jonasschnelli>
gmaxwell: So using tor hidden service over 443 would probably allow bypassing firewalls (assume some large company firewalls where only 80,443 is open) to connect to the bitcoin network?
< GitHub28>
bitcoin/0.13 edc2c70 Wladimir J. van der Laan: Merge #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them...
< GitHub79>
[bitcoin] laanwj closed pull request #8438: [0.13] backport: Treat high-sigop transactions as larger rather than rejecting them (0.13...btc-13-sigops) https://github.com/bitcoin/bitcoin/pull/8438
< GitHub28>
bitcoin/0.13 3f65ba2 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
< jonasschnelli>
Would ICE works for Bitcoin? Or would that require UDP? (maybe off-topic here)
< jonasschnelli>
Does bitcoin-cores UPNP (or UPNP in general) uses nat traversal or ICE? Or is the only way to get connection from the outside if your router supports uPNP and opens the port?
< GitHub86>
[bitcoin] sipa closed pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
< GitHub128>
bitcoin/master 484312b Pieter Wuille: Merge #8467: [Trivial] Do not shadow members in dbwrapper...
< GitHub128>
bitcoin/master 4a35e0f Pavel Janík: Do not shadow members in dbwrapper
< GitHub19>
[bitcoin] MarcoFalke opened pull request #8486: [wallet] Add high transaction fee warnings (master...Mf1607-walletHighFeeWarn) https://github.com/bitcoin/bitcoin/pull/8486
< jonasschnelli>
Adding something that could be called "detached signing" to bitcoin-core, would that require a BIP? Idea: during signing of a transaction, wallet can call/pipe a executable, send some transaction relevant information, wait for response, done.
< GitHub160>
[bitcoin] paveljanik opened pull request #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK (master...20160806_Wshadow_LOCK) https://github.com/bitcoin/bitcoin/pull/8472
< sipa>
this channel is about development of bitcoin core
< sipa>
i doubt many people involved with bitcoin core development are interested in this
< sipa>
sonlin: people were trying to innovate long before bitcoin had any value. increased value brought economic interest in influencing development with all associated politics
< sipa>
sonlin: as a developer, i believe it would strongly undermine trust in bitcoin as an independent decentralized currency
< sipa>
if bitcoin core were to introduce such a rule, i hope the community would refuse to run it
< sipa>
also, bitcoin developers don't set the rules
< sonlin>
But i was told by the developers that are making dsd that basically all bitcoin devs would switch over at once.
< sipa>
kanzure: now you give bitcoin developers an incentive to go pump those altcoins :p
< kanzure>
sipa: what about altcoins distributing payments to bitcoin developers as part of their protocol definitions?
< kanzure>
the funny thing is that altcoins should probably hard-code their developer subsidies to pay bitcoin developers, so that the bitcoin developers continue to work, since altcoins benefit mainly from that development activity, and that subsidy doesn't interfere with the bitcoin protocol definition. however, iirc, developers in the past have said they would not touch any of those subsidy payments anyway.
< sipa>
and we all want bitcoin to progress, but i don't think you do that by radically changing its economics
< sonlin>
I just want bitcoin to progress.
< sipa>
how do bitcoin holders decide?
< sonlin>
Bitcoin holders and a combination of other methods.
< GitHub14>
[bitcoin] paveljanik opened pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
< GitHub153>
[bitcoin] paveljanik opened pull request #8467: [Trivial] Do not shadow members in dbwrapper (master...20160805_Wshadow_dbwrapper) https://github.com/bitcoin/bitcoin/pull/8467
< GitHub185>
[bitcoin] paveljanik opened pull request #8466: [Trivial] Do not shadow variables in networking code (master...20160805_Wshadow_net) https://github.com/bitcoin/bitcoin/pull/8466
< bsm117532>
wizkid057, the exploding bitcoin spammer, somehow got op permissions on #bitcoin-wizards and is banning people. Can someone here take care of him?
< gmaxwell>
luke-jr: nothing held back blocksizes from growing from 250k to 1mb... not even the defaults in bitcoin core-- or large increases in orphaning rates.
< luke-jr>
if they care about Bitcoin (but not per se enough to research their own opinion on block size limits), they should follow recommendations to set it lower.
< GitHub92>
[bitcoin] jlopp opened pull request #8461: document return value of networkhashps for getmininginfo RPC endpoint (master...rpcMiningHelp) https://github.com/bitcoin/bitcoin/pull/8461
< GitHub10>
[bitcoin] luke-jr opened pull request #8459: [0.13] release-notes: Do not encourage changing blockmaxsize to blockmaxweight (0.13...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8459
< GitHub168>
[bitcoin] luke-jr closed pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
< GitHub107>
[bitcoin] luke-jr opened pull request #8458: [0.13] release notes: remove bad advice to switch to blockmaxweight prematurely (master...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8458
< GitHub30>
[bitcoin] laanwj opened pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
< sipa>
there are certainly no regressions known that would make the current master less appropriate than the subtree in bitcoin currently
< GitHub139>
[bitcoin] paveljanik opened pull request #8449: [Trivial] Do not shadow local variable, cleanup (master...20160803_shadow_blockencodings) https://github.com/bitcoin/bitcoin/pull/8449
< GitHub43>
[bitcoin] MarcoFalke closed pull request #8316: [qa] feefilter: Clear mempool after each check (master...Mf1607-qafeefilter) https://github.com/bitcoin/bitcoin/pull/8316
< GitHub193>
[bitcoin] laanwj closed pull request #8331: Fix three 'comparison between signed and unsigned integer expressions' warnings. (master...fix-compilation-warnings) https://github.com/bitcoin/bitcoin/pull/8331
< GitHub141>
bitcoin/master 115265b Pavel Janík: Trivial: bip -> BIP in help text and comment
< GitHub71>
bitcoin/0.13 6c083ac Wladimir J. van der Laan: Merge #8441: doc: Rewrite shell example to not leave secrets in the history file...
< GitHub53>
[bitcoin] laanwj closed pull request #8441: doc: Rewrite shell example to not leave secrets in the history file (0.13...patch-17) https://github.com/bitcoin/bitcoin/pull/8441
< GitHub71>
bitcoin/0.13 719208c paveljanik: Rewrite shell example to not leave secrets in the history file
< wumpus>
cfields: I don't get it, I don't manage to compile master for ARM anymore: https://github.com/bitcoin/bitcoin/issues/8447 however, in travis it's working. What could be the difference, that I'm compiling my own toolchain?
< GitHub103>
[bitcoin] paveljanik opened pull request #8446: BIP9 parameters on regtest cleanup (master...20160802_shadow_bip9params) https://github.com/bitcoin/bitcoin/pull/8446