On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombr...@gmail.com> wrote: > >> On Jul 22, 2015, at 5:05 PM, Cory Fields <li...@coryfields.com> wrote: >> >> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombr...@gmail.com> wrote: >>> FWIW, I had worked on something similar a while back: >>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf >>> >>> 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. :) >>> >> >> Not sure if serious, so I'll assume you are :) > > Only being partly serious - I strongly am in favor of a sufficiently > modularized codebase that swapping out consensus rules is fairly > straightforward and easy to test. I’m not in favor of encouraging forking an > existing blockchain without having mechanisms in place to gracefully merge > back without significant network disruptions. We do not have this yet. >
Again, why? If someone wants to create a scamcoin, they can. If someone wants to burn money on a scamcoin, equally, they can. I'm not sure how this is any different. If someone manages to garner realistic support for a hard-fork, I don't see the benefit in forcing them to use forked software.. that only leaves Core in the middle because it's forced to choose a side (not choosing is unfortunately a side as well). It doesn't remove the reality of the split. >> Why? The idea in this case would be to allow the user to decide >> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at >> runtime rather than the likely alternative of "./bitcoind" vs >> "./bitcoin-fork”. > > That’s exactly what my coinparams_new branch does. Adding a parameter for > maximum block size would be straightforward. > >> Chain params may be identical other than the value of some future >> event (miner vote for example), in which case the configs would run >> identically until that point. > > Yes, indeed - this would be a special case. > >> If your concern is about nodes with different configs communicating >> with eachother, I'd like to reiterate: 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. > > I do not encourage anyone to try to fork an existing blockchain without first > securing overwhelming (near unanimous) consensus…or without having yet built > a mechanism that can merge divergent chains gracefully. Well of course. It would be a terrible idea. People would try it and fail, and lose money. But for those crying foul at Core for being the consensus/policy gatekeeper, it seems to me that user-selectable params is the only logical solution. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
