public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ross Nicoll <jrn@jrn.me.uk>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Date: Tue, 21 Jul 2015 23:05:14 +0100	[thread overview]
Message-ID: <55AEC21A.3090302@jrn.me.uk> (raw)
In-Reply-To: <CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>

Not so much that the implementation is difficult, as it requires context 
to validate a block size, rather than being able to validate it without 
requiring the preceeding blocks. Yes, time on different machines may 
vary, but block time is safe to use for this, because it's a 
straight-forward test of "if block time is acceptable and block time is 
after <date> then maximum block size allowed is n MB otherwise m MB".

Ross

On 21/07/2015 10:26, Jorge Timón wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will differ in different computers and places when we have a
> universal tick with every block?
>
> Btw, BIP16 and BIP34 could be changed to height-based activation
> already. BIP16 simply should have used height instead of time from the
> beginning.
>
> On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Further to that - please disregard what I said about using block height. Had
>> failed to realise that in using contextual information (block height) it
>> complicates block validation (i.e. it would be impossible to tell if a block
>> is too big, without having all previous blocks first). Block time is in fact
>> the better option.
>>
>> Ross
>>
>>
>> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
>>
>> I'd back this if we can't find a permanent solution - 2MB gives us a lot
>> more wiggle room in the interim at least; one of my concerns with block size
>> is 3 transactions per second is absolutely tiny, and we need space for the
>> network to search for an equilibrium between volume and pricing without risk
>> of an adoption spike rendering it essentially unusable.
>>
>> I'd favour switching over by block height rather than time, and I'd suggest
>> that given virtually every wallet/node out there will require testing (even
>> if many do not currently enforce a limit and therefore do not need
>> changing), 6 months should be considered a minimum target. I'd open with a
>> suggestion of block 390k as a target.
>>
>> Ross
>>
>> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>>
>> Opening a mailing list thread on this BIP:
>>
>> BIP PR: https://github.com/bitcoin/bips/pull/173
>> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>>
>> The general intent of this BIP is as a minimum viable alternative plan to my
>> preferred proposal (BIP 100).
>>
>> If agreement is not reached on a more comprehensive solution, then this
>> solution is at least available and a known quantity.  A good backup plan.
>>
>> Benefits:  conservative increase.  proves network can upgrade.  permits some
>> added growth, while the community & market gathers data on how an increased
>> block size impacts privacy, security, centralization, transaction throughput
>> and other metrics.  2MB seems to be a Least Common Denominator on an
>> increase.
>>
>> Costs:  requires a hard fork.  requires another hard fork down the road.
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>



  parent reply	other threads:[~2015-07-21 22:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14   ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06   ` Chris Wardell
2015-07-17 19:13     ` Ross Nicoll
2015-07-19 22:51   ` Ross Nicoll
2015-07-21  9:26     ` Jorge Timón
2015-07-21 13:04       ` Peter Todd
2015-07-21 13:58         ` Peter Todd
2015-07-22 15:51           ` Tom Harding
2015-07-22 17:02           ` Sriram Karra
2015-07-22 17:40             ` Sriram Karra
2015-07-22 17:43           ` Jeff Garzik
2015-07-22 22:30             ` Peter Todd
2015-07-23  5:39               ` jl2012
2015-07-22 17:00         ` jl2012
2015-07-21 22:05       ` Ross Nicoll [this message]
2015-07-23 11:24         ` Jorge Timón
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13   ` Angel Leon
2015-07-17 22:25   ` Tier Nolan
2015-07-18  9:22     ` Jorge Timón
2015-07-18  9:24       ` Jorge Timón
2015-07-24  8:52   ` Thomas Zander
2015-07-24  9:43     ` Slurms MacKenzie
2015-07-18  4:32 ` Venzen Khaosan
2015-07-17 22:40 Raystonn

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=55AEC21A.3090302@jrn.me.uk \
    --to=jrn@jrn.me.uk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /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