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 B7A23B8B for ; 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 ; Sat, 27 Jun 2015 17:25:15 +0000 (UTC) Received: by wicnd19 with SMTP id nd19so40290227wic.1 for ; 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: <20150627163731.GA12820@muck> Date: Sat, 27 Jun 2015 13:25:14 -0400 Message-ID: From: Michael Naber To: Peter Todd , Mark Friedenbach , Adam Back 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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

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


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 thei= r
> respective domains, but none of them solves the global consensus probl= em
> with any greater efficiency than Bitcoin does.

Solutions like (hub-and-spoke) payment channels, Lightning, etc. all= ow
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--