From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EB00A49D for ; Wed, 22 Jul 2015 23:53:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E960FE0 for ; Wed, 22 Jul 2015 23:53:43 +0000 (UTC) Received: by pacan13 with SMTP id an13so147916366pac.1 for ; Wed, 22 Jul 2015 16:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=kR0t5FAQEZbodwqkz95hUdF/DeGJ03J4IgtUzH9lJKs=; b=h3mP+36ynTXmIPGBbf/qgl2q8t8R3PaR7pUqeOomjsWafdOr3zpWMIpF+6NUc76k4c nhEqQYL3HRXoSZt1Gp/X8fYmcTlkhdfiobIb+Udot9LVr+j1Q4Kb/jpS8CBxj5A5+C/M zoxMzkAfYMzUSkmiBXMVo2NJAhV6oXCN0eaa0icHF1FE9HVMQI069uD+W7Avq1PWjUn6 2lcFf+/C6Pm0yeEGz+Y65qlX5fdLU3A/PoS7T2TSKxnajQD2B4fYo1Rq6PO49cXL9JFv 8KcVjbKVsKUKcRFqYwSuKXL1NHB2c3qC6ADh2I4EGgsdIT9Y06/rdItD9KBOBEqtpNM0 ZW2A== X-Received: by 10.66.66.173 with SMTP id g13mr11666050pat.155.1437609223556; Wed, 22 Jul 2015 16:53:43 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id cl15sm5312454pdb.27.2015.07.22.16.53.41 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 16:53:42 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Wed, 22 Jul 2015 16:53:39 -0700 Message-Id: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com> References: To: Cory Fields X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 Cc: bitcoin-dev@lists.linuxfoundation.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 23:53:45 -0000 --Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285 Content-Type: multipart/alternative; boundary="Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82" --Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=A6but 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 = wrote: >=20 > 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. >=20 > 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. >=20 > With that in place, consensus changes would be more about lobbying and > coalitions, and less about pull requests. >=20 > Cory >=20 > On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev > wrote: >>> If the developers fail to reflect user consensus, the network will = let us >>> know. >>=20 >> 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. >>=20 >> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev >> wrote: >>=20 >> I wouldn't go quite that far. The reality is somewhere in the = middle, as >> Bryan Cheng noted in this thread: >>=20 >> 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. >>=20 >> The developers propose a new version, by publishing a new release. = The >> individual network nodes choose to accept or reject that. >>=20 >> So I respectfully disagree with "core devs don't control the network" = and >> "core devs control the network" both. >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev >> wrote: >>=20 >> Hi Pieter, >>=20 >> I think a core area of disagreement is this: >>=20 >> Bitcoin Core is not running the Bitcoin economy, and its developers = have no >> authority to set its rules. >>=20 >> 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. >>=20 >> 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: >>=20 >> 1. Swallow it even if they hate it >> 2. Fork the project and fork the block chain with it (XT) >>=20 >> 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. >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altcon= f

I like the = idea in principle=E2=80=A6but 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<= br class=3D"">


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">
_______________________________________________bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82-- --Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVsC0DAAoJEJNAI64YFENU2rAQAMAJjg4Eo/xjeUgeP+B8Qt/F gPx/RxC3DJ/NuGSrJZu0WD/BdQoeQU+1aK4vAHzsqN3c52RELaNQgY77N+QJq7tU YIGiLikDGgRVkrCis+O76i4YH1Sr3/JR+Ao8ItnWbqm6TdciiGj0JIqnZMdXzAqD 23Rka8Vp6cpfNhPp+AhysM2SHmdJK31qr/MXJjsnGvU7H1EzPhpiZmpB7NlCbi7T vOQLaiEko74MjmuB5NAWBqLbCwGrJkVDBim0qkZNYFpUKf9RcE9CBzyh2GP2R8ae xrnbA2mI8Ie1HVj9P5vL8IwKLE8jvVGFkuOiO5bEoRlmrZfr5Hbo9/bZTnmcEJhg 5tpXhKmPg9iIbZW6zV5nYQrpFNnQkAfaP1KYBF2fovdVFhfllnOdudkm3pN14RHp +xe7oHwrmPjg8Ld0fxIyLzaLquUfZ+mgPvgbhl4Sgr4gVLklbQSKEjVwBOYHP16s Ow0ZoZyuFxyeh9yM0Mh0wL9fVu/dlF0Yx/PKTTu+fO5fOqn+MayKbH/FN+m7ngmY 9GRHXLXfRPm5NKI1uAGc9I+IP5ghk+fiC50SfgOIBpZJ1NHlL+Fv5i+sMWmq8Vsf 8yKLMpr6RROzIxmSM1w2lni8aahifjJCM6Lc2FitsNk5K6pPgiu1CYxQWJNWsTEO s/rBu4MJ3Cc5jePtQjmg =10pX -----END PGP SIGNATURE----- --Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285--