[bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

Sergio Demian Lerner sergio.d.lerner at gmail.com
Fri Aug 7 21:37:01 UTC 2015

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

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


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

> 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/7ed74a86/attachment-0001.html>

More information about the bitcoin-dev mailing list