rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-07-27 📝 Original message:On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote: > Hello all, > > I'd like to talk a bit about my view on the relation between the Bitcoin > Core project, and the consensus rules of Bitcoin. > > I believe it is the responsibility of the maintainers/developers of Bitcoin > Core to create software which helps guarantee the security and operation of > the Bitcoin network. > > In addition to normal software maintenance, bug fixes and performance > improvements, this includes DoS protection mechanism deemed necessary to > keep the network operational. Sometimes, such (per-node configurable) > policies have had economic impact, for example the dust rule. > > This also includes participating in discussions about consensus changes, > but not the responsibility to decide on them - only to implement them when > agreed upon. It would be irresponsible and dangerous to the network and > thus the users of the software to risk forks, or to take a leading role in > pushing dramatic changes. Bitcoin Core developers obviously have the > ability to make any changes to the codebase or its releases, but it is > still up to the community to choose to run that code. > > Some people have called the prospect of limited block space and the > development of a fee market a change in policy compared to the past. I > respectfully disagree with that. Bitcoin Core is not running the Bitcoin > economy, and its developers have no authority to set its rules. Change in > economics is always happening, and should be expected. Worse, intervening > in consensus changes would make the ecosystem more dependent on the group > taking that decision, not less. > > So to point out what I consider obvious: if Bitcoin requires central > control over its rules by a group of developers, it is completely > uninteresting to me. Consensus changes should be done using consensus, and > the default in case of controversy is no change. It's worth reminding people that Bitcoin Core, Bitcoin XT, my own Bitcoin RBF, Luke-Jr's Bitcoin distribution, etc. are all software packages that implement the Bitcoin protocol. Like many protocols, changing the Bitcoin protocol isn't easy, and requires a broad consensus among many players for any change to proceed smoothly. Conversely, changing non-protocol aspects of any of those software packages is easy, and requires little to no coordination. Of course, in practice the Bitcoin Core dev team does have a lot of influence, to the point where soft-forks proposed by them are adopted pretty much blindly by most users. This is essentially a meta-consensus: the community is assuming what the Bitcoin Core team releases will be a good idea to run as well as non-controversial without necessarily investigating too closely. The Core dev team has a strong track record of making good decisions with very few mistakes, while still adding new features, fixing security bugs, and improving performance significantly. That leads to a fairly strong meta-consensus of "Just run Bitcoin Core" Of course, if the Core team was taking changes and making controversial changes, I suspect that meta-consensus would quickly break down! So it's not as strong as it looks - the Core team doesn't really have the ability to push through controversial changes, and the Core team acts accordingly. If you don't agree with that "meta-consensus", running an alternative Bitcoin protocol implementation such as Bitcoin XT is a logical way of showing your support for a different way of coming to consensus on protocol changes. It's not totally clear yet what that way actually is, but it's certainly shaping up to have a lot less emphasis on broad consensus among the technical community. (of course, the XT team to date has much less experience with the Bitcoin protocol and codebase than the combined Core team does) The ugly thing is I think everyone in this process recognises the meta-consensus nature of the debate already. Notice how Gavin Andresen's initial blocksize posts were in the form of a non-technical blog, making non-technical arguments to the public - not the Core dev team - in ways not conducive to open response. A rather annoying example is Jeff Garzik's recent efforts: a fundementally broken troll pull-req raising the blocksize to 2MB that simply can't be merged for reasons unrelated to the blocksize, followed by very public and loud efforts to spin a non-issue - closing a pull-req that had no real impact on blockchain capacity - into a broader reddit furor over a "changed" policy on scaling. As a PR effort to the public this was fairly effective: framing the Core dev team's actions as a change and raising the blocksize as a default action puts the team on the defensive. As a way of building consensus among the Core dev team, Garzik's actions are very counterproductive. I personally have a fairly high tolerance to trolling, but I wouldn't be surprised if other devs start getting tired of this stuff and just leave Bitcoin development to focus on more productive stuff. To many it's discouraging when the other side gets to "promise ponies" - we've got a fundamentally uphill PR battle in arguing for the development of scalability tech. For the long term, I think it'd be useful for research to be done on how to better manage these social issues. I suspect a lot of the problem - at least for non-scalable blockchain designs - stems from how centralization failures aren't gradual, and the ease of relying on trust rather than verification. While we get a lot of warning of issues, the warning isn't directly associated with losses at first, making the problem hard to explain to the general public. > === > > My personal opinion is that we - as a community - should indeed let a fee > market develop, and rather sooner than later, and that "kicking the can > down the road" is an incredibly dangerous precedent: if we are willing to > go through the risk of a hard fork because of a fear of change of > economics, then I believe that community is not ready to deal with change > at all. And some change is inevitable, at any block size. Again, this does > not mean the block size needs to be fixed forever, but its intent should be > growing with the evolution of technology, not a panic reaction because a > fear of change. Agreed. You know, those promoting the idea of a "one-time-only" blocksize increase would do well to get the stakeholders affected to publicly explain what exactly are their plans with regard to scalability in the long run. If they don't have any, then it's a strong sign that said stakeholders don't actually intend to have a "one-time-only" blocksize increase. Remember that there's no guarantee that the technology limiting the blocksize will improve as fast as desired, or even for that matter, improve at all. (bandwidth is limited by politics far more than it is limited by technology) There's strong parallels to zeroconf safety, where as far as I can tell the relevant stakeholders - pretty much all large payment providers - have no plans at all to move to genuine decentralized zeroconf technology. Rather they have backup plans to get into dangerous and centralizing mining contracts if zeroconf security gets any worse, something Coinbase even publicly admitted on this list. -- 'peter'[:-1]@petertodd.org 000000000000000014e0038d4c6614025cf655cc976fcd11ee4c4f7861136b9f -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150727/6f1d75d7/attachment.sig>