{"type":"rich","version":"1.0","author_name":"Jameson Lopp [ARCHIVE] (npub1gh…akqmn)","author_url":"https://nostr.ae/npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-17\n📝 Original message:On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik \u003cjgarzik at gmail.com\u003e wrote:\n\u003e \u003e\u003e You present this as if the Bitcoin Core development team is in charge\n\u003e \u003e\u003e of deciding the network consensus rules, and is responsible for making\n\u003e \u003e\u003e changes to it in order to satisfy economic demand. If that is the\n\u003e \u003e\u003e case, Bitcoin has failed, in my opinion.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e This circles back to Problem #1:   Avoidance of a choice is a still a\n\u003e choice\n\u003e \u003e - failing to ACK a MAX_BLOCK_SIZE increase still creates very real\n\u003e Economic\n\u003e \u003e Change Event risk.\n\u003e\n\u003e We are not avoiding a choice. We don't have the authority to make a choice.\n\u003e\n\u003e \u003e And #3:  If the likely predicted course is that Bitcoin Core will not\n\u003e accept\n\u003e \u003e a protocol change changing MAX_BLOCK_SIZE via hard fork in the short\n\u003e term,\n\u003e \u003e the core dev team should communicate that position clearly to users and\n\u003e \u003e media.\n\u003e\n\u003e I indeed think we can communicate much better that deciding consensus\n\u003e rules is not within our power.\n\u003e\n\nIndeed, because I sometimes find these statements to be confusing as well -\nI can completely understand what you mean if you're speaking from a moral\nstandpoint. If you're saying that it's unacceptable for the Bitcoin Core\ndevelopers to force consensus changes upon the system, I agree. But\nthankfully the design of the system does not allow the developers to do so.\nDevelopers can commit amazing code or terrible code, but it must be\nvoluntarily adopted by the rest of the ecosystem. Core developers can't\ndecide these changes, they merely propose them to the ecosystem by writing\nand releasing code.\n\nI agree that Core developers have no authority to make these decisions on\nbehalf of all of the network participants. However, they are in a position\nof authority when it comes to proposing changes. One of my takeaways from\nHong Kong was that most miners have little interest in taking\nresponsibility for consensus changes - they trust the Core developers to\nuse their expertise to propose changes that will result in the continued\noperation of the network and not endanger their business operations.\n\nA non-trivial portion of the ecosystem is requesting that the Core\ndevelopers make a proposal so that the network participants can make a\nchoice. Jeff noted that we can expect for the economic conditions of the\nnetwork to change significantly in 2016, barring higher throughput\ncapacity. If the year+ deployment timeframe for hard forks proposed by Matt\non another thread is what we can expect for any proposed consensus change,\nthen it should be non-contentious to announce that there will be no hard\nfork in 2016. This will give clarity to the rest of the ecosystem as to how\nthey should prepare.\n\n\n\u003e --\n\u003e Pieter\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/ba83fcba/attachment.html\u003e"}