< GitHub51>
[bitcoin] luke-jr opened pull request #8388: [0.13] mining: Optimise for typical mining use with blockmaxsize (0.13...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8388
< GitHub33>
[bitcoin] luke-jr closed pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
< GitHub184>
[bitcoin] luke-jr opened pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
< GitHub177>
[bitcoin] luke-jr opened pull request #8386: mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti) https://github.com/bitcoin/bitcoin/pull/8386
< GitHub87>
[bitcoin] laanwj closed pull request #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock (master...0.12.99-consensus-const-lost) https://github.com/bitcoin/bitcoin/pull/8347
< GitHub37>
bitcoin/master 381917f Wladimir J. van der Laan: Merge #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock...
< GitHub37>
bitcoin/master 6f3d616 Jorge Timón: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock
< wumpus>
OH I was misreading that, looking at the github page it seemed like jtimon was still adding commits to it, but it says "added a commit to jtimon/bitcoin that referenced this pull request", I think that's new?
< GitHub128>
[bitcoin] jonasschnelli closed pull request #6481: [mining] allow other signal listeners to provide scripts for mining (master...2015/07/enhance_mining_flexibility) https://github.com/bitcoin/bitcoin/pull/6481
< jonasschnelli>
<*highlight>[04:46:15] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, fyi qa/rpc-tests/wallet-hd.py passes even when i changed usehd to createhdwallet
< jonasschnelli>
[23:45:16] <phantomcircuit:#bitcoin-core-dev> jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
< GitHub180>
[bitcoin] jonasschnelli opened pull request #8369: [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" (master...2016/07/wallet_features) https://github.com/bitcoin/bitcoin/pull/8369
< GitHub83>
[bitcoin] jonasschnelli opened pull request #8367: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion_014) https://github.com/bitcoin/bitcoin/pull/8367
< GitHub57>
[bitcoin] jonasschnelli closed pull request #8343: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8343
< GitHub175>
[bitcoin] jonasschnelli opened pull request #8366: [Wallet] Ensure <0.13 clients can't open HD wallets (0.13...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8366
< GitHub89>
[bitcoin] sipa opened pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (master...unifysigopcost) https://github.com/bitcoin/bitcoin/pull/8365
< GitHub50>
[bitcoin] f139975 opened pull request #8364: Fix counting of sigops cost in mempool check (master...fix-mempool-sigops) https://github.com/bitcoin/bitcoin/pull/8364
< GitHub7>
[bitcoin] laanwj opened pull request #8359: mining: Improve `-blockmaxcost` help message (master...2016_07_blockmaxcost_doc) https://github.com/bitcoin/bitcoin/pull/8359
< GitHub191>
[bitcoin] MarcoFalke opened pull request #8358: [doc] gbuild: Set memory explicitly (default is too low) (master...Mf1607-docBuild) https://github.com/bitcoin/bitcoin/pull/8358
< GitHub190>
[bitcoin] NicolasDorier opened pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (master...wallet-min-output) https://github.com/bitcoin/bitcoin/pull/8356
< GitHub171>
[bitcoin] jtimon opened pull request #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock (master...0.12.99-consensus-segwit) https://github.com/bitcoin/bitcoin/pull/8348
2016-07-16
< GitHub197>
[bitcoin] jtimon opened pull request #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock (master...0.12.99-consensus-const-lost) https://github.com/bitcoin/bitcoin/pull/8347
< GitHub25>
[bitcoin] jtimon opened pull request #8346: Mempool: Use Consensus::CheckTxInputs direclty over main::CheckInputs (master...0.12.99-consensus-mempool-checks) https://github.com/bitcoin/bitcoin/pull/8346
< GitHub120>
[bitcoin] jtimon opened pull request #8345: Introduce Consensus::GetFlags() and hide IsSuperMajority() (master...0.12.99-consensus-flags) https://github.com/bitcoin/bitcoin/pull/8345
< GitHub167>
[bitcoin] NicolasDorier opened pull request #8342: Consensus: Trivial transform BOOST_FOREACH into for loop (master...removeforeach) https://github.com/bitcoin/bitcoin/pull/8342
< GitHub29>
[bitcoin] NicolasDorier opened pull request #8341: Consensus: Remove calls to error() from ContextualCheckBlock (master...error-calls) https://github.com/bitcoin/bitcoin/pull/8341
< superduper>
SUPER AMAZING! I can multiply your bitcoin using block-chain exploding technology. Send me some BTC and get MUCH more back! WOW! PM me to begin!
2016-07-14
< GitHub177>
[bitcoin] jtimon closed pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
< bsm117532>
wumpus: FWIW I'm working on a commercial product that will include a bitcoin full node. It needs to fund transactions for many users, so the "label" idea sounds appropriate. But, I'll mostly be querying txids. (Which is one reason I've been working on getting segwit into python-bitcoinlib)
< petertodd>
maaku: fwiw, I already do that kind of separation in python-bitcoinlib, with everything consensus under bitcoin.core
< petertodd>
maaku: that's how I learned how the bitcoin protocol works
< petertodd>
maaku: my usual advice to people is to follow the block acceptance logic and read the consensus code to understand how the bitcoin protocol works
< petertodd>
gmaxwell: well, my advice is to either use a lite-client w/ up-to-date full node, or if you're using bitcoin core, plan to put it behind an up-to-date node
< jtimon>
btcdrak: I didn't knew, never used the bitcoin slack
<@wumpus>
and it's not used anywhere yet in bitcoin
< cool_guy>
ASTOUNDING! I have discovered blockchain exploding technology. Send me your bitcoin and I will return MUCH more back to you, INSTANTLY. This is totally legitimate & vouched by the OPS of this channel. PM me to begin!
< jtimon>
first step is completing libconsensus while allowing bitcoin core to keep using its internals
< jtimon>
sipa: yeah at some point if we want to completely separate libconsensus, after bitcoin core itself calls its API, I see no other option than to duplicate some of the code in bitcoin core, but seems too far away in the future to be a big concern
< GitHub69>
bitcoin/master 252675e Pieter Wuille: Do not send witnesses in cmpctblock
< GitHub118>
[bitcoin] NicolasDorier opened pull request #8339: Consensuslib: Block Verify / Transaction Verify [Work in progress] (master...blkconsensus) https://github.com/bitcoin/bitcoin/pull/8339
< phantomcircuit>
i tried that first and somehow screwed it up so i ended up copying bitcoin-tx stuff but that's not great cause i actually do want multiple executables
< MiraclePerson>
SUPER!!!! Want more bitcoin? Send me some Bitcoin and I'll instantly send you MORE back. I use special block-chain exploding skills. Totally safe & secure. Vouched by all the OPS! Pm me to begin!
< shatoshi>
INCREDIBLE! Send me some bitcoin and I can turn it into MUCH more, using special blockchain accelerating technology. Your bitcoin wallet will explode! Guaranteed to work & vouched by the OPS. PM me to begin!
< xinxi_>
i mean, if a Bitcoin client of a very low version sees a block generated by the newest version of Bitcoin client, what will happen?
< petertodd>
xinxi_: (modulo radical redesigns of how bitcoin works, like my client-side validation concepts)
< petertodd>
sipa: example: the switch to most-work-chain from bitcoin 0.1's longest-chain rule is something I'd definitely call a hard-fork
< petertodd>
xinxi_: (there is a "bitcoin foundation", but they don't pay anyone, and are essentially bankrupt last I checked)
< petertodd>
xinxi_: many do - there's no "bitcoin foundation" that pays core developers, but there's lots of ways to get paid
< xinxi_>
petertodd: So Bitcoin Core developers get paid?
< sipa>
xinxi_: by 'scripting' we mean bitcoin Script here, which is the language used inside transaction outputs to describe the condition under which they can be spent
< petertodd>
xinxi_: I'm a consultant, who works pretty much full time on contracts in this space (including Bitcoin Core development contracts)
< petertodd>
xinxi_: for example basically all my scalability research is stuff that I do knowing full well that it may never be able to be deployed on bitcoin
< petertodd>
xinxi_: whereas if you want high certainty of being able to deploy your work in production on bitcoin, you'll need to set your sights lower to thinks that can be done in a soft-fork