<oembed><type>rich</type><version>1.0</version><author_name>npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4</author_name><author_url>https://nostr.ae/npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-08-11&#xA;📝 Original message:I&#39;m not sure whether removing the limit at the protocol-level would lead to&#xA;government by miners who might reject blocks which were too big, but I&#xA;probably wouldn&#39;t want to take that risk. I think we should probably keep a&#xA;block size limit in the protocol, but that we should increase it to be as&#xA;high as &#34;technology can provide.&#34; Toward that: I don&#39;t necessarily think&#xA;that node-count in and of itself should be the metric for evaluating what&#xA;technology can provide, as much as the goal that the chain be inexpensive&#xA;to validate given the capabilities of present technology -- so if I can&#xA;lease a server in a datacenter which can validate the chain and my total&#xA;cost to do that is just a few dollars, then we&#39;re probably ok.&#xA;&#xA;Of course there&#39;s also the issue that we maintain enough geographic /&#xA;political distribution to keep the network reliable, but I think we&#39;re far&#xA;from being in danger on the reliability front. So maybe my criteria that&#xA;the chain be validated at low cost is the wrong focus, but if it is than&#xA;what&#39;s the appropriate criteria for deciding whether it&#39;s safe by standards&#xA;of &#34;today&#39;s technology&#34; to raise the limit at the protocol level?&#xA;&#xA;On Tue, Aug 11, 2015 at 2:53 PM, Jorge Timón &lt;jtimon at jtimon.cc&gt; wrote:&#xA;&#xA;&gt;&#xA;&gt; On Aug 11, 2015 9:37 PM, &#34;Michael Naber&#34; &lt;mickeybob at gmail.com&gt; wrote:&#xA;&gt;&#xA;&gt; &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;&gt; You didn&#39;t answer the 2 questions...&#xA;&gt; Anyway, if we don&#39;t care about centralization at all, we can just remove&#xA;&gt; the limit: that&#39;s what &#34;technology can provide&#34;.&#xA;&gt; Maybe in that case it is developers who move to a decentralized&#xA;&gt; competitor...&#xA;&gt;&#xA;&gt; &gt; On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón &lt;jtimon at jtimon.cc&gt; wrote:&#xA;&gt; &gt;&gt;&#xA;&gt; &gt;&gt;&#xA;&gt; &gt;&gt; On Aug 11, 2015 8:46 PM, &#34;Michael Naber&#34; &lt;mickeybob at gmail.com&gt; wrote:&#xA;&gt; &gt;&gt; &gt;&#xA;&gt; &gt;&gt; &gt; Hi Jorge: Many people would like to participate in a global consensus&#xA;&gt; network -- which is a network where all the participating nodes are aware&#xA;&gt; of and agree upon every transaction. Constraining Bitcoin capacity below&#xA;&gt; the limits of technology will only push users seeking to participate in a&#xA;&gt; global consensus network to other solutions which have adequate capacity,&#xA;&gt; such as BitcoinXT or others. Note that lightning / hub and spoke do not&#xA;&gt; meet requirements for users wishing to participate in global consensus,&#xA;&gt; because they are not global consensus networks, since all participating&#xA;&gt; nodes are not aware of all transactions.&#xA;&gt; &gt;&gt;&#xA;&gt; &gt;&gt; Even if you are right, first fees will raise and that will be what&#xA;&gt; pushes people to other altcoins, no?&#xA;&gt; &gt;&gt; Can we agree that the first step in any potentially bad situation is&#xA;&gt; hitting the limit and then fees rising as a consequence?&#xA;&gt; &gt;&#xA;&gt; &gt;&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/c9fb0045/attachment.html&gt;</html></oembed>