From: Matt Whitlock <bip@mattwhitlock•name>
To: Peter Todd <pete@petertodd•org>, bitcoin-dev@lists•linuxfoundation.org
Cc: greg@xiph•org
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Date: Tue, 25 Aug 2015 17:14:58 -0400 [thread overview]
Message-ID: <1555170.JCnkl2i9KN@crushinator> (raw)
In-Reply-To: <20150825203744.GB3464@muck>
On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
> On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
> > On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> > > What would you think of an approach like John Dillon's proposal to
> > > explicitly give the economic majority of coin holders a vote for the max
> > > blocksize? Miners could still vote BIP100 style for what max they were
> > > willing to use, limited in turn by the vote of the economic majority.
> >
> > What fraction of coin holders do you suppose will vote? And, of those, what fraction have the technical knowledge to make an informed vote? It would be like polling Toyota truck owners to see whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%. Ordinary users just aren't going to be able to vote meaningfully, and most won't respond to the poll at all.
>
> Note that you can make the % of voters required adapt dyanmically to voter
> interest. Also, your example is rather misleading, as car buyers *do*
> make those kinds of decisions though various market mechanisms.
Yes, car buyers do make those kinds of decisions through market mechanisms. An equivalent process for Bitcoin would be that the max block-size limit (and other fundamental economic parameters) would be determined via a process of forking off altcoins (such as Bitcoin XT will do) and allowing the market to decide which coin is most valuable. This is the "default" mechanism for change (because it's what naturally happens when there is a lack of internal consensus), but it's not the least painful mechanism.
My point still stands that — just as in democracy in general — the voters are really in no position to cast informed votes, nor should they be (cf. "rational ignorance" [1]). I do not oppose opening up the determination of the max block-size limit to a popular "check" via stakeholder vote — actually, I think this is an important check on miners' power — but I do argue that the vote is likely to have drastically little participation and very low-quality results.
[1] Rational Ignorance: «Ignorance about an issue is said to be "rational" when the cost of educating oneself about the issue sufficiently to make an informed decision can outweigh any potential benefit one could reasonably expect to gain from that decision, and so it would be irrational to waste time doing so.» <https://en.wikipedia.org/wiki/Rational_ignorance>
next prev parent reply other threads:[~2015-08-25 21:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 9:07 Upal Chakraborty
2015-08-25 9:19 ` Chun Wang
2015-08-25 20:16 ` Peter Todd
2015-08-25 20:26 ` Matt Whitlock
2015-08-25 20:37 ` Peter Todd
2015-08-25 21:14 ` Matt Whitlock [this message]
2015-08-25 21:28 ` Eric Voskuil
2015-08-25 21:18 ` Simon Liu
2015-08-25 21:44 ` Chun Wang
2015-08-26 0:29 ` Peter Todd
2015-08-26 6:28 ` Hector Chu
2015-08-26 12:19 ` Upal Chakraborty
2015-08-27 15:09 ` Upal Chakraborty
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=1555170.JCnkl2i9KN@crushinator \
--to=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
--cc=pete@petertodd$(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