{"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:The only reason why Bitcoin has grown the way it has, and in fact the only\nreason why we're all even here on this mailing list talking about this, is\nbecause Bitcoin is growing, since it's \"better money than other money\". One\nof the key characteristics toward that is Bitcoin being inexpensive to\ntransact. If that characteristic is no longer true, then Bitcoin isn't\ngoing to grow, and in fact Bitcoin itself will be replaced by better money\nthat is less expensive to transfer.\n\nSo the importance of this issue cannot be overstated -- it's compete or die\nfor Bitcoin -- because people want to transact with global consensus at\nhigh volume, and because technology exists to service that want, then it's\ngoing to be met. This is basic rules of demand and supply. I don't\nnecessarily disagree with your position on only wanting to support\nuncontroversial commits, but I think it's important to get consensus on the\ncriticality of the block size issue: do you agree, disagree, or not take a\nside, and why?\n\n\nOn Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nwrote:\n\n\u003e On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hitting the limit in and of itself is not necessarily a bad thing. The\n\u003e\u003e question at hand is whether we should constrain that limit below what\n\u003e\u003e technology is capable of delivering. I'm arguing that not only we should\n\u003e\u003e not, but that we could not even if we wanted to, since competition will\n\u003e\u003e deliver capacity for global consensus whether it's in Bitcoin or in some\n\u003e\u003e other product / fork.\n\u003e\u003e\n\u003e\n\u003e The question is not what the technology can deliver. The question is what\n\u003e price we're willing to pay for that. It is not a boolean \"at this size,\n\u003e things break, and below it, they work\". A small constant factor increase\n\u003e will unlikely break anything in the short term, but it will come with\n\u003e higher centralization pressure of various forms. There is discussion about\n\u003e whether these centralization pressures are significant, but citing that\n\u003e it's artificially constrained under the limit is IMHO a misrepresentation.\n\u003e It is constrained to aim for a certain balance between utility and risk,\n\u003e and neither extreme is interesting, while possibly still \"working\".\n\u003e\n\u003e Consensus rules are what keeps the system together. You can't simply\n\u003e switch to new rules on your own, because the rest of the system will end up\n\u003e ignoring you. These rules are there for a reason. You and I may agree about\n\u003e whether the 21M limit is necessary, and disagree about whether we need a\n\u003e block size limit, but we should be extremely careful with change. My\n\u003e position as Bitcoin Core developer is that we should merge consensus\n\u003e changes only when they are uncontroversial. Even when you believe a more\n\u003e invasive change is worth it, others may disagree, and the risk from\n\u003e disagreement is likely larger than the effect of a small block size\n\u003e increase by itself: the risk that suddenly every transaction can be spent\n\u003e twice (once on each side of the fork), the very thing that the block chain\n\u003e was designed to prevent.\n\u003e\n\u003e My personal opinion is that we should aim to do a block size increase for\n\u003e the right reasons. I don't think fear of rising fees or unreliability\n\u003e should be an issue: if fees are being paid, it means someone is willing to\n\u003e pay them. If people are doing transactions despite being unreliable, there\n\u003e must be a use for them. That may mean that some use cases don't fit\n\u003e anymore, but that is already the case.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/becc6fff/attachment.html\u003e"}