<oembed><type>rich</type><version>1.0</version><author_name>npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</author_name><author_url>https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-26&#xA;📝 Original message:It is not &#34;fear&#34; of fee pressure.&#xA;&#xA;1) Blocks are mostly not-full on average.&#xA;&#xA;2) Absent long blocks and stress tests, there is little fee pressure above&#xA;the anti-spam relay fee metric, because of #1.&#xA;&#xA;3) As such, inducing fee pressure is a delta, a change from years-long&#xA;bitcoin economic policy.  Each time we approach the soft limit, Bitcoin&#xA;Core increases the soft limit to prevent &#34;full&#34; blocks.  Mike Hearn et. al.&#xA;lobbies miners to upgrade.&#xA;&#xA;(note - this is not an endorsement of these actions - it is a neutral&#xA;observation)&#xA;&#xA;4) Inaction leads to consistent fee pressure as the months tick on and&#xA;system volume grows; thus, inaction leads to economic policy change.&#xA;&#xA;5) Economic policy change leads to market and software disruption.  The&#xA;market and software - notably wallets - is not prepared for this.&#xA;&#xA;6) If you want to change economic policy, that&#39;s fine.  But be honest and&#xA;admit you are arguing for a change, a delta from current market&#xA;expectations and behavior.&#xA;&#xA;7) It is critical to first deal with what _is_, not what you wish the world&#xA;to be.  You want a fee market to develop.  There is nothing wrong with that&#xA;desire.  It remains a delta from where we are today, and that is critically&#xA;relevant in a $3b+ market.&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille &lt;pieter.wuille at gmail.com&gt;&#xA;wrote:&#xA;&#xA;&gt; Hello all,&#xA;&gt;&#xA;&gt; here I&#39;m going to try to address a part of the block size debate which has&#xA;&gt; been troubling me since the beginning: the reason why people seem to want&#xA;&gt; it.&#xA;&gt;&#xA;&gt; People say that larger blocks are necessary. In the long term, I agree -&#xA;&gt; in the sense that systems that do not evolve tend to be replaced by other&#xA;&gt; systems. This evolution can come in terms of layers on top of Bitcoin&#39;s&#xA;&gt; blockchain, in terms of the technology underlying various aspects of the&#xA;&gt; blockchain itself, and also in the scale that this technology supports.&#xA;&gt;&#xA;&gt; I do, however, fundamentally disagree that a fear for a change in&#xA;&gt; economics should be considered to necessitate larger blocks. If it is, and&#xA;&gt; there is consensus that we should adapt to it, then there is effectively no&#xA;&gt; limit going forward. This is similar to how Congress voting to increase the&#xA;&gt; copyright term retroactively from time to time is really no different from&#xA;&gt; having an infinite copyright term in the first place. This scares me.&#xA;&gt;&#xA;&gt; Here is how Gavin summarizes the future without increasing block sizes in&#xA;&gt; PR 6341:&#xA;&gt;&#xA;&gt; &gt; 1. Transaction confirmation times for transactions with a given fee will&#xA;&gt; rise; very-low-fee transactions will fail to get confirmed at all.&#xA;&gt; &gt; 2. Average transaction fee paid will rise&#xA;&gt; &gt; 3. People or applications unwilling or unable to pay the rising fees&#xA;&gt; will stop submitting transactions&#xA;&gt; &gt; 4. People and businesses will shelve plans to use Bitcoin, stunting&#xA;&gt; growth and adoption&#xA;&gt;&#xA;&gt; Is it fair to summarize this as &#34;Some use cases won&#39;t fit any more, people&#xA;&gt; will decide to no longer use the blockchain for these purposes, and the&#xA;&gt; fees will adapt.&#34;?&#xA;&gt;&#xA;&gt; I think that is already happening, and will happen at any scale. I believe&#xA;&gt; demand for payments in general is nearly infinite, and only a small portion&#xA;&gt; of it will eventually fit on a block chain (independent of whether its size&#xA;&gt; is limited by consensus rules or economic or technological means).&#xA;&gt; Furthermore, systems that compete with Bitcoin in this space already offer&#xA;&gt; orders of magnitude more capacity than we can reasonably achieve with any&#xA;&gt; blockchain technology at this point.&#xA;&gt;&#xA;&gt; I don&#39;t know what subset of use cases Bitcoin will cater to in the long&#xA;&gt; term. They have already changed - you see way less betting transactions&#xA;&gt; these days than a few years ago for example - and they will keep changing,&#xA;&gt; independent of what effective block sizes we end up with. I don&#39;t think we&#xA;&gt; should be afraid of this change or try to stop it.&#xA;&gt;&#xA;&gt; If you look at graphs of block sizes over time (for example,&#xA;&gt; http://rusty.ozlabs.org/?p=498), it seems to me that there is very little&#xA;&gt; &#34;organic&#34; growth, and a lot of sudden changes (which could correspond to&#xA;&gt; changing defaults in miner software, introduction of popular&#xA;&gt; sites/services, changes in the economy). I think these can be seen as the&#xA;&gt; economy changing to full up the available space, and I believe these will&#xA;&gt; keep happening at any size effectively available.&#xA;&gt;&#xA;&gt; None of this is a reason why the size can&#39;t increase. However, in my&#xA;&gt; opinion, we should do it because we believe it increases utility and&#xA;&gt; understand the risks; not because we&#39;re afraid of what might happen if we&#xA;&gt; don&#39;t hurry up. And from that point of view, it seems silly to make a huge&#xA;&gt; increase at once...&#xA;&gt;&#xA;&gt; --&#xA;&gt; Pieter&#xA;&gt;&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/4d6992ee/attachment.html&gt;</html></oembed>