<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber <span dir="ltr">&lt;<a href="mailto:mickeybob@gmail.com" target="_blank">mickeybob@gmail.com</a>&gt;</span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bitcoin would be better money than current money even if it were a bit more expensive to transact, simply because of its other great characteristics (trustlessness, limited supply, etc). However... it is not better than something else sharing all those same characteristics but which is also less expensive. The best money will win, and if Bitcoin doesn&#39;t increase capacity then it won&#39;t remain the best.<br></div></blockquote><div><br></div></span><div>If it is less expensive, it is harder to be reliable (because it&#39;s easier for a sudden new use case to outbid the available space), which is less useful for a payment mechanism.<br></div></div></div></div></blockquote><div><br></div><div>It depends on which use case&#39;s reliability that you focus on. For any specific use case of Bitcoin, that use case will be more reliable with a larger block size (ignoring centralization effects). </div><div><br></div><div>The effect that I think you&#39;re talking about is that with lower fees, some use cases will exist that otherwise wouldn&#39;t have been possible with higher fees / smaller blocks, and these &quot;low fee only&quot; use cases will not be as reliable as the use cases you&#39;d see with high fees. But that puts you in a position or arguing that it&#39;s better that low fee use cases never exist at all, than existing at some high risk of being priced out eventually. Do we know with high confidence how high tx fees will be in the future? Should it be up to us discourage low fee use cases from being tried, because we think the risk that they&#39;ll later be priced out is too great? Shouldn&#39;t we let the people developing those use cases make that call? Maybe they don&#39;t mind the unreliability. Maybe it&#39;s worth it to them if their use case only lasts for a few months.</div><div><br></div><div>The important point to note is that the reliability of a use case is determined by the fees that people are willing to pay for that use case, not the fees that are actually paid. If big banks are willing to pay $1 / tx for some use case right now, but they only need 200 of these txns per block, then they might be paying only 5 cents / tx because no one is forcing them to pay more. The fact that they&#39;re only paying 5 cents / tx now doesn&#39;t make them any more vulnerable to new use cases than if they were paying $1 / tx now. If a new use case started bidding up tx fees, the banks would just increase their tx fees as high as they needed to (up to $1). </div><div><br></div><div>The reason that larger block sizes increase reliability for any given use case is that (a) You will never be priced out of blocks by a use case that is only willing to pay lower fees than you. This is true regardless of the block size. At worst they&#39;ll just force you to pay more in fees and lose some of your consumer surplus. (b) If a use case is willing to pay higher fees than you, then they&#39;re basically stepping ahead of you in line for block space and pushing you closer to the edge of not being included in blocks. The more space that exists between your use case and the marginal use cases that are just barely getting included in blocks, the less vulnerable you are to getting pushed out of blocks by new use cases. </div><div><br></div><div>If this is tricky to understand, here&#39;s an example that will make it clear:</div><div><br></div><div>Assume blocks can hold 2000 txns per MB. Before the new use case is discovered, demand looks like this: </div><div><br></div><div>500 txns will pay $1 fees</div><div>1000 txns will pay 50 cent fees</div><div>2000 txns will pay 5 cent fees</div><div>8000 txns will pay 2 cent fees</div><div>15,000 txns will pay 1 cent fees.</div><div>100,000 txns will pay 0.01 cent fees.</div><div><br></div><div>So at a block size of 1MB, fees are 5 cents and user surplus is $925 per block ($0.95 * 500 + 0.45 * 1000).</div><div>At a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per block ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).</div><div><br></div><div>Now a new use case comes into play and this is added to demand:</div><div><br></div><div>3000 txns will pay $5 / tx</div><div><br></div><div>That demand changes the scenarios like such:</div><div><br></div><div>At 1 MB fees jump to $5, user surplus is $0, and the $925 of value the previous users were getting is lost. All existing use cases are priced out, because there wasn&#39;t enough room in the blocks to accommodate them plus this new use case.</div><div><br></div><div>At 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0 in value would be lost (3000 users who were paying 1 cent for txns that they valued only at 1 cent would stop making txns). All use cases corresponding to the txns that were willing to pay at least 2 cents are still viable, because there was enough space in blocks to accommodate them plus the 3000 new high fee txns.</div><div><br></div><div>Let&#39;s say you&#39;re running the service that represents the 2000 txns willing to pay 5 cents each on the demand curve specified above. Let&#39;s say you&#39;re worried about being priced out of blocks. Which situation do you want to be in, the one with 1 MB blocks or 8 MB blocks? It&#39;s pretty clear that your best chance to remain viable is with larger blocks.</div><div><br></div><div> <br></div></div></div></div>