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 --]
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/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