{"type":"rich","version":"1.0","author_name":"npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","author_url":"https://nostr.ae/npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-30\n📝 Original message:Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:\n\n\u003e \n\u003e I still don't see the point in having a lower moving size maximum.\n\u003e If 8 MB is mining-centralization-safe, let's move directly to 8 MB\n\u003e without adding this seemingly useless extra complexity.\n\u003e If it's not, mining voting on a lower moving maximum won't make it \n\u003e safer.\n\u003e \n\u003e Once we have more objective tools (centralization metrics, simulators,\n\u003e etc...) to determine whether or not a block size is\n\u003e mining-centralization-safe for a given point in time (looking at\n\u003e current centralization and current technology available), I don't see\n\u003e the problem with repeating the equivalent of bip102 periodically\n\u003e (every 2 years?) to adapt the size to better technology or lower\n\u003e mining centralization.\n\u003e It would be also helpful to have a tool to somehow measure \"size\n\u003e increase urgency\" (ie right now free transactions get mined and blocks\n\u003e aren't full or close to be full, I don't think the current general\n\u003e sense of urgency on this matter is justified).\n\u003e \n\u003e With all respect, I believe bip100 and this proposal are\n\u003e over-engineering; and bip101 and bip103 (pieter's) are\n\u003e overly-optimistic (in their exponential technological growth\n\u003e assumptions).\n\nThis is based on the assumption that miners would always like to use up \nthe last byte of the available block size. However, this is just not \ntrue:\n\n1. The 6 year blockchain history has shown that most miners have a soft \ncap with their block size.\n\n2. Chinese miners, controlling 60% of the network, rejected Gavin's \ninitial 20MB proposal and asked for 8MB: \nhttp://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size\n\n3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with \n8MB as a mid-term goal: \nhttps://vip.btcchina.com/page/noticetemplate?id=100.\nBTCChina is controlling 12% of the network in the past month. If BIP100 \nuses the 20-percentile vote as the block size, it takes only 8% more \nvote to keep the size at 2MB\n\nFor many reasons miners may want to have a smaller block size, which we \ndon't need to list them here. Although they can limit it by a softfork \nor even 51% attack, it is a very violent process. Why don't we just \nallow them to vote for a lower limit?\n\nSo I think the right way is to choose a mining-centralization-safe \nlimit, and let it free float within a range based on miner's vote. If we \nare lucky enough to have some responsible miners, they will keep it as \nlow as possible, until the legitimate tx volume catches up. Even in the \nworst case, the block size is still mining-centralization-safe. The \nupper limit may increase linearly, if not exponentially, until we find a \nbetter long-term solution. (sort of a combination of BIP100 and 101, \nwith different parameters)\n\n--------\nFor the matter of \"urgency\", I agree with you that there is no actual \nurgency AT THIS MOMENT. However, if a hardfork may take 5 years to \ndeploy (as you suggested), we really have the urgency to make a decision \nnow. Actually, the main point is not urgency but uncertainty. We have \ndebated for 5 years. Why won't we have 5 more years of debate, plus 5 \nyears of deployment delay? Are we sticking to 1MB for 10 years? In that \ncase Bitcoin Core must be abandoned by the economic majority and a \nSchism fork must occur."}