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