Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B53DD71 for ; 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 ; Fri, 7 Aug 2015 21:37:41 +0000 (UTC) Received: by obbop1 with SMTP id op1so88336141obb.2 for ; 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: References: From: Sergio Demian Lerner Date: Fri, 7 Aug 2015 18:37:01 -0300 Message-ID: To: Mark Friedenbach 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Mark,
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.

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>

On Fri= , Aug 7, 2015 at 6:27 PM, Mark Friedenbach <mark@friedenbach.org>= ; wrote:
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.

Doubling = the block size is safer than halving the block interval, for the same effec= t in aggregate transactions per second.

On Fri, Aug 7, 2015 = at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
What wou= ld 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 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>
So what would be best for Bitcoin?

<= /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.

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.=C2= =A0

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).

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?

Best regards,
=C2=A0Sergio.

(*) b requires increasing the transaction version numb= er, to support the old nLockTime rate.



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--047d7b33d3480130a0051cbf7231--