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 8049A49C for ; Wed, 22 Jul 2015 22:09:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BA8BE8 for ; Wed, 22 Jul 2015 22:09:30 +0000 (UTC) Received: by pdbbh15 with SMTP id bh15so99473951pdb.1 for ; Wed, 22 Jul 2015 15:09:30 -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=NgV8UUbAK5UzG7Me+Ap7ipQ70DFqh623+yFeFKH5Efc=; b=fSfxyfbohhIYCQVkYQC1tZDZAtK5DpYgo9G4GLJEYEeahotuChCL9WZdPOzsh1J+uN 4Duzx5ZEDBj2l1iFwiIrcNRYmjWnJClHzFx5L/h1YrSQRkGXcTDRZ5fDFkCxn+OJm6Yy A9wxgAXF3hnSdA79nhKcRKtylpjWeKlMDqZ5rf/bJfmIrq8DMkLcssUjmdb7mi6RXvm0 iAMLnkG+oQVVYhVG4kfX1eUO9Pc48KjCywGGsZNKY19uHIoF8/yfq6MDmnkB3O9kbi+b pi0B6egl4nZ/qRZzVwzIHpYiTQRXsgBwsy9Ms0HcKWgjxVf2U+ZBhtV3dBHDrQGugsBh uOog== X-Received: by 10.66.155.36 with SMTP id vt4mr10837059pab.32.1437602970102; Wed, 22 Jul 2015 15:09:30 -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 xp10sm5128158pac.34.2015.07.22.15.09.27 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 15:09:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D4228C13-0957-49B2-882F-E7B2818FD22E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Wed, 22 Jul 2015 15:09:26 -0700 Message-Id: <8CD11148-3669-43AD-A3CB-5060ED0DB37E@gmail.com> References: To: Mike Hearn 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 22:09:31 -0000 --Apple-Mail=_D4228C13-0957-49B2-882F-E7B2818FD22E Content-Type: multipart/alternative; boundary="Apple-Mail=_5E5E003B-7B73-454D-955A-41D12BE2AC39" --Apple-Mail=_5E5E003B-7B73-454D-955A-41D12BE2AC39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2015, at 3:01 PM, Mike Hearn wrote: >=20 > Until we=E2=80=99re able to merge blockchain forks like we=E2=80=99re = able to merge git repo forks, the safest option is no fork. >=20 > Block chain forks merge in the same way as git forks all the time, = that's how the reorg algorithm works. Transactions that didn't make it = into the post-reorg chain go back into the mempool and miners attempt to = reinclude them: this is the "merge" process. If they now conflict with = other transactions they are dropped and this is "resolving merge = conflicts". >=20 Blockchain reorgs are part of the consensus rules. We=E2=80=99re talking = not about forks caused by network partitions=E2=80=A6but forks caused by = the use of distinct consensus rules. > However you have to want to merge with the new chain. If your software = is programmed not to do that out of some bizarre belief that throttling = your own user base is a good idea, then of course, no merge happens. = Once you stop telling your computer to do that, you can then merge = (reorg) back onto the main chain again. >=20 You cannot merge two chains that have incompatible transactions in them = without throwing away one of the two conflicting transactions (along = with all dependencies). In the reorg process, this occurs = naturally=E2=80=A6and we allow for it by using confirmation count as a = metric of irreversibility. Until one chain wins (by overwhelming = consensus) or all chains include a particular transaction in question, = we cannot treat that transaction as irreversible. Propose a model in = which we can still reliably measure irreversibility in the presence of = multiple chains and you might have a point. --Apple-Mail=_5E5E003B-7B73-454D-955A-41D12BE2AC39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn@vinumeris.com>= wrote:

Until we=E2=80=99re able to merge blockchain forks like = we=E2=80=99re able to merge git repo forks, the safest option is no = fork.

Block chain forks merge in the same way = as git forks all the time, that's how the reorg algorithm works. = Transactions that didn't make it into the post-reorg chain go back into = the mempool and miners attempt to reinclude them: this is the "merge" = process. If they now conflict with other transactions they are dropped = and this is "resolving merge conflicts".


Blockchain reorgs are part of the consensus rules. = We=E2=80=99re talking not about forks caused by network partitions=E2=80=A6= but forks caused by the use of distinct consensus rules.

However you have to want to merge = with the new chain. If your software is programmed not to do that out of = some bizarre belief that throttling your own user base is a good idea, = then of course, no merge happens. Once you stop telling your computer to = do that, you can then merge (reorg) back onto the main chain = again.


You cannot merge = two chains that have incompatible transactions in them without throwing = away one of the two conflicting transactions (along with all = dependencies). In the reorg process, this occurs naturally=E2=80=A6and = we allow for it by using confirmation count as a metric of = irreversibility. Until one chain wins (by overwhelming consensus) or all = chains include a particular transaction in question, we cannot treat = that transaction as irreversible. Propose a model in which we can still = reliably measure irreversibility in the presence of multiple chains and = you might have a point.
= --Apple-Mail=_5E5E003B-7B73-454D-955A-41D12BE2AC39-- --Apple-Mail=_D4228C13-0957-49B2-882F-E7B2818FD22E 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 iQIcBAEBCgAGBQJVsBSWAAoJEJNAI64YFENU7jMP/3E7zbEakjPZL4Xzbr0u4Vu6 oxARdr4JANzfcTsOeOBTO5lCnwVoueLcUPPbb4Z4EyvuEHEAYQrF+uZrWTJpmvyw TtpAWhZxuHuB7v5dazKEsHp5VDm57baqlIRm3nKmV08+c6RYJMGZT5IfIQ+PMgaB 7QhFHSYH4PUFUGc0xqrlds4eTLCEBqVMtGNzIIc4nqoJNu/v0viNluU7acsHan3c 1+drD5uEi4d762iocj/+8PBYdHAmo71uYnFVXXKzvq/Be8MaufRecmgG/ElLLQDG gYpZhbjHYsAtaCZ14nP/nCFTTiOBvEaF4PD1tBAbVA8Adeq1TRvvxBUflk/4Mwk1 ItI9qkUoM9255DyvkuQJ87gX7nJ1+UTwIu6fmwcLmld3PgGWLb9nbmCvotAx/bYx ABdTwjEnskMD89E4ya5Il0Hzq+1I69sg2gIl3mO/oxDSKQ1j7aRceYNbYK8bH2mI QGZdHjsuaNbWpTxj7dBFfdMP4KH9ir7WoVI69g//gxy6hSchUS/7dHRgwmPOXABF RholwUWC2TZNMu8mdRLH80hCuns2geDNlJbopu8dUVJ41OhaFyB7PjnVIFNj+V6w 7VJCi2y07GlrNAsW9qspteIMNMOkMgWcwYkIa9RlVyJJCXW3cPVR0XURoqNuqBFm zyBC+dNNYijW7CwhBcZg =cXxM -----END PGP SIGNATURE----- --Apple-Mail=_D4228C13-0957-49B2-882F-E7B2818FD22E--