path: root/72/fcc66caf0d3c3dab81451c715661dd26cebb6b

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 C52CE273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 16:09:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
	[209.85.212.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3E3C1AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 16:09:17 +0000 (UTC)
Received: by wicgi11 with SMTP id gi11so40119857wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 09:09:16 -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=YxY+FLTmsuKlEtqhfEujyugKZdrfvDSbqlBsmUgdCm8=;
	b=eVVSBOU4Kq0vPjZxCTWJBYNGMF7anF35IQeQnnBVh59nedd0HEXXZQv75f/QtIqFkJ
	fiy897g0swad3MpbW8Cqd/+X4K26OsSBNOXybPZB7ZyQGxKJbawDl1/NJSkZh7jqYI1h
	pkVUIPaCRs7/F+rPjUKXSrEU5/ExlzFWXnpzeQ7q5b9VMk4RaZuhjuWvloG6ScZNgpem
	kjprCj2GXp0LXmutvDYJQm8TCVbovhxr/UJYPfUVpOoYKOA2Mu8w6nfFwWvlbN6JqA9n
	Fgc5nKXLk701SD0kWh47oUR5RpAeWf89doGtSfT4U31x8GWNVEXpg8p1+sCULB7S8MnQ
	145w==
MIME-Version: 1.0
X-Received: by 10.180.13.175 with SMTP id i15mr7005391wic.30.1435421356497;
	Sat, 27 Jun 2015 09:09:16 -0700 (PDT)
Received: by 10.27.10.1 with HTTP; Sat, 27 Jun 2015 09:09:16 -0700 (PDT)
In-Reply-To: <CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
	<CALqxMTHjszPcf=S20kquF=5y3zfYb+foP6tL1okOT2jhdrW08A@mail.gmail.com>
Date: Sat, 27 Jun 2015 12:09:16 -0400
Message-ID: <CALgxB7tdFsQXzGRje=suC7Yaym_Whhtn2qrb3ykx2ZOBwwbE7w@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a11c22af00ea31705198214f8
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 16:09:18 -0000

--001a11c22af00ea31705198214f8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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.


On Sat, Jun 27, 2015 at 11:33 AM, Adam Back <adam@cypherspace.org> wrote:

> Michael Naber wrote:
> > Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,
> distributed, fastest, overall best solution possible to the global
> consensus problem.
>
> Everyone here is excited about the potential of Bitcoin and would
> aspirationally like it to reach its full potential as fast as
> possible.  But the block-size is not a free variable, half those
> parameters you listed are in conflict with each other.  We're trying
> to improve both decentralisation and throughput short-term while
> people work on algorithmic improvements mid-term.  If you are
> interested you can take a look through the proposals:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.h=
tml
>
> Note that probably 99% of Bitcoin transactions already happen
> off-chain in exchanges, tipping services, hosted wallets etc.  Maybe
> you're already using them, assuming you are a bitcoin user.
> They constitute an early stage layer 2, some of them even have on
> chain netting and scale faster than the block-chain.
>
> You can also read about layer 2, the lightning network paper and the
> duplex micropayment channel paper:
>
> http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
>
> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-mi=
cropayment-channels.pdf
>
> and read the development list and look at the code:
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
> https://github.com/ElementsProject/lightning
>
> Adam
>
>
> On 27 June 2015 at 16:39, Michael Naber <mickeybob@gmail.com> wrote:
> > Demand to participate in a low-fee global consensus network will likely
> > continue to rise. Technology already exists to meet that rising demand
> using
> > a blockchain with sufficient block size. Whether that blockchain is
> Bitcoin
> > Core with an increased block size, or whether it is a fork, market forc=
es
> > make it almost certain that demand will be met by a blockchain with
> adequate
> > capacity. These forces ensure that not only today=E2=80=99s block size =
will be
> > increased, but also that future increases will occur should the demand
> > arise.
> >
> > In order to survive, Bitcoin Core must remain the lowest-fee,
> > highest-capacity, most secure, distributed, fastest, overall best
> solution
> > possible to the global consensus problem. Attempting to artificially
> > constrain the block size below the limits of technology for any reason
> is a
> > conflict with this objective and a threat to the survival of Bitcoin
> Core.
> > At the same time, scheduling large future increases or permitting
> unlimited
> > dynamic scaling of the block size limit raises concerns over
> availability of
> > future computing resources. Instead, we should manually increase the
> block
> > size limit as demand occurs, except in the special case that increasing
> the
> > limit would cause an undue burden upon users wishing to validate the
> > integrity of the blockchain.
> >
> > Compromise: Can we agree that raising the block size to a static 8MB no=
w
> > with a plan to increase it further should demand necessitate except in
> the
> > special case above is a reasonable path forward?
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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

<div dir=3D"ltr"><div>The goal of Bitcoin Core is to meet the demand for gl=
obal consensus as effectively as possible. Please let&#39;s keep the conver=
sation on how to best meet that goal.<br></div><div><br></div><div>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 grea=
ter efficiency than Bitcoin does.<br></div><br></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Sat, Jun 27, 2015 at 11:33 AM, 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_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">Michael Naber wrote:<br>
&gt; Bitcoin Core must remain the lowest-fee, highest-capacity, most secure=
, distributed, fastest, overall best solution possible to the global consen=
sus problem.<br>
<br>
</span>Everyone here is excited about the potential of Bitcoin and would<br=
>
aspirationally like it to reach its full potential as fast as<br>
possible.=C2=A0 But the block-size is not a free variable, half those<br>
parameters you listed are in conflict with each other.=C2=A0 We&#39;re tryi=
ng<br>
to improve both decentralisation and throughput short-term while<br>
people work on algorithmic improvements mid-term.=C2=A0 If you are<br>
interested you can take a look through the proposals:<br>
<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June=
/008603.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2015-June/008603.html</a><br>
<br>
Note that probably 99% of Bitcoin transactions already happen<br>
off-chain in exchanges, tipping services, hosted wallets etc.=C2=A0 Maybe<b=
r>
you&#39;re already using them, assuming you are a bitcoin user.<br>
They constitute an early stage layer 2, some of them even have on<br>
chain netting and scale faster than the block-chain.<br>
<br>
You can also read about layer 2, the lightning network paper and the<br>
duplex micropayment channel paper:<br>
<br>
<a href=3D"http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf" =
rel=3D"noreferrer" target=3D"_blank">http://lightning.network/lightning-net=
work-paper-DRAFT-0.5.pdf</a><br>
<a href=3D"http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/=
duplex-micropayment-channels.pdf" rel=3D"noreferrer" target=3D"_blank">http=
://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropay=
ment-channels.pdf</a><br>
<br>
and read the development list and look at the code:<br>
<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/lightning-dev/" rel=
=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundation.org/pipermai=
l/lightning-dev/</a><br>
<a href=3D"https://github.com/ElementsProject/lightning" rel=3D"noreferrer"=
 target=3D"_blank">https://github.com/ElementsProject/lightning</a><br>
<br>
Adam<br>
<div><div class=3D"h5"><br>
<br>
On 27 June 2015 at 16:39, Michael Naber &lt;<a href=3D"mailto:mickeybob@gma=
il.com">mickeybob@gmail.com</a>&gt; wrote:<br>
&gt; Demand to participate in a low-fee global consensus network will likel=
y<br>
&gt; continue to rise. Technology already exists to meet that rising demand=
 using<br>
&gt; a blockchain with sufficient block size. Whether that blockchain is Bi=
tcoin<br>
&gt; Core with an increased block size, or whether it is a fork, market for=
ces<br>
&gt; make it almost certain that demand will be met by a blockchain with ad=
equate<br>
&gt; capacity. These forces ensure that not only today=E2=80=99s block size=
 will be<br>
&gt; increased, but also that future increases will occur should the demand=
<br>
&gt; arise.<br>
&gt;<br>
&gt; In order to survive, Bitcoin Core must remain the lowest-fee,<br>
&gt; highest-capacity, most secure, distributed, fastest, overall best solu=
tion<br>
&gt; possible to the global consensus problem. Attempting to artificially<b=
r>
&gt; constrain the block size below the limits of technology for any reason=
 is a<br>
&gt; conflict with this objective and a threat to the survival of Bitcoin C=
ore.<br>
&gt; At the same time, scheduling large future increases or permitting unli=
mited<br>
&gt; dynamic scaling of the block size limit raises concerns over availabil=
ity of<br>
&gt; future computing resources. Instead, we should manually increase the b=
lock<br>
&gt; size limit as demand occurs, except in the special case that increasin=
g the<br>
&gt; limit would cause an undue burden upon users wishing to validate the<b=
r>
&gt; integrity of the blockchain.<br>
&gt;<br>
&gt; Compromise: Can we agree that raising the block size to a static 8MB n=
ow<br>
&gt; with a plan to increase it further should demand necessitate except in=
 the<br>
&gt; special case above is a reasonable path forward?<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--001a11c22af00ea31705198214f8--