public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Wed, 16 Dec 2015 18:06:08 -0800	[thread overview]
Message-ID: <CADL_X_eWNuMJn_UBm3YYg_HjHmyDj3J85xp02L-0N-x6bmPZLA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBimfFVea4Sorgx=DaMPVs1k1DrmTA2ZFdLFtxrqKm23-w@mail.gmail.com>

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

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1:   Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3:  If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>

Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.

I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.

A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.


> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  reply	other threads:[~2015-12-17  2:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 14:53 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08   ` Jeff Garzik
2015-12-16 21:11     ` Pieter Wuille
2015-12-17  2:06       ` Jameson Lopp [this message]
2015-12-17 16:58       ` Tier Nolan
2015-12-17 19:44         ` Peter Todd
2015-12-18  5:23           ` Jorge Timón
2015-12-18  9:44           ` Tier Nolan
2015-12-16 21:24     ` Jorge Timón
2015-12-16 21:36       ` Jeff Garzik
2015-12-18  5:11   ` Jeff Garzik
2015-12-18  7:56     ` Pieter Wuille
2015-12-18 10:13       ` sickpig
2015-12-18 15:48         ` Pieter Wuille
2015-12-19 19:04           ` Dave Scotese
     [not found]           ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44             ` Pieter Wuille
2015-12-26 17:20               ` Jorge Timón
2015-12-26 22:55               ` Jonathan Toomim
2015-12-26 23:01                 ` Pieter Wuille
2015-12-26 23:07                   ` Jonathan Toomim
2015-12-26 23:16                     ` Pieter Wuille
2015-12-27  0:03                       ` Jonathan Toomim
2015-12-26 23:15                   ` Justus Ranvier
2015-12-27  0:13                     ` Bryan Bishop
2015-12-27  0:33                       ` Justus Ranvier
2015-12-18 13:56       ` Jeff Garzik
2015-12-23  6:26   ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27   ` Jeff Garzik
2015-12-17  6:12     ` Dave Scotese

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=CADL_X_eWNuMJn_UBm3YYg_HjHmyDj3J85xp02L-0N-x6bmPZLA@mail.gmail.com \
    --to=jameson.lopp@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    /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