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 5FA259D for ; Thu, 23 Jul 2015 00:34:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AF56143 for ; Thu, 23 Jul 2015 00:34:25 +0000 (UTC) Received: by wibud3 with SMTP id ud3so2041146wib.1 for ; Wed, 22 Jul 2015 17:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SBpU/PbqZW1QTwjfn+5gn2xFTPfX3uwmH8QioktwRWE=; b=E+0nWQTn9lYz4aNuDtY3/IKZD73aZFbWzfnAaziQOHldk3XezkBexvoJdYnAYY1Sfc xu0a2FhQVZIPgbH6J94INM+klwCgQ8XRszBcrVc53T/s+yh9haVmGok2NGHsfDNa9fwn lG9gjvvqdohqpebkRNchJ4d/bGvAcg6Rrz+LAFRQ5BeaO1FaEaZjch8V6cIrKPKTaGpK wcT/WllBGPE1J41l3SUouklQ7QOwPxELmeVKW/V29dlAN6Wo0tEuSsBTee5AMaQbish9 1keYaXzMGC5UQf4r7+7iI4GmuOkfB82ABgrcja4/SSuNxOLKd54pBqRiyDZCDmDfR+iq oxbQ== X-Gm-Message-State: ALoCoQm4a26+JVnD2sI4+Uxx5q0f3sYOKTNEXDORf4P4Q1eje0jWp7227rh2xEEonXvYQI3wi7pi MIME-Version: 1.0 X-Received: by 10.180.99.71 with SMTP id eo7mr11535178wib.25.1437611664177; Wed, 22 Jul 2015 17:34:24 -0700 (PDT) Received: by 10.194.168.167 with HTTP; Wed, 22 Jul 2015 17:34:23 -0700 (PDT) In-Reply-To: References: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com> Date: Wed, 22 Jul 2015 20:34:23 -0400 Message-ID: From: Cory Fields To: Eric Lombrozo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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:34:26 -0000 On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo wrote: > >> On Jul 22, 2015, at 5:05 PM, Cory Fields wrote: >> >> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo wro= te: >>> 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 genesi= s 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 modu= larized codebase that swapping out consensus rules is fairly straightforwar= d and easy to test. I=E2=80=99m not in favor of encouraging forking an exis= ting 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=E2=80=9D. > > That=E2=80=99s exactly what my coinparams_new branch does. Adding a param= eter 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 f= irst securing overwhelming (near unanimous) consensus=E2=80=A6or 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.