< October 2023 >
Su Mo Tu We Th Fr Sa 1234 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
2016-07-13
< 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
< gmaxwell>
cfields: I've found that a lot of people would like to play with it are actually thrown off by setting an option. It's not so intutive for GUI users. I think this would greatly increase testnet usage to have builds that work more like bitcoin/altcoin installs.
< gmaxwell>
Matt has announced his new relaynetwork work that uses UDP and FEC, http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/ the current not really fully cooked software gets worldwide block propagation 99% of the time in less than 100ms over the fiber-path distances.
<@wumpus>
in any case, to conclude this topic: https://github.com/bitcoin/bitcoin/milestone/20 is an accurate reflection of what has to be done before rc1? (apart from the release notes issue)
< zooko>
Hey Core Devs: here's another patch we've been working on for Zcash which you might want upstream in Bitcoin Core: https://github.com/zcash/zcash/issues/915
< GitHub155>
[bitcoin] yurizhykin opened pull request #8313: Use std::move() instead of copying/removing in TxMemPool (master...tx-delete) https://github.com/bitcoin/bitcoin/pull/8313
< bsm1175321>
Does there exist any UTXO set commitment implementation as a patch/PR to bitcoin? I'm interested in running some benchmarks and comparisons of ways we might do it.
< GitHub19>
[bitcoin] MarcoFalke opened pull request #8302: [Qt] Disable some menu items during splashscreen/verification state (0.12...Mf1607-012qtDebugSplash) https://github.com/bitcoin/bitcoin/pull/8302
2016-07-02
< gmaxwell>
The primary, nearly exclusive, argument provided to why someone won't overpower the network (e.g. briefly) is becaues there isn't much that they can do with it. They can't just blank-check write themselve an extra 100,000 Bitcoin. They can DOS attack and double spend their own payments.
< gmaxwell>
yes, including the one built into bitcoin's p2p protocol, though thats several layers of irrelevance down the line. (also an attacker who can influence that one is already too powerful)
< CubicEarth>
gmaxwell: Thinking about your 'carving a block of marble' analogy for forks, and thinking about the nature of Bitcoin, I tend to think that anything can be accomplished with a 'soft-fork', such as effectively raising the coin limit, etc. I see it like a nested-universe scenario, but in the marble analogy... take the statue of David. Say we find ourselves disappointed that Michelangelo didn't give David
2016-07-01
< CubicEarth>
gmaxwell: well I'm pretty sure the rise of ETH was hurting the bitcoin price to some extent. I think this event was a decoupling, where Bitcoin shakes the monkey off its back.
< gmaxwell>
which adversely impacted the bitcoin price even though many of us have been pointing out the related risks and distinguishing bitcoin on the basis of them for some time.
< gmaxwell>
midnightmagic: I don't think that matters that much, but right now bitcoin "xt" is only not totally partitioned due to inbound connections from core to XT, but part of segwit is that segwit capable nodes will strongly prefer to connect out to only non-segwit nodes (because they must in order to get blocks once segwit is activated)-- the result will be making that partition complete.
< gmaxwell>
signature validation is, and bitcoin core runs that in paralle... but normally almost all of the signatures in a block are already validated before it shows up.
< bsm1175321>
Ok I think I understand. A wallet bitcoin.conf really should have 3 possible values then: non-segwit, segwit, and segwit-in-p2sh.
<@wumpus>
though of course it's not entirely certain whether the reported problems were due to this change, or another change, or a change in the general usage of bitcoin not directly related to a change in our wallet
<@wumpus>
though at some point the 'exclude these coins and do the selection again' list would become very long, and is less suited for non-boolean properties like input size (https://github.com/bitcoin/bitcoin/issues/7664)
< gmaxwell>
it ended up that way because they had multiple unconfirmed few-bitcoin outputs, and then a 1 bitcoin output and were making many not huge payments... so it decided to keep reusing the change because it considered them all equal.
< GitHub129>
[bitcoin] laanwj closed pull request #8285: windows: Add testnet link to installer (master...2016_06_testnet_link_windows) https://github.com/bitcoin/bitcoin/pull/8285
< GitHub68>
bitcoin/master da50997 Wladimir J. van der Laan: Merge #8285: windows: Add testnet link to installer...
< GitHub68>
bitcoin/master 975a41d Wladimir J. van der Laan: windows: Add testnet icon for testnet link...
< gmaxwell>
I don't think its of major importance, but "Bitcoin XT" recently started making only outbound connections to other XT nodes. In combination with segwit, I believe this will partition them. Because they are such a small number of nodes I don't think it warrents much attention, but something to be aware of.
< gmaxwell>
wumpus: I agree in principle except for the fact that a LOT of people have copied the "example config" from the bitcoin wiki and are setting all kinds of crazy things. :)
< GitHub96>
[bitcoin] jmcorgan closed pull request #8284: Backport remaining commits for out-of-tree builds from master to 0.12 branch (0.12...build-oot-0.12) https://github.com/bitcoin/bitcoin/pull/8284
< GitHub64>
[bitcoin] luke-jr opened pull request #8293: Bugfix: Allow building libbitcoinconsensus without any univalue (master...sys_univalue_opt) https://github.com/bitcoin/bitcoin/pull/8293
2016-06-29
< GitHub73>
[bitcoin] MarcoFalke opened pull request #8291: [util] CopyrightHolders: Check for untranslated substitution (master...Mf1607-utilCopy) https://github.com/bitcoin/bitcoin/pull/8291
< GitHub20>
[bitcoin] EthanHeilman opened pull request #8282: net: Feeler connections to increase online addrs in the tried table. (master...feelers3) https://github.com/bitcoin/bitcoin/pull/8282
< GitHub142>
[bitcoin] laanwj opened pull request #8281: qt: Remove client name from debug window (master...2016_06_qt_remove_client_name) https://github.com/bitcoin/bitcoin/pull/8281
< GitHub17>
[bitcoin] sdaftuar opened pull request #8280: Tests: Increase sync_blocks() timeouts in pruning.py (master...fix-pruning-test) https://github.com/bitcoin/bitcoin/pull/8280
< GitHub152>
[bitcoin] laanwj closed pull request #8261: The bit field is shown only when status is "started" (master...20160625_sw_getblockchaininfo_bit) https://github.com/bitcoin/bitcoin/pull/8261
< GitHub19>
bitcoin/master 3685e0c Wladimir J. van der Laan: Merge #8261: The bit field is shown only when status is "started"...
< GitHub19>
bitcoin/master 2129fce Pavel Janík: The bit field is shown only when status is "started"