{"type":"rich","version":"1.0","author_name":"npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4","author_url":"https://nostr.ae/npub13rv3raner7hu6npy7vxxvdswdapae65pnw8jjs4c80wtp2nmg4xq9cy5l4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-11\n📝 Original message:I'm not sure whether removing the limit at the protocol-level would lead to\ngovernment by miners who might reject blocks which were too big, but I\nprobably wouldn't want to take that risk. I think we should probably keep a\nblock size limit in the protocol, but that we should increase it to be as\nhigh as \"technology can provide.\" Toward that: I don't necessarily think\nthat node-count in and of itself should be the metric for evaluating what\ntechnology can provide, as much as the goal that the chain be inexpensive\nto validate given the capabilities of present technology -- so if I can\nlease a server in a datacenter which can validate the chain and my total\ncost to do that is just a few dollars, then we're probably ok.\n\nOf course there's also the issue that we maintain enough geographic /\npolitical distribution to keep the network reliable, but I think we're far\nfrom being in danger on the reliability front. So maybe my criteria that\nthe chain be validated at low cost is the wrong focus, but if it is than\nwhat's the appropriate criteria for deciding whether it's safe by standards\nof \"today's technology\" to raise the limit at the protocol level?\n\nOn Tue, Aug 11, 2015 at 2:53 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\n\u003e\n\u003e On Aug 11, 2015 9:37 PM, \"Michael Naber\" \u003cmickeybob at gmail.com\u003e wrote:\n\u003e\n\u003e \u003e Hitting the limit in and of itself is not necessarily a bad thing. The\n\u003e question at hand is whether we should constrain that limit below what\n\u003e technology is capable of delivering. I'm arguing that not only we should\n\u003e not, but that we could not even if we wanted to, since competition will\n\u003e deliver capacity for global consensus whether it's in Bitcoin or in some\n\u003e other product / fork.\n\u003e\n\u003e You didn't answer the 2 questions...\n\u003e Anyway, if we don't care about centralization at all, we can just remove\n\u003e the limit: that's what \"technology can provide\".\n\u003e Maybe in that case it is developers who move to a decentralized\n\u003e competitor...\n\u003e\n\u003e \u003e On Tue, Aug 11, 2015 at 2:27 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On Aug 11, 2015 8:46 PM, \"Michael Naber\" \u003cmickeybob at gmail.com\u003e wrote:\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Hi Jorge: Many people would like to participate in a global consensus\n\u003e network -- which is a network where all the participating nodes are aware\n\u003e of and agree upon every transaction. Constraining Bitcoin capacity below\n\u003e the limits of technology will only push users seeking to participate in a\n\u003e global consensus network to other solutions which have adequate capacity,\n\u003e such as BitcoinXT or others. Note that lightning / hub and spoke do not\n\u003e meet requirements for users wishing to participate in global consensus,\n\u003e because they are not global consensus networks, since all participating\n\u003e nodes are not aware of all transactions.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Even if you are right, first fees will raise and that will be what\n\u003e pushes people to other altcoins, no?\n\u003e \u003e\u003e Can we agree that the first step in any potentially bad situation is\n\u003e hitting the limit and then fees rising as a consequence?\n\u003e \u003e\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/c9fb0045/attachment.html\u003e"}