<div dir="ltr">I don't have strong opinion @ block size topic.<div><br></div><div>But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (<a href="https://bitcointalk.org/index.php?topic=181734.0">https://bitcointalk.org/index.php?topic=181734.0</a>) or its alternative. All developers of lightweight (blockchain-less) clients will adore you!</div><div><br></div><div>slush</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <span dir="ltr"><<a href="mailto:bitcoin-list@bluematt.me" target="_blank">bitcoin-list@bluematt.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Recently there has been a flurry of posts by Gavin at<br>
<a href="http://gavinandresen.svbtle.com/" target="_blank">http://gavinandresen.svbtle.com/</a> which advocate strongly for increasing<br>
the maximum block size. However, there hasnt been any discussion on this<br>
mailing list in several years as far as I can tell.<br>
<br>
Block size is a question to which there is no answer, but which<br>
certainly has a LOT of technical tradeoffs to consider. I know a lot of<br>
people here have varying levels of strong or very strong opinions about<br>
this, and the fact that it is not being discussed in a technical<br>
community publicly anywhere is rather disappointing.<br>
<br>
So, at the risk of starting a flamewar, I'll provide a little bait to<br>
get some responses and hope the discussion opens up into an honest<br>
comparison of the tradeoffs here. Certainly a consensus in this kind of<br>
technical community should be a basic requirement for any serious<br>
commitment to blocksize increase.<br>
<br>
Personally, I'm rather strongly against any commitment to a block size<br>
increase in the near future. Long-term incentive compatibility requires<br>
that there be some fee pressure, and that blocks be relatively<br>
consistently full or very nearly full. What we see today are<br>
transactions enjoying next-block confirmations with nearly zero pressure<br>
to include any fee at all (though many do because it makes wallet code<br>
simpler).<br>
<br>
This allows the well-funded Bitcoin ecosystem to continue building<br>
systems which rely on transactions moving quickly into blocks while<br>
pretending these systems scale. Thus, instead of working on technologies<br>
which bring Bitcoin's trustlessness to systems which scale beyond a<br>
blockchain's necessarily slow and (compared to updating numbers in a<br>
database) expensive settlement, the ecosystem as a whole continues to<br>
focus on building centralized platforms and advocate for changes to<br>
Bitcoin which allow them to maintain the status quo[1].<br>
<br>
Matt<br>
<br>
[1] <a href="https://twitter.com/coinbase/status/595741967759335426" target="_blank">https://twitter.com/coinbase/status/595741967759335426</a><br>
<br>
------------------------------------------------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div><br></div>