<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <<a href="mailto:jgarzik@gmail.com">jgarzik@gmail.com</a>> wrote:<br>
>> You present this as if the Bitcoin Core development team is in charge<br>
>> of deciding the network consensus rules, and is responsible for making<br>
>> changes to it in order to satisfy economic demand. If that is the<br>
>> case, Bitcoin has failed, in my opinion.<br>
><br>
><br>
> This circles back to Problem #1: Avoidance of a choice is a still a choice<br>
> - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic<br>
> Change Event risk.<br>
<br>
</span>We are not avoiding a choice. We don't have the authority to make a choice.<br>
<span class=""><br>
> And #3: If the likely predicted course is that Bitcoin Core will not accept<br>
> a protocol change changing MAX_BLOCK_SIZE via hard fork in the short term,<br>
> the core dev team should communicate that position clearly to users and<br>
> media.<br>
<br>
</span>I indeed think we can communicate much better that deciding consensus<br>
rules is not within our power.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div>