From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mickeybob@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B7A23B8B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 17:25:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
	[209.85.212.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4DF1246
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 17:25:15 +0000 (UTC)
Received: by wicnd19 with SMTP id nd19so40290227wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 10:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BXEClGBZKRpe3CoxZV1Cligh6WIuw5/gumOf3hKZBOU=;
	b=GkPD59VYCak6MXgunEWF19Zbskeuewjjfx1bA01v1nxdAQc2lgNcZI0Vr0e//NQhcQ
	qZNSj1t+KIE00HNvwzNA0dHtXrnEkS2Jp5YMnrpuWlWjkZtl5bh+iM6HPjUt0aZ/8j2w
	SpWhsa3dH8KKCAsonnMlsV5xcTNVXV2bht8xmRlI9Htqn2TdT+vaFyNeQD39WXqvYcpV
	SCl1bxj3eapS23vJpbvlln83HJpl9JXLHQm5kYOnWW+VXXTgrAR1qUyY4JISrnlERmyb
	xMmGERc9rVwJfNO5RJsvnMF4JPU8fbW9jwj/UP7VKhiT7zCv+WMHBSizCMuXYOXIjesu
	AT5A==
MIME-Version: 1.0
X-Received: by 10.194.179.167 with SMTP id dh7mr14149630wjc.15.1435425914584; 
	Sat, 27 Jun 2015 10:25:14 -0700 (PDT)
Received: by 10.27.10.1 with HTTP; Sat, 27 Jun 2015 10:25:14 -0700 (PDT)
In-Reply-To: <20150627163731.GA12820@muck>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
	<CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
	<CALgxB7tdFsQXzGRje=suC7Yaym_Whhtn2qrb3ykx2ZOBwwbE7w@mail.gmail.com>
	<20150627163731.GA12820@muck>
Date: Sat, 27 Jun 2015 13:25:14 -0400
Message-ID: <CALgxB7tsmHGiGuCmcdNuwjKxNfBpdq6U+x8eK=7sL6NekAfXow@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Peter Todd <pete@petertodd.org>, Mark Friedenbach <mark@friedenbach.org>, 
	Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e0141a0a4bd86360519832335
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] A Proposed Compromise to the Block Size Limit
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: Sat, 27 Jun 2015 17:25:16 -0000

--089e0141a0a4bd86360519832335
Content-Type: text/plain; charset=UTF-8

Global network consensus means that there is global network recognition
that a particular transaction has occurred and is irreversible. The
off-chain solutions you describe, while probably useful for other purposes,
do not exhibit this characteristic and so they are not global network
consensus networks.

Bitcoin Core scales as O(N), where N is the number of transactions. Can we
do better than this while still achieving global consensus?


On Sat, Jun 27, 2015 at 12:37 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sat, Jun 27, 2015 at 12:09:16PM -0400, Michael Naber wrote:
> > The goal of Bitcoin Core is to meet the demand for global consensus as
> > effectively as possible. Please let's keep the conversation on how to
> best
> > meet that goal.
>
> Keep in mind that Andresen and Hearn both propose that the majority of
> Bitcoin users, even businesses, abandon the global consensus technology
> aspect of Bitcoin - running full nodes - and instead adopt trust
> technology instead - running SPV nodes.
>
> We're very much focused on meeting the demand for global consensus
> technology, but unfortunately global consensus is also has inherently
> O(n^2) scaling with current approaches available. Thus we have a fixed
> capacity system where access is mediated by supply and demand
> transaction fees.
>
> > The off-chain solutions you enumerate are are useful solutions in their
> > respective domains, but none of them solves the global consensus problem
> > with any greater efficiency than Bitcoin does.
>
> Solutions like (hub-and-spoke) payment channels, Lightning, etc. allow
> users of the global consensus technology in Bitcoin to use that
> technology in much more effcient ways, leveraging a relatively small
> amount of global consensus to do large numbers of transactions
> trustlessly.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>

--089e0141a0a4bd86360519832335
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Global network consensus means that there is global n=
etwork recognition that a particular transaction has occurred and is irreve=
rsible. The off-chain solutions you describe, while probably useful for oth=
er purposes, do not exhibit this characteristic and so they are not global =
network consensus networks.=C2=A0</div><div><br></div><div>Bitcoin Core sca=
les as O(N), where N is the number of transactions. Can we do better than t=
his while still achieving global consensus?=C2=A0</div><div><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jun 27, =
2015 at 12:37 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@p=
etertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Sat, Jun 27, 2015 at 12=
:09:16PM -0400, Michael Naber wrote:<br>
&gt; The goal of Bitcoin Core is to meet the demand for global consensus as=
<br>
&gt; effectively as possible. Please let&#39;s keep the conversation on how=
 to best<br>
&gt; meet that goal.<br>
<br>
</span>Keep in mind that Andresen and Hearn both propose that the majority =
of<br>
Bitcoin users, even businesses, abandon the global consensus technology<br>
aspect of Bitcoin - running full nodes - and instead adopt trust<br>
technology instead - running SPV nodes.<br>
<br>
We&#39;re very much focused on meeting the demand for global consensus<br>
technology, but unfortunately global consensus is also has inherently<br>
O(n^2) scaling with current approaches available. Thus we have a fixed<br>
capacity system where access is mediated by supply and demand<br>
transaction fees.<br>
<span class=3D""><br>
&gt; The off-chain solutions you enumerate are are useful solutions in thei=
r<br>
&gt; respective domains, but none of them solves the global consensus probl=
em<br>
&gt; with any greater efficiency than Bitcoin does.<br>
<br>
</span>Solutions like (hub-and-spoke) payment channels, Lightning, etc. all=
ow<br>
users of the global consensus technology in Bitcoin to use that<br>
technology in much more effcient ways, leveraging a relatively small<br>
amount of global consensus to do large numbers of transactions<br>
trustlessly.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
</font></span></blockquote></div><br></div>

--089e0141a0a4bd86360519832335--