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