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