<div dir="ltr">On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <span dir="ltr">&lt;<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br>
&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; 2) If block size stays at 1M, the Bitcoin Core developer team should sign a<br>
&gt; collective note stating their desire to transition to a new economic policy,<br>
&gt; that of &quot;healthy fee market&quot; and strongly urge users to examine their fee<br>
&gt; policies, wallet software, transaction volumes and other possible User<br>
&gt; impacting outcomes.<br>
<br>
</span>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></blockquote><div><br></div><div>Diverging from the satoshi block size change plan[1] and current economics would seem to require a high level of months-ahead communication to users.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
all. Yes, old full nodes after a soft fork are not able to fully<br>
validate the rules new miners enforce anymore, but they do still<br>
verify the rules that their operators opted to enforce. Furthermore,<br>
they can&#39;t be prevented. For that reason, I&#39;ve proposed, and am<br>
working hard, on an approach that includes Segregated Witness as a<br>
first step. It shows the ecosystem that something is being done, it<br>
kicks the can down the road, it solves/issues half a dozen other<br>
issues at the same time, and it does not require the degree of<br>
certainty needed for a hardfork.<br></blockquote><div><br></div><div></div></div></div><div class="gmail_extra">Segregated Witness does not kick the can, it solves none of the problems #1, #3 - #8 explicitly defined and listed in email #1.</div><div class="gmail_extra"><br></div><div class="gmail_extra">1)  A plan of &quot;SW + no hard fork&quot; is gambling with ECE risk, gambling there will be no Fee Event, because the core block size is still heavily contended -- 100% contended at time out SW rollout.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) We are only 100% certain that bitcoin works in the blocks-not-full-on-avg state, where there is a healthy buffer between the hard limit and the average block size.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There is remains major ECE risk due to the core block size freeze, possibly pushing the system into a new, untried economic state and causing major market and actor disruption.  Users of the Service can still drift randomly and unpredictably into a Fee Event.</div><div class="gmail_extra"><br></div><div class="gmail_extra">SW mitigates this</div><div class="gmail_extra">- only after several months</div><div class="gmail_extra">- only assuming robust adoption rates by up-layer ecosystem software, and </div><div class="gmail_extra">- only assuming transaction volume growth is flat or sub-linear</div><div class="gmail_extra"><br></div><div class="gmail_extra">Those conditions <i style="font-weight:bold">must</i> go as planned to fulfill &quot;SW kicked the can&quot; -- a lot of if&#39;s.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As stated, SW is orthogonal to the drift-into-uncharted-waters problem outlined in email #1, which a short term bump does address.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>