path: root/05/1eee4c3dc8bd6f1ffaf240127efab42d5ab718

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8049A49C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 22:09:30 +0000 (UTC)
Received: by pdbbh15 with SMTP id bh15so99473951pdb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <elombrozo@gmail.com>
In-Reply-To: <CA+w+GKQ_b0gMFov24nt8ZX89=GDWTpX9J15sj=fuicQBqBVcag@mail.gmail.com>
Date: Wed, 22 Jul 2015 15:09:26 -0700
Message-Id: <8CD11148-3669-43AD-A3CB-5060ED0DB37E@gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CA+w+GKTfBNsQm0X27+QeMmLvJXuX0H=8+ij_GU6mkGnWn-poZA@mail.gmail.com>
	<CAA33663-B688-4D53-8BED-85B4E67EFA0A@gmail.com>
	<CA+w+GKQ_b0gMFov24nt8ZX89=GDWTpX9J15sj=fuicQBqBVcag@mail.gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <hearn@vinumeris.com> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 22, 2015, at 3:01 PM, Mike Hearn &lt;<a =
href=3D"mailto:hearn@vinumeris.com" class=3D"">hearn@vinumeris.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><div =
class=3D"">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.</div></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">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".</div><div class=3D""><br =
class=3D""></div></div></div></div></div></blockquote><div><br =
class=3D""></div><div>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.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D"">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.</div><div class=3D""><br class=3D""></div></div></div></div>
</div></blockquote></div><br class=3D""><div class=3D"">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.</div></body></html>=

--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--