path: root/bc/14fb10fa27f667709485c4bd483a83fd6d6ad1

Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B8ED4268
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 07:24:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a62.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id DF2321ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 07:24:50 +0000 (UTC)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 1D09C634075
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
	:references:from:message-id:date:mime-version:in-reply-to:
	content-type; s=jrn.me.uk; bh=QDZiPeetUQHt8kOXRIBRzS0IVTQ=; b=Gj
	1SpZ+A5oGnvaPYekd2JXdH2zwHxNiZiRKUhKJEA4xYbgyzqAVHJU4JR4/gJet/rV
	WRZfB8DQQszK8DUbRM/9VBgqt0kZop3fyVwPQFXpa0h/jwHpvxT9bMzuBN+P1wnR
	iDkAQvZknhuRxVcGueOQVoSAbdDJ5SkWfURBQZuys=
Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net
	[86.30.131.63])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: jrn@jrn.me.uk)
	by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 8629D634073
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:24:49 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
	<CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
	<068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com>
	<CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com>
	<B340ACFF-600F-45A9-BFE9-B831A4C6DD8E@gmail.com>
	<CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
	<D02A0586-83CA-4BD6-B607-73570C695081@gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55B096C0.8000207@jrn.me.uk>
Date: Thu, 23 Jul 2015 08:24:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <D02A0586-83CA-4BD6-B607-73570C695081@gmail.com>
Content-Type: multipart/alternative;
	boundary="------------040503050509010203060903"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 07:24:52 -0000

This is a multi-part message in MIME format.
--------------040503050509010203060903
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

The code so far is fairly limited in scope, essentially making it=20
possible to change the values in consensus/params.h based on block=20
height. The actual code to interpret those values does need to be=20
provided ahead of time, of course, so there's still developer time to=20
implement, it just moves consensus arguments to the users.

Loading the values from disk rather than hard-coding them is a=20
reasonably straight forward extension to the code, in theory. The=20
existing work has application-specific changes that would need stripping=20
out, but you can get an idea of what this would look like from=20
https://github.com/rnicoll/dogecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f=
36c1085904

Ross

On 23/07/2015 01:43, Eric Lombrozo via bitcoin-dev wrote:
>> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists@coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail.com> w=
rote:
>>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields.com> wrot=
e:
>>>>
>>>> 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=85but we should require a new genesis =
block,
>>>>> different magic bytes, and a different network port at the very lea=
st. :)
>>>>>
>>>> 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 straight=
forward and easy to test. I=92m not in favor of encouraging forking an ex=
isting 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.
> In general, new consensus rules are not trivial to implement. Block siz=
e limits are exceptional in being so simple to change in the code. So wha=
t you=92re proposing sounds more like a plugin model supporting dynamic l=
inking than a configuration file.
>
>>>> 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=94.
>>> That=92s exactly what my coinparams_new branch does. Adding a paramet=
er 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 differe=
nt
>>>> than suggesting that someone fork the codebase and implement their o=
wn
>>>> changes, it just cuts out most of the work required.
>>> I do not encourage anyone to try to fork an existing blockchain witho=
ut first securing overwhelming (near unanimous) consensus=85or without ha=
ving 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.
> The real problem isn=92t so much the difficulty of creating forks of th=
e codebase - but the fact that unless a fork has overwhelming support, bl=
ockchains cannot guarantee irreversibility of transactions=85which defeat=
s their entire purpose.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------040503050509010203060903
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    The code so far is fairly limited in scope, essentially making it
    possible to change the values in consensus/params.h based on block
    height. The actual code to interpret those values does need to be
    provided ahead of time, of course, so there's still developer time
    to implement, it just moves consensus arguments to the users.<br>
    <br>
    Loading the values from disk rather than hard-coding them is a
    reasonably straight forward extension to the code, in theory. The
    existing work has application-specific changes that would need
    stripping out, but you can get an idea of what this would look like
    from
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/rnicoll/dog=
ecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f36c1085904">https://github.com=
/rnicoll/dogecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f36c1085904</a><br>
    <br>
    Ross<br>
    <br>
    <div class=3D"moz-cite-prefix">On 23/07/2015 01:43, Eric Lombrozo via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:D02A0586-83CA-4BD6-B607-73570C695081@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">On Jul 22, 2015, at 5:34 PM, Cory Fields <a class=3D=
"moz-txt-link-rfc2396E" href=3D"mailto:lists@coryfields.com">&lt;lists@co=
ryfields.com&gt;</a> wrote:

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <a class=3D"moz-txt-link-r=
fc2396E" href=3D"mailto:elombrozo@gmail.com">&lt;elombrozo@gmail.com&gt;<=
/a> wrote:
</pre>
        <blockquote type=3D"cite">
          <pre wrap=3D"">
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">On Jul 22, 2015, at 5:05 PM, Cory Fields <a cl=
ass=3D"moz-txt-link-rfc2396E" href=3D"mailto:lists@coryfields.com">&lt;li=
sts@coryfields.com&gt;</a> wrote:

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <a class=3D"moz-txt-link-r=
fc2396E" href=3D"mailto:elombrozo@gmail.com">&lt;elombrozo@gmail.com&gt;<=
/a> wrote:
</pre>
            <blockquote type=3D"cite">
              <pre wrap=3D"">FWIW, I had worked on something similar a wh=
ile back:
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/CodeShark/b=
itcoin/tree/coinparams_new/altconf">https://github.com/CodeShark/bitcoin/=
tree/coinparams_new/altconf</a>

I like the idea in principle=85but we should require a new genesis block,
different magic bytes, and a different network port at the very least. :)

</pre>
            </blockquote>
            <pre wrap=3D"">
Not sure if serious, so I'll assume you are :)
</pre>
          </blockquote>
          <pre wrap=3D"">
Only being partly serious - I strongly am in favor of a sufficiently modu=
larized codebase that swapping out consensus rules is fairly straightforw=
ard and easy to test. I=92m not in favor of encouraging forking an existi=
ng blockchain without having mechanisms in place to gracefully merge back=
 without significant network disruptions. We do not have this yet.

</pre>
        </blockquote>
        <pre wrap=3D"">
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.
</pre>
      </blockquote>
      <pre wrap=3D"">
In general, new consensus rules are not trivial to implement. Block size =
limits are exceptional in being so simple to change in the code. So what =
you=92re proposing sounds more like a plugin model supporting dynamic lin=
king than a configuration file.

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre wrap=3D"">Why? The idea in this case would be to allow t=
he user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork=94.
</pre>
          </blockquote>
          <pre wrap=3D"">
That=92s exactly what my coinparams_new branch does. Adding a parameter f=
or maximum block size would be straightforward.

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">Chain params may be identical other than the v=
alue of some future
event (miner vote for example), in which case the configs would run
identically until that point.
</pre>
          </blockquote>
          <pre wrap=3D"">
Yes, indeed - this would be a special case.

</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">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.
</pre>
          </blockquote>
          <pre wrap=3D"">
I do not encourage anyone to try to fork an existing blockchain without f=
irst securing overwhelming (near unanimous) consensus=85or without having=
 yet built a mechanism that can merge divergent chains gracefully.
</pre>
        </blockquote>
        <pre wrap=3D"">
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.
</pre>
      </blockquote>
      <pre wrap=3D"">
The real problem isn=92t so much the difficulty of creating forks of the =
codebase - but the fact that unless a fork has overwhelming support, bloc=
kchains cannot guarantee irreversibility of transactions=85which defeats =
their entire purpose.
</pre>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------040503050509010203060903--