path: root/68/4dbccb7542722f333968d55e7d51f5bba4d8a2

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BA8ECE91
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 17:52:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7B1710C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 17:52:06 +0000 (UTC)
Received: by igcse8 with SMTP id se8so42059130igc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 10:52:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=ekalFp0fADHcVH5ZYnhjI6gsLUndowcWdcjwPk/sR3w=;
	b=E/YAIl+1khA/XDw3+3vnHLfuHk/Ny5LRhIOxPWebNSslWT5gMl3CXCp1wQ3LNKkQqE
	1ommcKvmS9uV52/9okVnNgBt0wCsWaCC3ip9WW1AyKkjf5ySaWiLZrzSlkpSskhuMJuL
	VEZflno9njZFdoLl5Wa09gzc9uWB07ztjHx1Lld41FgZ9OcrmjHC0IBOBjtJT1YHXNww
	4dz8uhLJYBAfjGoQVnmRMIbwqe3T5+TRb8Kb3PheKb2ZxkZgjkQygHSex7Odj4PPZKdy
	IgEeAW0uRj/LGD0b9e1hpN66N0gNAF/5ONMrTk6CTqCvSFjXGm7pscMdY0dYkfu92fuB
	IeiQ==
X-Received: by 10.50.62.46 with SMTP id v14mr8204630igr.79.1440870726300; Sat,
	29 Aug 2015 10:52:06 -0700 (PDT)
MIME-Version: 1.0
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
	<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
	<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
	<2081355.cHxjDEpgpW@crushinator>
	<A30CC2E3-A769-445C-95A2-35B963EFC283@gmail.com>
	<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
	<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
	<CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>
	<CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com>
	<CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
In-Reply-To: <CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sat, 29 Aug 2015 17:51:56 +0000
Message-ID: <CABr1YTe+sCAioRMqsAjUC-1v+bfsz24=jjDKaatP=Gbm9sDf8g@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>, Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7bd77122cefb67051e76db8f
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
	(draft)
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, 29 Aug 2015 17:52:07 -0000

--047d7bd77122cefb67051e76db8f
Content-Type: text/plain; charset=UTF-8

In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
want to balance hashing and propagation time costs with revenue), and
validator nodes (who currrently lack any direct incentives), I think we're
talking about significant protocol complications with potential benefits
that are hard to model at best.

On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Ah, then my mistake. It seemed so similar to an idea that was proposed
> > before on this mailing list:
> >
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
> >
> > that my mind just filled in the gaps. I concur -- having miners -- or any
> > group -- vote on block size is not an intrinsically good thing. The the
> > original proposal due to Greg Maxwell et al was not a mechanism for
> "voting"
> > but rather a feedback control that made the maximum block size that which
> > generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters.  Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<p dir=3D"ltr">In principle I am sympathetic to dynamic block size proposal=
s...but in practice it seems we&#39;re barking up the wrong tree. Without m=
echanisms for incentivizing validators...and checks and balances between th=
e interests of regular users (who want to reduce fees and confirmation time=
), miners (who want to balance hashing and propagation time costs with reve=
nue), and validator nodes (who currrently lack any direct incentives), I th=
ink we&#39;re talking about significant protocol complications with potenti=
al benefits that are hard to model at best.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 29, 2015, 3:16 =
AM=C2=A0Btc Drak via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On Sat, Aug 29, 2015 at 1:29 AM, Mark =
Friedenbach via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Ah, then my mistake. It seemed so similar to an idea that was proposed=
<br>
&gt; before on this mailing list:<br>
&gt;<br>
&gt; <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015=
-May/008033.html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2015-May/008033.html</a><br>
&gt;<br>
&gt; that my mind just filled in the gaps. I concur -- having miners -- or =
any<br>
&gt; group -- vote on block size is not an intrinsically good thing. The th=
e<br>
&gt; original proposal due to Greg Maxwell et al was not a mechanism for &q=
uot;voting&quot;<br>
&gt; but rather a feedback control that made the maximum block size that wh=
ich<br>
&gt; generated the most fees.<br>
<br>
Mark and Jorge,<br>
<br>
I am very glad you have brought up this particular objection because<br>
it&#39;s something I thought about but was unclear if it was an opinion<br>
that would be shared by others. I chose to omit it from the proposal<br>
to see if it would come up during peer review.<br>
<br>
I feel that giving miners a blank cheque to increase blocksize, by any<br>
means, goes against a key design of bitcoin&#39;s security model. Full<br>
nodes keep miners honest by ensuring by validating their blocks. Under<br>
any voting-only scheme there is no way for full nodes to keep miners<br>
in cheque because miner have free reign to increase the blocksize.<br>
<br>
This problem can be solved by introducing a hard cap on blocksize. By<br>
introducing an upper limit miners now have the freedom to increase<br>
blocksize but only within defined parameters.=C2=A0 Remember my proposal<br=
>
allows blocksize to increase and decrease in such a way that miners<br>
must collectively agree if they want the size to increase.<br>
<br>
I believe the idea of a hard upper limit has become rather politicised<br>
but is essential to the security model of bitcoin.<br>
<br>
With respect to the flexicap idea where miners can create a larger<br>
block by paying extra difficulty, I believe that proposal has a<br>
critical flaw because, as Gavin pointed out, it makes it very<br>
expensive (and risky) to include a few extra transactions. I believe<br>
it suffers from tragedy of the commons because there is no incentive<br>
for the mining community to reach consensus. Each and every block is<br>
going to be a gamble, &quot;should we include a few extra transactions at<b=
r>
the risk of losing the block?&quot;. Under my proposal miners can<br>
collectively agree to change the blocksize. Let&#39;s say they want a 10%<b=
r>
increase, they can collude together to make that increase and once<br>
reached, it remains until they want to change it again. Yet, the upper<br>
hard limit keeps the ultimate control of the maximum block size<br>
squarely in the hands of full nodes.<br>
<br>
Whilst the exact number may be up for discussion, I would propose an<br>
initial upper limit of 8MB, so under my proposal the blocksize would<br>
be flexible between 1MB and 8MB.<br>
<br>
An alternative methodology to voting in the coinbase would be to<br>
change the vote to be the blocksize itself<br>
<br>
1. miners pay extra difficulty to create a larger block.<br>
2. every 2016 blocks the average or median of the last 2016 blocks is<br>
calculated and becomes the new maximum blocksize limit.<br>
<br>
This would retain incentive to collude to increase blocksize, as well<br>
as the property of costing to increase while being free to propose<br>
decrease.<br>
<br>
It would still require an upper blocksize limit in order for full<br>
nodes to retain control. Without an upper limit, any proposal is going<br>
to break the security model as full nodes give up some oversight<br>
control over miners.<br>
<br>
Another way of looking at these ideas is we&#39;re raising blocksize hard<b=
r>
limit (to 8MB or whatever is decided), but making a soft of &quot;softer&qu=
ot;<br>
or inner limit part of consensus. Such a concept is not really<br>
departing from the current idea of a soft limit except to make it<br>
consensus enforced. Obviously it&#39;s not identical, but I think you can<b=
r>
see the similarities.<br>
<br>
Does that make sense?<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</blockquote></div>

--047d7bd77122cefb67051e76db8f--