public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Whitlock <bip@mattwhitlock•name>
To: bitcoin-dev@lists•linuxfoundation.org,
	Mark Friedenbach <mark@friedenbach•org>,
	Chris Pacia <ctpacia@gmail•com>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Fri, 28 Aug 2015 19:42:03 -0400	[thread overview]
Message-ID: <12011991.1tUHVb58Dn@crushinator> (raw)
In-Reply-To: <CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>

But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.

Maybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period.


On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
> 
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> > When discussing this with Matt Whitlock earlier we basically concluded the
> > block size will never increase under this proposal do to a collective
> > action problem. If a miner votes for an increase and nobody else does, the
> > blocksize will not increase yet he will still have to pay the difficulty
> > penalty.
> >
> > It may be in everyone's collective interest to raise the block size but
> > not their individual interest.
> > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> With this proposal, how much would it cost a miner to include an 'extra'
> >> 500-byte transaction if the average block size is 900K and it costs the
> >> miner 20BTC in electricity/capital/etc to mine a block?
> >>
> >> If my understanding of the proposal is correct, it is:
> >>
> >> 500/900000 * 20 = 0.11111 BTC
> >>
> >> ... Or $2.50 at today's exchange rate.
> >>
> >> That seems excessive.
> >>
> >> --
> >> Gavin Andresen
> >>
> >>
> >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> >> bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >
> >> > This is the best proposal I've seen yet. Allow me to summarize:
> >> >
> >> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> >> their block-size votes.
> >> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> >> trying to predict future market needs versus future technological
> >> capacities.
> >> > • It avoids a large step discontinuity in the block-size limit by
> >> starting with a 1-MB limit.
> >> > • It throttles changes to ±10% every 2016 blocks.
> >> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> >> raise the block-size limit.
> >> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >> >
> >> > However, this proposal currently fails to answer a very important
> >> question:
> >> >
> >> > • What is the mechanism for activation of the new consensus rule? It is
> >> when a certain percentage of the blocks mined in a 2016-block retargeting
> >> period contain valid block-size votes?
> >> >
> >> >
> >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >> >
> >> >
> >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> >> Pull request: https://github.com/bitcoin/bips/pull/187
> >> > _______________________________________________
> >> > 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
> >
> >


  reply	other threads:[~2015-08-28 23:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21 22:22 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 [this message]
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
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=12011991.1tUHVb58Dn@crushinator \
    --to=bip@mattwhitlock$(echo .)name \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=ctpacia@gmail$(echo .)com \
    --cc=mark@friedenbach$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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