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 5737745E for ; Thu, 23 Jul 2015 00:43:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6475153 for ; Thu, 23 Jul 2015 00:43:05 +0000 (UTC) Received: by pdrg1 with SMTP id g1so146920233pdr.2 for ; Wed, 22 Jul 2015 17:43:05 -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=USxp+Tkg1IsCDpHIqfQ/KDtQzOnPljesxAx/YI6yTKA=; b=WsPlCtdVWXLruoKxZADM6G0N1RdJBKOLDF2Gn/NGLOrWCpDJfPZN9nwU2jXjdxqg6G Ic67AkXGQLTDB3Le8jgJmNqx0JKpi/UltED5Ujk7bIvpafDXx26Yw1PlPXuRv4UKhQTi gZtjh2D+/XthZdWPNE4G3KWKxYuJR2TLzOP0aMS1Ni3fEW+L0Wfrm6yL4GIas/MHcQdj o/7eF+ATighpJzUlBcVLdc4ZbbG4wZj7RzPv/8FIxyjUQmum1xDXq/O5F3t4reLNdYSX hKyrYLhLpsKO1gUyPNVQ/4qzRjEepxGoTHqncNOupgq2lpnxdI3A0gwBAC3bYo4/j7Vs OFmA== X-Received: by 10.66.162.198 with SMTP id yc6mr12062530pab.74.1437612185544; Wed, 22 Jul 2015 17:43:05 -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 t2sm5383741pdo.81.2015.07.22.17.43.03 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 17:43:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4"; 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:43:02 -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:43:06 -0000 --Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2015, at 5:34 PM, Cory Fields wrote: >=20 > On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo = wrote: >>=20 >>> 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 :) >>=20 >> 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. >>=20 >=20 > 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 size = limits are exceptional in being so simple to change in the code. So what = you=E2=80=99re proposing sounds more like a plugin model supporting = dynamic linking 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=E2=80=9D. >>=20 >> That=E2=80=99s exactly what my coinparams_new branch does. Adding a = parameter for maximum block size would be straightforward. >>=20 >>> 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. >>=20 >> Yes, indeed - this would be a special case. >>=20 >>> 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. >>=20 >> 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. >=20 > 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=E2=80=99t so much the difficulty of creating forks = of the codebase - but the fact that unless a fork has overwhelming = support, blockchains cannot guarantee irreversibility of = transactions=E2=80=A6which defeats their entire purpose. --Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4 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 iQIcBAEBCgAGBQJVsDiWAAoJEJNAI64YFENUVwMP/j8//ocBVHxp1JeI+k3WppT5 0z6+yyCIR8eo5lyAj/ngAM1Jcah7l75/bYwcP0RjqS9cBxV5FlTBv0/bosTx9boK ix7jE68X0jVq8fiUIhm7sFHbjdfx0c4/eh63MFjNdopDA7wXRKEzuf0CzJQQ5QkJ skvvNXf8nuSoHoff+55kTiiGob1BT8xdxaenIB9VRgYAITOSJbqPVp8QeimzIGYd XGTG8Xp4Bg+AttdJFDjsE/1lnKRv1Xzt2Ti7U8nHXkU0KBQ6nl5oVW+fGCtFEld3 3e8/AcW/bTgrrkOA5F1IV9gjbA8WoSaGqo6RUCY0o7tl8etkoREU/Xj9g/VZ7gLi MgVU+1lMspx40lktoFJEc5aHzXLiKAErcZ6EMpJ7RQ9ot38DMeLZBdFhr/+LOQYE /6oysni7UbAvZL3GLzDFcjQ+R1ojkb1efXF4Iq6QafcarGF5YymjAtXRrxTg/STU UNN/XcvoCTyRKroPjiKSvr6tBRh1K1X9OpUT3kqLY16MpKHIR7I5p0oJ13F2J61e shes8FV2EqKMTfef7c4lO1gi+8INe4B2qroExVkyupE+cYaPk3KSv2YLqYd29nVv OQfXj/mbtB1RTWS9+C4YsLSwyRtx+2Hua4u+uWQQLFkar98GEFPZWGug6Gmo2uc/ OhM7vpdr0u7BQCbTKa/a =9mEl -----END PGP SIGNATURE----- --Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4--