<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">FWIW, I had worked on something similar a while back:&nbsp;<a href="https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf" class="">https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf</a><div class=""><br class=""></div><div class="">I like the idea in principle…but we should require a new genesis block, different magic bytes, and a different network port at the very least. :)</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">I'm not sure why Bitcoin Core and the rules and policies that it<br class="">enforces are being conflated in this thread. There's nothing stopping<br class="">us from adding the ability for the user to decide what their consensus<br class="">parameters should be at runtime. In fact, that's already in use:<br class="">./bitcoind -testnet. As mentioned in another thread, the chain params<br class="">could even come from a config file that the user could edit without<br class="">touching the code.<br class=""><br class="">I realize that it'd be opening Pandora's Box, and likely met with very<br class="">loud and reasonable arguments about the obvious terrible implications,<br class="">but it's at least an alternative to the current status quo of Core's<br class="">conflation with the consensus rules. The idea really is no different<br class="">than suggesting that someone fork the codebase and implement their own<br class="">changes, it just cuts out most of the work required.<br class=""><br class="">With that in place, consensus changes would be more about lobbying and<br class="">coalitions, and less about pull requests.<br class=""><br class="">Cory<br class=""><br class="">On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev<br class="">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">If the developers fail to reflect user consensus, the network will let us<br class="">know.<br class=""></blockquote><br class="">This is true with the caveat that there must be more than one option present<br class="">for the network to show it's preference. &nbsp;If developers discourage anything<br class="">that forks from the rules enforced by Bitcoin Core, they harm the network's<br class="">ability to inform us of a failure to reflect user consensus.<br class=""><br class="">On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev<br class="">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br class=""><br class="">I wouldn't go quite that far. &nbsp;The reality is somewhere in the middle, as<br class="">Bryan Cheng noted in this thread:<br class=""><br class="">Quoting BC,<br class=""><blockquote type="cite" class="">Upgrading to a version of Bitcoin Core that is incompatible with your<br class="">ideals is in no way a forced choice, as you have stated in your email;<br class="">forks, alternative clients, or staying on an older version are all valid<br class="">choices. If the majority of the network chooses not to endorse a specific<br class="">change, then the majority of the network will continue to operate just fine<br class="">without it, and properly structured consensus rules will pull the minority<br class="">along as well.<br class=""></blockquote><br class="">The developers propose a new version, by publishing a new release. &nbsp;The<br class="">individual network nodes choose to accept or reject that.<br class=""><br class="">So I respectfully disagree with "core devs don't control the network" and<br class="">"core devs control the network" both.<br class=""><br class="">There are checks-and-balances that make the system work. &nbsp;Consensus is most<br class="">strongly measured by user actions after software release. &nbsp;If the developers<br class="">fail to reflect user consensus, the network will let us know.<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class="">On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev<br class="">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br class=""><br class="">Hi Pieter,<br class=""><br class="">I think a core area of disagreement is this:<br class=""><br class="">Bitcoin Core is not running the Bitcoin economy, and its developers have no<br class="">authority to set its rules.<br class=""><br class="">In fact Bitcoin Core is running the Bitcoin economy, and its developers do<br class="">have the authority to set its rules. This is enforced by the reality of<br class="">~100% market share and limited github commit access.<br class=""><br class="">You may not like this situation, but it is what it is. By refusing to make a<br class="">release with different rules, people who disagree are faced with only two<br class="">options:<br class=""><br class="">1. Swallow it even if they hate it<br class="">2. Fork the project and fork the block chain with it (XT)<br class=""><br class="">There are no alternatives. People who object to (2) are inherently<br class="">suggesting (1) is the only acceptable path, which not surprisingly, makes a<br class="">lot of people very angry.<br class=""><br class="">_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">bitcoin-dev mailing list<br class="">bitcoin-dev@lists.linuxfoundation.org<br class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br class=""><br class=""></blockquote>_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br class=""></div></blockquote></div><br class=""></div></body></html>