Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B53DD71
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 21:37:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com
	[209.85.214.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19ED2107
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Aug 2015 21:37:41 +0000 (UTC)
Received: by obbop1 with SMTP id op1so88336141obb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Aug 2015 14:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=gZGDoknXTTEW1qWNmeIgZ7ouM/Kx+RHLhTSkPiTQb/A=;
	b=ATlquBXJXhCejaeXUe42yq4EC+bAR9GmIEpfYTx1ACJ3kFHtva2K0Xt7M5C9ycVvej
	itqfd97Bdz5KR4EvomRDm8PbCPN/hWGRCoPDIsiEHg0tJIvIjzwRpEPtU0axBM7YsK83
	0a2n69OcqXMDTzxGSlWh1yOUrv1E/aU59GWODfzVnGSkNAR49GyU3KuM/5Fp1/EmS9Hv
	Fr39GQ+ndBMC78DDnOP9hm/+KjopWjiN/wMYOGmG9tH6W0AUPOBt0hivWPO4ALDK+P3R
	4dI3wvB9IKMsZfizOP/DruzouAUwZiUKsBukp1GwEeYOz5RclLEnWx8YgGm2KzpW8JHg
	G+pA==
X-Received: by 10.60.76.69 with SMTP id i5mr8692860oew.42.1438983460563; Fri,
	07 Aug 2015 14:37:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.116.207 with HTTP; Fri, 7 Aug 2015 14:37:01 -0700 (PDT)
In-Reply-To: <CAOG=w-sCULNw=C75iot=6q4Yb16VvYh=F4DahS3ZEkEpGLvu3w@mail.gmail.com>
References: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
	<CAOG=w-sCULNw=C75iot=6q4Yb16VvYh=F4DahS3ZEkEpGLvu3w@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 7 Aug 2015 18:37:01 -0300
Message-ID: <CAKzdR-qpJzWoUVNUuhPh5sQQc2w-JZP9BqX4hRZG4c8_xujxQA@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b33d3480130a0051cbf7231
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] If you had a single chance to double the
 transactions/second Bitcoin allows...
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: Fri, 07 Aug 2015 21:37:41 -0000

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

Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.

Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.

:)




On Fri, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Because halving the block interval comes with costs to SPV proofs (which
> double the number of headers) and mining centralization (doubles the
> selfish mining effect of latency) for the questionable benefit of a block
> expectation time that is still measured in minutes, not seconds.
>
> Doubling the block size is safer than halving the block interval, for the
> same effect in aggregate transactions per second.
>
> On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> What would you do?
>>
>> a. Double the block size
>> b. Reduce the block rate to a half (average 5 minute blocks)
>>
>> Suppose this is a one time hard fork. There no drastic technical problems
>> with any of them: "SPV" mining and the relay network has shown that block
>> propagation is not an issue for such as small change. Mining centralization
>> won't radically change for a 2x adjustment.
>>
>> So what would be best for Bitcoin?
>>
>> I suspect some (if not most of you) would choose b. Because reducing the
>> block interval saves us real time. Waiting 30 minutes for a 3-block
>> confirmation is... such a long time! Time that we value. Time that
>> sometimes we waste waiting. Time that makes a difference for us. Doubling
>> the block size does not change the user perception of Bitcoin in any way.
>>
>> Then why most discussions go around doubling the block size?
>>
>> Each change require less than 20 lines of code (*) in the reference code,
>> and minimum change in other wallets.
>>
>> Currently there is no idle mining hardware for hire, so the security of
>> six 10-minute block confirmation is equivalent to the security of six
>> 5-minute block confirmations, as described in Satoshi's paper (if there
>> were 51% spare mining hardware for hire, then obviously hiring that
>> hardware for 30 minutes would cost less than hiring it for 1 hour).
>>
>> Why we discuss a 2x block size increase and not a 1/2 block interval
>> reduction? Aren't we Bitcoin users after all?
>>
>> Best regards,
>>  Sergio.
>>
>> (*) b requires increasing the transaction version number, to support the
>> old nLockTime rate.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

<div dir=3D"ltr">Mark,<div>It took you 3 minutes to respond to my e-mail. A=
nd I responded to you 4 minutes later. If you had responded to me in 10 min=
utes, I would be of out the office and we wouldn&#39;t have this dialogue. =
So 5 minutes is a lot of time.</div><div><br></div><div>Obviously this is n=
ot a technical response to the technical issues you argue. But &quot;minute=
s&quot; is a time scale we humans use to measure time very often.</div><div=
><br></div><div>:)</div><div><br></div><div><br></div><div><div><br></div><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Bec=
ause halving the block interval comes with costs to SPV proofs (which doubl=
e the number of headers) and mining centralization (doubles the selfish min=
ing effect of latency) for the questionable benefit of a block expectation =
time that is still measured in minutes, not seconds.<br><br></div>Doubling =
the block size is safer than halving the block interval, for the same effec=
t in aggregate transactions per second.<br></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Aug 7, 2015 =
at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">What wou=
ld you do?<div><br></div><div>a. Double the block size</div><div>b. Reduce =
the block rate to a half (average 5 minute blocks)</div><div><br></div><div=
><div>Suppose this is a one time hard fork. There no drastic technical prob=
lems with any of them: &quot;SPV&quot; mining and the relay network has sho=
wn that block propagation is not an issue for such as small change. Mining =
centralization won&#39;t radically change for a 2x adjustment.=C2=A0</div><=
div><br></div><div>So what would be best for Bitcoin?</div></div><div><br><=
/div><div>I suspect some (if not most of you) would choose b. Because reduc=
ing the block interval saves us real time. Waiting 30 minutes for a 3-block=
 confirmation is... such a long time! Time that we value. Time that sometim=
es we waste waiting. Time that makes a difference for us. Doubling the bloc=
k size does not change the user perception of Bitcoin in any way.</div><div=
><br></div><div>Then why most discussions go around doubling the block size=
?<br></div><div><br></div><div><div>Each change require less than 20 lines =
of code (*) in the reference code, and minimum change in other wallets.=C2=
=A0</div><div><br></div><div>Currently there is no idle mining hardware for=
 hire, so the security of six 10-minute block confirmation is equivalent to=
 the security of six 5-minute block confirmations, as described in Satoshi&=
#39;s paper (if there were 51% spare mining hardware for hire, then obvious=
ly hiring that hardware for 30 minutes would cost less than hiring it for 1=
 hour).</div></div><div><br></div><div>Why we discuss a 2x block size incre=
ase and not a 1/2 block interval reduction? Aren&#39;t we Bitcoin users aft=
er all?</div><div><br></div><div>Best regards,</div><div>=C2=A0Sergio.</div=
><div><br></div><div>(*) b requires increasing the transaction version numb=
er, to support the old nLockTime rate.<br></div><div><br></div><div><br></d=
iv></div>
<br></div></div>_______________________________________________<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>
<br></blockquote></div><br></div>
</blockquote></div><br></div>

--047d7b33d3480130a0051cbf7231--