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 A32A1416 for ; Thu, 23 Jul 2015 00:13:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12AF8185 for ; Thu, 23 Jul 2015 00:13:46 +0000 (UTC) Received: by pdrg1 with SMTP id g1so146564745pdr.2 for ; Wed, 22 Jul 2015 17:13:45 -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=xucCpZh5hMSUZeesgNAvsGLXj5Cnrz4Loxr7XETIeu8=; b=F0oa5zmnuc0E0armgRWB9nBJmMKXcTqOUoj5GDLryEJwf8pq+mt+I9Ku4E7O7TgSN6 BcQjF6aLBwL3e7hI509IQT79Hf48MX3ot9YBy7EmIGhF+Dypru8ATfachwLr+qjxHhDX Zb+3JFNqCNRmxzxpqXJc1OKJDRFywR24OqSQa7JY+livXkGlGZnWwzgwGZgpQRrFcW3C gCp9XOm7YeQan1eWpsAyRnCAYliragJ/zJzx43RVMPd3vHT7c+WCJW2D/klIsrrmsrSH lC9BFyjWIBKpe4v1a7tCvsvKJzdAz1Lp6YvPjzW3arHcXBeKsdSVqX5qRR5iw9Od9qWM dfWg== X-Received: by 10.66.62.194 with SMTP id a2mr11954984pas.67.1437610425749; Wed, 22 Jul 2015 17:13:45 -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 fy5sm5310613pdb.93.2015.07.22.17.13.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 17:13:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Wed, 22 Jul 2015 17:13:42 -0700 Message-Id: References: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com> 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, 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: Thu, 23 Jul 2015 00:13:47 -0000 --Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2015, at 5:05 PM, Cory Fields wrote: >=20 > On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo = wrote: >> FWIW, I had worked on something similar a while back: >> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf >>=20 >> 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. :) >>=20 >=20 > 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=E2=80=99m 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. > 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=E2=80=9D. That=E2=80=99s 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=E2=80=A6or = without having yet built a mechanism that can merge divergent chains = gracefully. > Cory >=20 >> 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: >>=20 >> If the developers fail to reflect user consensus, the network will = let us >> know. >>=20 >>=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, >>=20 >> 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 >>=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 >>=20 >>=20 --Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC 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 iQIcBAEBCgAGBQJVsDG2AAoJEJNAI64YFENUT2EQAJfsqnfoHh1sq67w7CJ/K/Bl BJ8qT9ZUF/IZCFXPMIRbJsGJtDdrbQg8FGsrLDFByH2xMlmOKqarTx/R6wnKJu40 Oa56VmmL9CrNcTFtv61BBphQWVGUYd9Rf8hFc4IQo1/d+gmN0RMHaEgQqxOQTJqr 424Oxw0RbPW/gsBP7UM5098moxbvjhZFxZZwKlTL3tKEjMYAlsmloYTDqYg1FW7e Lk97RkTWw2E5NjksO32+Mn6LVBii11UKSTlqJRaniOEH6KXsWOXaBKleAmEpx9kJ tdadUyjrd37qjtx8JD5eyzNYk6nSr9I3RXfLFYYy1++6QYlq/zKcOGPgTaBA0HTt mgJaAj6B7Sj39iJnaO53uWRplECiZ3Oesqjbo0+w/rUvcLZZNk+EUJksp3I9fYOR j+Is6SMxd/76F3Q/rkVbBzQL0YN5Xk/HaRowLdK+fshmcFH174l4nazEbI+GFBIq g0g3UdYLpfGMgg/GLBX4WUiQjezkTt8gjdlAj018XOlpkeeZYuJ+sxgbYEpr41gO mRJpV+LD/evQsOeIgF+cPaAmtRcYWXRtetzoVC6ZXhKMw2EfqYEKjs8p5muYRVri dEbsEwC3KHCm9AaV3Cjseg0c7Ln9oDU/1PnSlQ7ONqGetj5owMiJ0tcIw3ofzgqL HHf2DifWsJjBEmLVxlC7 =CQ3d -----END PGP SIGNATURE----- --Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC--