public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Fri, 28 Aug 2015 17:29:23 -0700	[thread overview]
Message-ID: <CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>

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

Ah, then my mistake. It seemed so similar to an idea that was proposed
before on this mailing list:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html

that my mind just filled in the gaps. I concur -- having miners -- or any
group -- vote on block size is not an intrinsically good thing. The the
original proposal due to Greg Maxwell et al was not a mechanism for
"voting" but rather a feedback control that made the maximum block size
that which generated the most fees.

On Fri, Aug 28, 2015 at 5:00 PM, Jorge Timón <jtimon@jtimon.cc> wrote:

> On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > It is in their individual interests when the larger block that is allowed
> > for them grants them more fees.
>
> I realize now that this is not what Greg Maxwell proposed (aka
> flexcap): this is just miner's voting on block size but paying with
> higher difficulty when they vote for bigger blocks.
> As I said several times in other places, miners should not decide on
> the consensus rule to limit mining centralization.
> People keep talking about miners voting on the block size or
> "softforking the size down if we went too far". But what if the
> hashing majority is perfectly fine with the mining centralization at
> that point in time?
> Then a softfork won't be useful and we're talking about an "anti-miner
> fork" (see
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
> and
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
> ).
>
> I believe miner's voting on the rule to limit mining centralization is
> a terrible idea.
> It sounds as bad as letting pharma companies write the regulations on
> new drugs safety, letting big food chains deciding on minimum food
> controls or car manufacturers deciding on indirect taxes for fuel.
> That's why I dislike both this proposal and BIP100.
>

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

  reply	other threads:[~2015-08-29  0:29 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 [this message]
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='CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com' \
    --to=mark@friedenbach.org \
    --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