From: Elliot Olds <elliot.olds@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
Date: Sat, 29 Aug 2015 02:15:16 -0700 [thread overview]
Message-ID: <CA+BnGuEidsn9=f1oUoN8iUL9g9Zu1zigwjOj8BvazaSxMFwUGA@mail.gmail.com> (raw)
In-Reply-To: <CADJgMzv+JPr-JeYqZGnbFMn16iTfcCmj+JAo7_tX5qPbOOqPeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear from recent events that miners are willing to collaborate
> together for the greater good of their industry. Miners have also
> publicly shown support for raising the blocksize collaboratively.
>
When have miners shown a willingness to make sacrifices for miners as a
whole when they've been in a "public good"[1] situation? Miners
collaborating to release statements to the public about which BIPs they
support is very different from miners incurring costs only to themselves in
order to help the entire group. They might do so, but it isn't clear.
I agree with Jorge and Mark that allowing miners to vote on the block size
is not ideal. Miners interests are somewhat aligned with those of the
broader community, but not perfectly aligned. The block size level that
maximizes miner revenue is not necessarily desirable overall. More miner
revenue is only good if the marginal extra security that it buys is worth
the extra cost. In addition to the cost of higher user fees, there's
another hidden cost. In Bitcoin's early stages trying to maximize revenue
too soon can slow growth and result in less revenue when it's more needed
(when block rewards are much lower).
[1] https://en.wikipedia.org/wiki/Public_good
[-- Attachment #2: Type: text/html, Size: 2092 bytes --]
next prev parent reply other threads:[~2015-08-29 9:15 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
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 [this message]
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='CA+BnGuEidsn9=f1oUoN8iUL9g9Zu1zigwjOj8BvazaSxMFwUGA@mail.gmail.com' \
--to=elliot.olds@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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