< 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
< petertodd>
xinxi_: I'm just saying, that anything that for any work you do that may require a hard-fork to deploy, you should accept that you may need to create a new currency, economically distint from bitcoin, to deploy your work in production
< petertodd>
xinxi_: I'd suggest you take that kind of discussion to #bitcoin-wizards at least
< xinxi_>
i need to make sure that tremendous amount of effort that could make Bitcoin even greater will be deployed.
< sipa>
it is off topic for the developer of bitcoin core, which is what this channel is about
< jtimon>
yep, sorry, #bitcoin I guess
< jeremyrubin>
xinxi_: probably discuss this on #bitcoin
< gmaxwell>
KwukDuck: that kind of issue is usually caused by hardware error, lose or bad disk cables, or bad memory (run memtest86?)-- sometimes antivirus software can screw with the files bitcoin is using.
< jtimon>
at least for bitcoin core as a caller (assuming one day bitcoin core directly calls libconsensus instead of its internals) I don't see how performance would be affected very negatively, I worry more about serializing and deserialzing the parameters (like the tx in verify) for example, since people have complained (that's the reason why libbitcoin copies the code instead of using libconsensus' API directly)
< jtimon>
I was working on https://github.com/jtimon/bitcoin/commits/jt but I broke the branch when backported bip9 and never cared to fix it (but review is still very welcomed since I plan to rewrite/cherry pick most of the stuff from there)
< phantomcircuit>
indeed wumpus is right, possibly this could move to #bitcoin
<@wumpus>
PSA: this channel is about bitcoin core development, XT and classic and certainly non-technical drama around them are very off-topic
< gmaxwell>
eragmus: (1) because software that silently downgrades security then promotes itself as faster is a risk to the continued viability and value of Bitcoin, which I care about. .. and because he attacks me by claiming that I've acted unethically, which if left unchallenged ends up recycled as accepted truth in places like the NYT where it can cause me lifelong harm.
< gmaxwell>
Seriously, if I wanted to 'backdoor' your software, the avenues available are far more profound-- your response has made me profoundly uncomfortable with the continued existance of Bitcoin XT-- you'll continue to copy code from Core, and when the inevitable errors that happen from interactions which I could never have anticiapted; you've shown that you'll accuse me of unethical or even criminal
< gmaxwell>
A few days ago you seemed to be arguing that using the _miner provided_ timestamps on blocks to decide to bother validating the block or not would require 100% hashpower and control of the users local clock to exploit-- functionality you added without even adding a _release note_ to Bitcoin XT. Your response to this being pointed out was to again repeat accusations that I backdoored your softwa
< gmaxwell>
And, what the heck is "a 51% attack" -- Bitcoin exists as a confluence of incentives, one part of it is that even a user who buys up large amounts of hashpower for a brief period only gains the ability to reorganize recent transactions, which is difficult to profitably exploit at any scale-- which users can protect themselves from by waiting for additional confirmations. Under the security mod
< GitHub136>
[bitcoin] dcousens opened pull request #8332: semi trivial: clarify witness branches in transaction.h serialization (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8332
2016-07-11
< GitHub44>
[bitcoin] dooglus opened pull request #8331: Fix three 'comparison between signed and unsigned integer expressions' warnings. (master...fix-compilation-warnings) https://github.com/bitcoin/bitcoin/pull/8331
< sipa>
xinxi: (i'll only mention this once): bitcoin core's cryptography library (libsecp256k1) does have some modest attempts at formally verifying pieces of the code, and help there would also be very welcome. It's much less ambitious than proving properties about bitcoin's consensus code, but also much easier to accomplish something in my opinion
< petertodd>
btcdrak: self-enforcing because of the underlying proof-of-work layers ensuring consensus, and the fact that people widely choose to accept the outputs of the system - bitcoin being a perfect - albeit inflexible - example
< petertodd>
xinxi: equally, the definition of the bitcoin protocol is what the bitcoin implementation accepts as valid - the fact the code that does that is somewhat intermixed with code that records state is just a historical mistake
< petertodd>
xinxi: the most likely way bitcoin will fail right now is a failure of decentralization, which is very closely tied to scalability
< petertodd>
xinxi: bitcoin is exactly the same, except that on top of that, PoW allows our state to converge to a single consensus history
< xinxi>
And the biggest concern of Bitcoin to me is not the lack of functions but its security. Many people still think it is too young and not reliable enough and could fail completely and thus don't want to adopt it.
< xinxi>
To me, Bitcoin is great because it is solving a real problem.
< petertodd>
sipa: point is, I think xinxi would be much better off solving problems in that problem space first, as they're easier to solve with more impact, and that'll give them tools to tackle bitcoin later; misunderstandings about that problem space are indicative of serious misunderstandings with how bitcoin works
< xinxi>
petertodd: yeah, we can use Bitcoin in that AWS based smart contract platform. It does not have to be decentralized.
< sipa>
xinxi: for bitcoin's security assumptions to hold, verification of blocks must be negligable in time compared to the block production rate
< petertodd>
Chris_Stewart_5: I'm not saying there isn't interest, I'm saying that if you want to make a high impact with formal verification deployed in production, Bitcoin isn't interesting because the risks of deploying formal verification in production are higher than the theoretical benefits
< xinxi>
But after that, we will take off. And Bitcoin will be much more secure than before.
< Chris_Stewart_5>
petertodd: I think there actually has been some considerable interest in the formal verification community in bitcoin. I've talked to a handful of researchers myself and I don't think directing them away from the core protocol is a good idea
< sipa>
xinxi: it gives you an idea of how complicated it was to find some of the actually known consensus failures in bitcoin
< sipa>
and bitcoin's scripting language before the removal of OP_VER was also a consensus problem
< sipa>
how many consensus failures in bitcoin can you name? :)
< Chris_Stewart_5>
Bitcoin has already had issues with this in the past
< Chris_Stewart_5>
petertodd: I disagree, the consensus layer is the bedrock of bitcoin, if we screw that up in a major way we are done
< xinxi>
petertodd: I think we are just lucky that Bitcoin has not yet experienced any catastrophic attacks?
< petertodd>
xinxi: it's not going to be huge - the reliability of the consensus specification/implementation hasn't been a major problem for bitcoin - other problems are far higher-impact (scaling)
< kanzure>
xinxi: there are many bitcoin developers who want that as well. i think you could easily find collaborators from this conversation.
< xinxi>
the purpose is simple. we want to make bitcoin reliable.
< GitHub72>
[bitcoin] JeremyRubin opened pull request #8330: WIP: Structure Packing Optimizations in CTransaction and CTxMemPoolEntry (master...structurepacking) https://github.com/bitcoin/bitcoin/pull/8330
< kanzure>
sipa: maybe we can hijack the milan conference for these purposes (scaling bitcoin 3)
< xinxi>
For Bitcoin, the programming language is not a big issue, and using languages like Coq, which enables a unified way for both coding and proofs could make it a lot easier.
< gmaxwell>
xinxi: yes, and Bitcoin has to achieve high efficiency, efficiency is a security parameter for us.
< sipa>
so now bitcoin's "specification" implicitly depended on OpenSSL's implementation
< sipa>
xinxi: for example, for a long time, bitcoin relied on OpenSSL's signature parsing code
< xinxi>
so the motivation of this is to avoid catastrophic failures of Bitcoin.
< sipa>
xinxi: so we've usually said that a specification for bitcoin would be descriptive but not prescriptive... the laws of the network are those implemented by the code that people choose to run, not by an abstract descriptio
< xinxi>
hey guys, I want to make Bitcoin provably correct.
< GitHub65>
[bitcoin] jtimon opened pull request #8329: Consensus: MOVEONLY: Move functions for tx verification (master...0.12.99-consensus-moveonly-tx) https://github.com/bitcoin/bitcoin/pull/8329
< BTCking>
AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
< BTCking>
AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
< GitHub157>
bitcoin/0.12 1233cb4 Wladimir J. van der Laan: Merge #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state...
< GitHub27>
[bitcoin] laanwj closed pull request #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state (0.12...Mf1607-012qtDebugSplash) https://github.com/bitcoin/bitcoin/pull/8302
< GitHub157>
bitcoin/0.12 fe98533 Jonas Schnelli: [Qt] Disable some menu items during splashscreen/verification state...
< oddishh>
WOW! My bitcoin expander is now READY! Put some bitcoin in my wallet and I'll intantly expand it & send you more back. Totally vouched & legit. PM me to begin!
< GitHub121>
[bitcoin] jonasschnelli opened pull request #8324: [Wallet] keep HD seed during salvagewallet (master...2016/07/hd_salvage) https://github.com/bitcoin/bitcoin/pull/8324
< GitHub29>
[bitcoin] jonasschnelli closed pull request #8205: [Wallet] add HD keypath to CKeyMetadata, report over validateaddress (master...2016/06/hd_metadata) https://github.com/bitcoin/bitcoin/pull/8205
< GitHub108>
[bitcoin] jonasschnelli opened pull request #8323: Add HD keypath to CKeyMetadata, report metadata in validateaddress (master...2016/07/hd_013) https://github.com/bitcoin/bitcoin/pull/8323