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