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'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 "minute= s" 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"><<a href=3D= "mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>>= ;</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"><<a h= ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc= oin-dev@lists.linuxfoundation.org</a>></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: "SPV" mining and the relay network has sho= wn that block propagation is not an issue for such as small change. Mining = centralization won'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'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--