public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Natanael <natanael.l@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Sat, 29 Aug 2015 21:13:12 +0200	[thread overview]
Message-ID: <CAAt2M19uCDHgMU8eFVhxuHka7aZ__9VoYtpHEp9qY5APC132Kw@mail.gmail.com> (raw)
In-Reply-To: <CABr1YTe+sCAioRMqsAjUC-1v+bfsz24=jjDKaatP=Gbm9sDf8g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

My current idea:

* There's a scheduled hardcap that goes up over time.

* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes
counted from block A to block B = block A+X, the change is enacted at block
C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a
reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No
suggestion on vote result calculation mechanism.)

* Casting votes are free.

* The mean (average) blocksize over the last time period X is calculated
for every block, or at the end of every fixed-length period (depending on
what scheduling is used for votes).

* Creating blocks larger than the mean but below the votecap raises the
difficulty target for the miner (and slightly raises the mean for future
blocks).

* The degree of difficulty raise depends on where between the mean and
votecap that the size of the given block is (and it follows that lots of
votes for large raise reduces per-extra-Kb penalty, allowing for cheaper
peak load adjustment if a large miner majority agrees). The degree of
increase may be either linear or logarithmic, I've got no suggestion
currently on any particular metric.
(Some might think this is an easy way for miners to collude to make large
blocks cheaper. If so, you could commit to only pay fee to miners that
don't vote for a block size above the size you accept, as a
counter-incentive.)

* Question: When the votecap is lowered, should the calculated mean be
forced down to follow (forcing a penalty for making blocks close to the
votecap straight after the change)? If so, how? Or should it be allowed to
fall naturally as new blocks with size below the votecap are created?

This is how miners would pay for actually creating larger blocks, and
leaves us with three methods of keeping the size in check (hardcap, votecap
and softcap). The softcap mechanism is then our third check to use if
deemed necessary (orphaning valid blocks if considered problematically
large). This third option do not need coordination with miners, they just
need to be aware which block size is accepted by the community.

I can't think of any sensible non-miner mechanism of deciding max block
size outside of using a community coordinated softcap, anything else will
not work reliably. Too hard to measure objectively and judge fairly.

The community would thus agree on a hardcap schedule in advance, and have
the option to threaten orphaning blocks via softfork later on if
circumstances would change and the votecap is too large.

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]

  reply	other threads:[~2015-08-29 19:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak
2015-08-21 23:17 ` Paul Sztorc
2015-08-22  0:06 ` Ahmed Zsales
2015-08-28 20:28   ` Btc Drak
2015-08-28 21:15     ` Matt Whitlock
2015-08-28 22:24       ` Gavin
2015-08-28 23:35         ` Chris Pacia
2015-08-28 23:38           ` Mark Friedenbach
2015-08-28 23:42             ` Matt Whitlock
2015-08-28 23:42             ` Chris Pacia
2015-08-29  0:00             ` Jorge Timón
2015-08-29  0:29               ` Mark Friedenbach
2015-08-29 10:15                 ` Btc Drak
2015-08-29 17:51                   ` Eric Lombrozo
2015-08-29 19:13                     ` Natanael [this message]
2015-08-29 19:03                   ` jl2012
2015-08-29 20:41                   ` Jorge Timón
2015-08-30 17:13                     ` jl2012
2015-08-30 18:56                       ` Jorge Timón
2015-08-31 18:50                         ` jl2012
2015-08-28 23:46           ` Btc Drak
2015-08-29  9:15             ` Elliot Olds
2015-08-28 23:38         ` Btc Drak
2015-08-28 23:36       ` Btc Drak
2015-08-28 23:44         ` Jorge Timón
2015-08-29  9:38     ` jl2012

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=CAAt2M19uCDHgMU8eFVhxuHka7aZ__9VoYtpHEp9qY5APC132Kw@mail.gmail.com \
    --to=natanael.l@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    /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