Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4984DB1B for ; Sun, 28 Jun 2015 21:23:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 575B0FD for ; Sun, 28 Jun 2015 21:23:53 +0000 (UTC) Received: by wgck11 with SMTP id k11so126474724wgc.0 for ; Sun, 28 Jun 2015 14:23:52 -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=nQhdqJm0EHVNbK4E2OfyXtl0DswqZ3GwGop/v9dfDaI=; b=N1AiAR7VHDILC5HkoY2j22GH9YZRTKfVaJCdup8l0WKljCqouHodXgLVXZMTBGPwYS JdFAWR1qVXwF1XoJrUW0ZldInJM0WXfJZB4vxIFVjeDTa+/qK/uHMoOxpdN9eZSRb/jN N9srRR0iNJWqimtQSbnFMHaUEaaFNSRTiFOU3JVqzhN7F8lIB7ydZzA9ZzjBvbmXnjZm ZkONh528VCNpydfduRyGxqDccZ6NvBWk3MdEj6GphmF4CjH6whpkD9Wk+d5EZEV9x7hl 1Ns9v6gshd0ATf9zUB6PRXCwPXnEfHHi2phDNK/cSZWA/spT2WEtq5pr5xRfElXEzJSp CrhQ== MIME-Version: 1.0 X-Received: by 10.194.179.167 with SMTP id dh7mr23854639wjc.15.1435526632076; Sun, 28 Jun 2015 14:23:52 -0700 (PDT) Received: by 10.27.10.1 with HTTP; Sun, 28 Jun 2015 14:23:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jun 2015 17:23:51 -0400 Message-ID: From: Michael Naber To: Gavin Andresen , Peter Todd , Adam Back Content-Type: multipart/alternative; boundary=089e0141a0a4f87c5d05199a961d 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: Sun, 28 Jun 2015 21:23:54 -0000 --089e0141a0a4f87c5d05199a961d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bitcoin Core exists to solve the global consensus problem. Global network consensus means that there is global network recognition that a particular transaction has occurred and is irreversible. Systems like hub-and-spoke, payment channels, Lightning, etc. are useful, but they are not solutions to the global consensus problem, because they do not meet this definition of global consensus. Let us focus our efforts on the goal of making Bitcoin Core the best solution to the global consensus problem. Let us address Peter Todd=E2=80= =99s requirements to raise the block size limit to 8MB: 1) Run a successful test-net with 8MB blocks and show that the network works and small miners are not unduly disadvantaged 2) Address Peter Todd's concern: =E2=80=9Cwithout scarcity of blockchain sp= ace there is no reason to think that transaction fees won=E2=80=99t fall to the marginal cost of including a transaction, which doesn=E2=80=99t leave anyth= ing to pay for proof-of-work security=E2=80=9D Regarding 1: This is not done yet, though it seems reasonable enough to do. Regarding 2: It is a fallacy to believe that artificially constraining capacity of Bitcoin Core below the limits of technology will lead to increased fees and therefore lead to sufficient security in the far-future. Constraining capacity below the limits of technology will ultimately only drive users seeking global consensus to solutions other than Bitcoin Core, perhaps through a fork. Demand for user access to high-capacity global consensus is real, and the technology exists to deliver it; if we don't meet that demand in Bitcoin Core, it's inevitably going to get met through some other product. Let's not let that happen. Let's keep Bitcoin Core the best solution to the global consensus problem. Thoughts? Is there anything else not mentioned above which anyone would like done in order to raise the block size to a static 8 MB? On Sun, Jun 28, 2015 at 5:05 PM, Gavin Andresen wrote: > On Sun, Jun 28, 2015 at 2:58 PM, Adam Back wrote: > >> This is probably going to sound impolite, but I think it's pertinent. >> >> Gavin, on dwelling on the the fact that you appear to not understand >> the basics of the lightning network, I am a little alarmed about this > > > If I don't see how switching from using the thousands of fully-validating > bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better = in > terms of decentralization (or security, in terms of Sybil/DoS attacks), > then I doubt other people do, either. You need to do a better job of > explaining it. > > But even if you could convince me that it WAS better from a > security/decentralization point of view: > > a) Lightning Network is nothing but a whitepaper right now. We are a long > way from a practical implementation supported by even one wallet. > > b) The Lightning Network paper itself says bigger blocks will be needed > even if (especially if!) Lightning is wildly successful. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e0141a0a4f87c5d05199a961d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bitcoin Core exists to solve the global consensus pro= blem. Global network consensus means that there is global network recogniti= on that a particular transaction has occurred and is irreversible. Systems = like hub-and-spoke, payment channels, Lightning, etc. are useful, but they = are not solutions to the global consensus problem, because they do not meet= this definition of global consensus.=C2=A0

Let us= focus our efforts on the goal of making Bitcoin Core the best solution to = the global consensus problem. Let us address Peter Todd=E2=80=99s requireme= nts to raise the block size limit to 8MB:

1) Run a= successful test-net with 8MB blocks and show that the network works and sm= all miners are not unduly disadvantaged

2) Address= Peter Todd's concern: =E2=80=9Cwithout scarcity of blockchain space th= ere is no reason to think that transaction fees won=E2=80=99t fall to the m= arginal cost of including a transaction, which doesn=E2=80=99t leave anythi= ng to pay for proof-of-work security=E2=80=9D

Rega= rding 1: This is not done yet, though it seems reasonable enough to do.

Regarding 2: It is a fallacy to believe that artifici= ally constraining capacity of Bitcoin Core below the limits of technology w= ill lead to increased fees and therefore lead to sufficient security in the= far-future. Constraining capacity below the limits of technology will ulti= mately only drive users seeking global consensus to solutions other than Bi= tcoin Core, perhaps through a fork.=C2=A0

Demand f= or user access to high-capacity global consensus is real, and the technolog= y exists to deliver it; if we don't meet that demand in Bitcoin Core, i= t's inevitably going to get met through some other product. Let's n= ot let that happen. Let's keep Bitcoin Core the best solution to the gl= obal consensus problem.

Thoughts? Is there anythin= g else not mentioned above which anyone would like done in order to raise t= he block size to a static 8 MB?

<= div class=3D"gmail_quote">On Sun, Jun 28, 2015 at 5:05 PM, Gavin Andresen <= span dir=3D"ltr"><gavinandresen@gmail.com> wrote:
On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <= adam@cypherspace.org> wrote:
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--089e0141a0a4f87c5d05199a961d--