<oembed><type>rich</type><version>1.0</version><author_name>npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r</author_name><author_url>https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-26&#xA;📝 Original message:Hello all,&#xA;&#xA;here I&#39;m going to try to address a part of the block size debate which has&#xA;been troubling me since the beginning: the reason why people seem to want&#xA;it.&#xA;&#xA;People say that larger blocks are necessary. In the long term, I agree - in&#xA;the sense that systems that do not evolve tend to be replaced by other&#xA;systems. This evolution can come in terms of layers on top of Bitcoin&#39;s&#xA;blockchain, in terms of the technology underlying various aspects of the&#xA;blockchain itself, and also in the scale that this technology supports.&#xA;&#xA;I do, however, fundamentally disagree that a fear for a change in economics&#xA;should be considered to necessitate larger blocks. If it is, and there is&#xA;consensus that we should adapt to it, then there is effectively no limit&#xA;going forward. This is similar to how Congress voting to increase the&#xA;copyright term retroactively from time to time is really no different from&#xA;having an infinite copyright term in the first place. This scares me.&#xA;&#xA;Here is how Gavin summarizes the future without increasing block sizes in&#xA;PR 6341:&#xA;&#xA;&gt; 1. Transaction confirmation times for transactions with a given fee will&#xA;rise; very-low-fee transactions will fail to get confirmed at all.&#xA;&gt; 2. Average transaction fee paid will rise&#xA;&gt; 3. People or applications unwilling or unable to pay the rising fees will&#xA;stop submitting transactions&#xA;&gt; 4. People and businesses will shelve plans to use Bitcoin, stunting&#xA;growth and adoption&#xA;&#xA;Is it fair to summarize this as &#34;Some use cases won&#39;t fit any more, people&#xA;will decide to no longer use the blockchain for these purposes, and the&#xA;fees will adapt.&#34;?&#xA;&#xA;I think that is already happening, and will happen at any scale. I believe&#xA;demand for payments in general is nearly infinite, and only a small portion&#xA;of it will eventually fit on a block chain (independent of whether its size&#xA;is limited by consensus rules or economic or technological means).&#xA;Furthermore, systems that compete with Bitcoin in this space already offer&#xA;orders of magnitude more capacity than we can reasonably achieve with any&#xA;blockchain technology at this point.&#xA;&#xA;I don&#39;t know what subset of use cases Bitcoin will cater to in the long&#xA;term. They have already changed - you see way less betting transactions&#xA;these days than a few years ago for example - and they will keep changing,&#xA;independent of what effective block sizes we end up with. I don&#39;t think we&#xA;should be afraid of this change or try to stop it.&#xA;&#xA;If you look at graphs of block sizes over time (for example,&#xA;http://rusty.ozlabs.org/?p=498), it seems to me that there is very little&#xA;&#34;organic&#34; growth, and a lot of sudden changes (which could correspond to&#xA;changing defaults in miner software, introduction of popular&#xA;sites/services, changes in the economy). I think these can be seen as the&#xA;economy changing to full up the available space, and I believe these will&#xA;keep happening at any size effectively available.&#xA;&#xA;None of this is a reason why the size can&#39;t increase. However, in my&#xA;opinion, we should do it because we believe it increases utility and&#xA;understand the risks; not because we&#39;re afraid of what might happen if we&#xA;don&#39;t hurry up. And from that point of view, it seems silly to make a huge&#xA;increase at once...&#xA;&#xA;-- &#xA;Pieter&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/69d0ee83/attachment.html&gt;</html></oembed>