{"type":"rich","version":"1.0","author_name":"npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","author_url":"https://nostr.ae/npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-03\n📝 Original message:We should avoid discussing actual hard fork/softfork deployment\nmethodologies when discussing blocksize proposals because deployment\nis a separate issue. As a recent case in point, look at how BIP65\n(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.\nThat lead to a focused discussion of the functionality and relatively\nquick inclusion.\n\nDeployment really is a separate issue than the mechanics of how BIP100\nwill function after activation.\n\nOn Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Some comments:\n\u003e\n\u003e The 75% rule is meaningless here. Since this is a pure relaxation of rules,\n\u003e there is no such thing as \"invalid version 4 blocks\"\n\u003e\n\u003e The implication threshold is unclear. Is it 95% or 80%?\n\u003e\n\u003e Softfork requires a very high threshold (95%) to \"attack\" the original fork.\n\u003e This makes sure that unupgraded client will only see the new fork.\n\u003e In the case of hardfork, however, the new fork is unable to attack the\n\u003e original fork, and unupgraded client will never see the new fork. The\n\u003e initiation of a hardfork should be based on its acceptance by the economic\n\u003e majority, not miner support. 95% is an overkill and may probably never\n\u003e accomplished. I strongly prefer a 80% threshold rather than 95%.\n\u003e\n\u003e As I've pointed out, using 20-percentile rather than median creates an\n\u003e incentive to 51% attack the uncooperative minority.\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html\n\u003e\n\u003e Having said that, I don't have a strong feeling about the use of\n\u003e 20-percentile as threshold to increase the block size. That means the block\n\u003e size is increased only when most miners agree, which sounds ok to me.\n\u003e\n\u003e However, using 20-percentile as threshold to DECREASE the block size could\n\u003e be very dangerous. Consider that the block size has been stable at 8MB for a\n\u003e few years. Everyone are happy with that. An attacker would just need to\n\u003e acquire 21% of mining power to break the status quo and send us all the way\n\u003e to 1MB. The only way to stop such attempt is to 51% attack the attacker.\n\u003e That'd be really ugly.\n\u003e\n\u003e For technical and ethical reasons, I believe the thresholds for increase and\n\u003e decrease must be symmetrical: increase the block size when the x-percentile\n\u003e is bigger than the current size, decrease the block size when the\n\u003e (100-x)-percentile is smaller than the current size. The overall effect is:\n\u003e the block size remains unchanged unless 80% of miners agree to.\n\u003e\n\u003e Please consider the use of \"hardfork bit\" to signify the hardfork:\n\u003e\n\u003e https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/\n\u003e\n\u003e https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki\n\u003e\n\u003e Or, alternatively, please combine the hardfork with a softfork. I'm\n\u003e rewriting the specification as follow (changes underlined):\n\u003e\n\u003e Replace static 1M block size hard limit with a floating limit (\"hardLimit\").\n\u003e\n\u003e hardLimit floats within the range 1-32M, inclusive.\n\u003e\n\u003e Initial value of hardLimit is 1M, preserving current system.\n\u003e\n\u003e Changing hardLimit is accomplished by encoding a proposed value within a\n\u003e block's coinbase scriptSig.\n\u003e\n\u003e Votes refer to a byte value, encoded within the pattern \"/BV\\d+/\" Example:\n\u003e /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one\n\u003e match with with pattern, the first match is counted.\n\u003e Absent/invalid votes and votes below minimum cap (1M) are counted as 1M\n\u003e votes. Votes above the maximum cap (32M) are counted as 32M votes.\n\u003e A new hardLimit is calculated at each difficult adjustment period (2016\n\u003e blocks), and applies to the next 2016 blocks.\n\u003e Calculate hardLimit by examining the coinbase scriptSig votes of the\n\u003e previous 12,000 blocks, and taking the 20th percentile and 80th percentile.\n\u003e New hardLimit is the median of the followings:\n\u003e\n\u003e min(current hardLimit * 1.2, 20-percentile)\n\u003e max(current hardLimit / 1.2, 80-percentile)\n\u003e current hardLimit\n\u003e\n\u003e version 4 block: the coinbase of a version 4 block must match this pattern:\n\u003e \"/BV\\d+/\"\n\u003e 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,\n\u003e reject invalid version 4 blocks. (testnet4: 501 of last 1000)\n\u003e 80% rule (\"Point of no return\"): If 9,600 of the last 12,000 blocks are\n\u003e version 4 or greater, reject all version \u003c= 3 blocks. (testnet4: 750 of last\n\u003e 1000)\n\u003e Block version number is calculated after masking out high 16 bits (final bit\n\u003e count TBD by versionBits outcome).\n\u003e\n\u003e Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:\n\u003e\u003e BIP 100 initial public draft:\n\u003e\u003e https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]\n\u003e\u003e\n\u003e\u003e Emphasis on \"initial\"  This is a starting point for the usual open\n\u003e\u003e source feedback/iteration cycle, not an endpoint that Must Be This\n\u003e\u003e Way.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Links:\n\u003e\u003e ------\n\u003e\u003e [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}