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"><<a href=3D"mailto:pete@p= etertodd.org" target=3D"_blank">pete@petertodd.org</a>></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> > The goal of Bitcoin Core is to meet the demand for global consensus as= <br> > effectively as possible. Please let's keep the conversation on how= to best<br> > 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'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> > The off-chain solutions you enumerate are are useful solutions in thei= r<br> > respective domains, but none of them solves the global consensus probl= em<br> > 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> 'peter'[:-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--