From: Cory Fields <lists@coryfields•com>
To: Eric Lombrozo <elombrozo@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Wed, 22 Jul 2015 20:34:23 -0400 [thread overview]
Message-ID: <CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com> (raw)
In-Reply-To: <B340ACFF-600F-45A9-BFE9-B831A4C6DD8E@gmail.com>
On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields•com> wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@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.
next prev parent reply other threads:[~2015-07-23 0:34 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
2015-07-23 0:05 ` Cory Fields
2015-07-23 0:13 ` Eric Lombrozo
2015-07-23 0:34 ` Cory Fields [this message]
2015-07-23 0:43 ` Eric Lombrozo
2015-07-23 7:24 ` Ross Nicoll
2015-07-23 0:49 ` Eric Voskuil
2015-07-23 18:12 ` Jorge Timón
-- strict thread matches above, loose matches on Subject: below --
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28 4:55 ` Wladimir J. van der Laan
[not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23 8:24 ` Gareth Williams
[not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` Pieter Wuille
2015-07-22 17:18 ` Ross Nicoll
2015-07-22 17:32 ` Milly Bitcoin
2015-07-22 18:45 ` Bryan Cheng
2015-07-22 17:33 ` Jeff Garzik
2015-07-22 18:01 ` Jeff Garzik
2015-07-22 18:03 ` Alex Morcos
2015-07-22 18:24 ` Jeff Garzik
2015-07-23 12:17 ` Jorge Timón
2015-07-23 16:17 ` Tom Harding
2015-07-23 16:28 ` Gavin Andresen
2015-07-23 16:50 ` cipher anthem
2015-07-23 17:14 ` Robert Learney
2015-07-23 18:21 ` Eric Lombrozo
2015-07-23 18:47 ` Jorge Timón
2015-07-23 17:43 ` Eric Lombrozo
2015-07-23 18:10 ` Jameson Lopp
2015-07-23 19:14 ` Eric Lombrozo
2015-07-23 19:35 ` Gavin Andresen
2015-07-23 19:39 ` Eric Lombrozo
2015-07-23 19:51 ` Eric Lombrozo
2015-07-23 19:52 ` Jameson Lopp
2015-07-23 20:26 ` Jorge Timón
2015-07-23 20:52 ` Eric Lombrozo
2015-07-23 23:42 ` Benedict Chan
[not found] ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57 ` Eric Lombrozo
2015-07-24 0:04 ` Eric Lombrozo
2015-07-24 0:20 ` Simon Liu
2015-07-24 0:22 ` Jean-Paul Kogelman
2015-07-24 0:32 ` Eric Lombrozo
2015-07-24 0:38 ` Eric Lombrozo
2015-07-24 0:45 ` Jean-Paul Kogelman
2015-07-24 0:49 ` Jean-Paul Kogelman
2015-07-24 0:53 ` Peter Todd
2015-07-24 1:03 ` Jean-Paul Kogelman
2015-07-24 1:08 ` Eric Lombrozo
2015-07-24 1:25 ` Jean-Paul Kogelman
2015-07-24 1:28 ` Eric Lombrozo
2015-07-24 1:37 ` Eric Lombrozo
2015-07-24 1:42 ` Jean-Paul Kogelman
2015-07-24 1:55 ` Eric Lombrozo
2015-07-24 0:56 ` Eric Lombrozo
2015-07-24 1:05 ` Jean-Paul Kogelman
2015-07-23 18:12 ` Slurms MacKenzie
2015-07-23 18:57 ` Mike Hearn
2015-07-23 17:51 ` Jorge Timón
2015-07-24 6:30 ` Tom Harding
2015-07-24 9:24 ` Jorge Timón
2015-07-24 22:50 ` Tom Harding
2015-07-28 11:29 ` Jorge Timón
2015-07-28 11:32 ` Jorge Timón
2015-07-28 16:44 ` Tom Harding
2015-07-28 17:33 ` Jorge Timón
2015-07-22 19:17 ` Eric Lombrozo
2015-07-22 21:43 ` Mike Hearn
2015-07-22 21:56 ` Eric Lombrozo
2015-07-22 22:01 ` Mike Hearn
2015-07-22 22:09 ` Eric Lombrozo
2015-07-23 1:53 ` Eric Lombrozo
2015-07-22 22:30 ` Jeff Garzik
2015-07-23 0:27 ` Tom Harding
2015-07-23 0:37 ` Eric Lombrozo
2015-07-23 4:40 ` Edmund Edgar
2015-07-27 12:08 ` Peter Todd
2015-07-27 12:44 ` Milly Bitcoin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com \
--to=lists@coryfields$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=elombrozo@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox