<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-08-11&#xA;📝 Original message:On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; Hitting the limit in and of itself is not necessarily a bad thing. The&#xA;&gt; question at hand is whether we should constrain that limit below what&#xA;&gt; technology is capable of delivering. I&#39;m arguing that not only we should&#xA;&gt; not, but that we could not even if we wanted to, since competition will&#xA;&gt; deliver capacity for global consensus whether it&#39;s in Bitcoin or in some&#xA;&gt; other product / fork.&#xA;&gt;&#xA;&#xA;The question is not what the technology can deliver. The question is what&#xA;price we&#39;re willing to pay for that. It is not a boolean &#34;at this size,&#xA;things break, and below it, they work&#34;. A small constant factor increase&#xA;will unlikely break anything in the short term, but it will come with&#xA;higher centralization pressure of various forms. There is discussion about&#xA;whether these centralization pressures are significant, but citing that&#xA;it&#39;s artificially constrained under the limit is IMHO a misrepresentation.&#xA;It is constrained to aim for a certain balance between utility and risk,&#xA;and neither extreme is interesting, while possibly still &#34;working&#34;.&#xA;&#xA;Consensus rules are what keeps the system together. You can&#39;t simply switch&#xA;to new rules on your own, because the rest of the system will end up&#xA;ignoring you. These rules are there for a reason. You and I may agree about&#xA;whether the 21M limit is necessary, and disagree about whether we need a&#xA;block size limit, but we should be extremely careful with change. My&#xA;position as Bitcoin Core developer is that we should merge consensus&#xA;changes only when they are uncontroversial. Even when you believe a more&#xA;invasive change is worth it, others may disagree, and the risk from&#xA;disagreement is likely larger than the effect of a small block size&#xA;increase by itself: the risk that suddenly every transaction can be spent&#xA;twice (once on each side of the fork), the very thing that the block chain&#xA;was designed to prevent.&#xA;&#xA;My personal opinion is that we should aim to do a block size increase for&#xA;the right reasons. I don&#39;t think fear of rising fees or unreliability&#xA;should be an issue: if fees are being paid, it means someone is willing to&#xA;pay them. If people are doing transactions despite being unreliable, there&#xA;must be a use for them. That may mean that some use cases don&#39;t fit&#xA;anymore, but that is already the case.&#xA;&#xA;-- &#xA;Pieter&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/851e0acb/attachment.html&gt;</html></oembed>