path: root/31/d383587d0b607406f3998c8070bb5eefe08224

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 4984DB1B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 21:23:53 +0000 (UTC)
Received: by wgck11 with SMTP id k11so126474724wgc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CABsx9T3Xhu4n3LzjEjanbAnUr5UeG0DzY7HXchfOvEa+BNqakw@mail.gmail.com>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
	<CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com>
	<CAOoPuRarNoPwLxVqjJ_g4b6HsWJecB-oCdfEjaknKbUnKdnmEg@mail.gmail.com>
	<CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com>
	<COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl>
	<CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>
	<CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>
	<CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@mail.gmail.com>
	<CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
	<CABsx9T3Xhu4n3LzjEjanbAnUr5UeG0DzY7HXchfOvEa+BNqakw@mail.gmail.com>
Date: Sun, 28 Jun 2015 17:23:51 -0400
Message-ID: <CALgxB7uuC0NbQnAVLqypF6OdZ-ETJVGn5T6FGMfuB2f=zR0VnA@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>, Peter Todd <pete@petertodd.org>, 
	Adam Back <adam@cypherspace.org>
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 <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: 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 <gavinandresen@gmail.com>
wrote:

> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam@cypherspace.org> 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

<div dir=3D"ltr"><div>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</div><div><br></div><div>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:</div><div><br></div><div>1) Run a=
 successful test-net with 8MB blocks and show that the network works and sm=
all miners are not unduly disadvantaged</div><div><br></div><div>2) Address=
 Peter Todd&#39;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</div><div><br></div><div>Rega=
rding 1: This is not done yet, though it seems reasonable enough to do.</di=
v><div><br></div><div>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</div><div><br></div><div>Demand f=
or user access to high-capacity global consensus is real, and the technolog=
y exists to deliver it; if we don&#39;t meet that demand in Bitcoin Core, i=
t&#39;s inevitably going to get met through some other product. Let&#39;s n=
ot let that happen. Let&#39;s keep Bitcoin Core the best solution to the gl=
obal consensus problem.</div><div><br></div><div>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></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Sun, Jun 28, 2015 at 5:05 PM, Gavin Andresen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_=
blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D"">On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">=
adam@cypherspace.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">This is probably going to sound impolite, but I think it&#39;s pertinent.=
<br>
<br>
Gavin, on dwelling on the the fact that you appear to not understand<br>
the basics of the lightning network, I am a little alarmed about this</bloc=
kquote><div><br></div></span><div>If I don&#39;t see how switching from usi=
ng the thousands of fully-validating bitcoin nodes with (tens? hundreds?) o=
f Lightning Network hubs is better in terms of decentralization (or securit=
y, in terms of Sybil/DoS attacks), then I doubt other people do, either. Yo=
u need to do a better job of explaining it.</div><div><br></div><div>But ev=
en if you could convince me that it WAS better from a security/decentraliza=
tion point of view:</div><div><br></div><div>a) Lightning Network is nothin=
g but a whitepaper right now. We are a long way from a practical implementa=
tion supported by even one wallet.</div><div><br></div><div>b) The Lightnin=
g Network paper itself says bigger blocks will be needed even if (especiall=
y if!) Lightning is wildly successful.</div><div><br></div><div><br></div><=
/div>
</div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--089e0141a0a4f87c5d05199a961d--