From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
To: Mark Friedenbach <mark@friedenbach.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...
Date: Fri, 7 Aug 2015 18:37:01 -0300 [thread overview]
Message-ID: <CAKzdR-qpJzWoUVNUuhPh5sQQc2w-JZP9BqX4hRZG4c8_xujxQA@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-sCULNw=C75iot=6q4Yb16VvYh=F4DahS3ZEkEpGLvu3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]
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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 4096 bytes --]
next prev parent reply other threads:[~2015-08-07 21:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 21:18 [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows Sergio Demian Lerner
2015-08-07 21:27 ` Mark Friedenbach
2015-08-07 21:37 ` Sergio Demian Lerner [this message]
2015-08-07 22:46 ` Natanael
2015-08-07 23:01 ` Mark Friedenbach
2015-08-07 23:08 ` Sergio Demian Lerner
2015-08-07 23:17 ` Mark Friedenbach
2015-08-10 20:44 ` Michael Ruddy
2015-08-10 21:01 ` Pieter Wuille
2015-08-10 22:11 ` Sergio Demian Lerner
2015-08-10 22:31 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKzdR-qpJzWoUVNUuhPh5sQQc2w-JZP9BqX4hRZG4c8_xujxQA@mail.gmail.com \
--to=sergio.d.lerner@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=mark@friedenbach.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox