<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In the interest of promoting some constructive discussion on this, let me start by making a few proposals to correct the listed issues.<div class=""><br class=""></div><div class="">Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance.</div><div class=""><br class=""><div class=""><br class=""></div><div class="">——</div><div class=""><br class=""></div><div class="">1) A fee market never really got created, we don’t really know how transaction fees would &nbsp;work in practice.</div><div class=""><br class=""></div><div class="">The only way to see how fees would work in practice is to have scarcity. If the network is still not sufficiently mature to be able to handle actual resource limits securely, the safest way to do this is to artificially impose limits. Some economists might bicker about the problems with production quotas and what not…but how else are we to solve the real, non-trivial engineering problems without risking system collapse? The eventual goal would be to remove these artificial limits once we’re confident that the economic incentives are properly aligned to maintain security. We’re still quite far from this goal, though, and it would be irresponsible, IMHO, to insist on letting the system hit its real limits.</div><div class=""><br class=""></div><div class=""><br class="">2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated…validation cost is externalized to the entire network.</div><div class="">3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!</div><div class=""><br class=""></div><div class="">Issues (2) and (3) are inextricably related so I’ll cover both together.</div><div class=""><br class=""></div><div class="">The obvious problem here is that as long as the cost of checking validators is the same as the cost of validating itself, there’s really little we can do to properly have any sort of division of labor. Requiring, at the very least, random checks might be a start. Perhaps some clever use of SNARKs might eventually be secure and practical.</div><div class=""><br class=""></div><div class="">It might also be possible to directly pay validators for satisfying random checks or providing SNARKs. If only we could trustlessly and securely outsource this work we’d make tremendous progress.</div><div class=""><br class=""></div><div class="">Of all the issues I’ve listed, these are perhaps the ones for which practical solutions seem most tentative at present.<br class=""><br class=""><br class="">4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.</div><div class=""><br class=""></div><div class="">The first part of the solution to this issue is the use of better data structures. Satoshi’s SPV can prove that transactions are included in blocks…and that outputs are spent. But it has no mechanism for proving that a given transaction is *not* included in any block…or that some particular output remains unspent. The structures to which we’re committing extremely inefficient for querying some of the most important things required for validation…i.e. whether an output exists and whether it is spent.</div><div class=""><br class=""></div><div class="">The second part is shifting the responsibility for constructing proofs to the parties who already have the greatest incentives to store the necessary data to construct these proofs to allow efficient prunability. Outsourceability of proofs would also be highly desirable.</div><div class=""><br class=""></div><div class="">——</div><div class=""><br class=""></div><div class="">If we want to be able to raise the block size limit…or perhaps get rid of it altogether, I would suggest we start by addressing these specific issues and work to find practical solutions. Since raising the block size limit is already a hard forking consensus rule change, at least the need for hard forks isn’t what’s stopping us.</div><div class=""><br class=""></div><div class="">- Eric</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 28, 2015, at 5:55 PM, Eric Lombrozo &lt;<a href="mailto:elombrozo@gmail.com" class="">elombrozo@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion…and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with “But Satoshi said that…”<div class=""><div class=""><br class=""></div><div class="">What’s critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrong…and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).<br class=""><div class=""><br class=""></div><div class="">- Eric</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 28, 2015, at 5:46 PM, Mark Friedenbach &lt;<a href="mailto:mark@friedenbach.org" class="">mark@friedenbach.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <span dir="ltr" class="">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
&gt; Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…<br class="">
&gt;<br class="">
<br class="">
</span>The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.<br class="">
<br class="">
<br class="">
jp<br class="">
<br class="">
_______________________________________________<br class="">
bitcoin-dev mailing list<br class="">
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank" class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div></body></html>