{"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-09-03\n📝 Original message:Some comments:\n\n \t* The 75% rule is meaningless here. Since this is a pure relaxation of\nrules, there is no such thing as \"invalid version 4 blocks\"\n\n\t* \n\nThe implication threshold is unclear. Is it 95% or 80%?\n\n \t* Softfork requires a very high threshold (95%) to \"attack\" the\noriginal fork. This makes sure that unupgraded client will only see the\nnew fork.\n \t* In the case of hardfork, however, the new fork is unable to attack\nthe original fork, and unupgraded client will never see the new fork.\nThe initiation of a hardfork should be based on its acceptance by the\neconomic majority, not miner support. 95% is an overkill and may\nprobably never accomplished. I strongly prefer a 80% threshold rather\nthan 95%.\n\n \t* As I've pointed out, using 20-percentile rather than median creates\nan incentive to 51% attack the uncooperative minority.\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html\n\nHaving said that, I don't have a strong feeling about the use of\n20-percentile as threshold to increase the block size. That means the\nblock size is increased only when most miners agree, which sounds ok to\nme. \n\nHowever, using 20-percentile as threshold to DECREASE the block size\ncould be very dangerous. Consider that the block size has been stable at\n8MB for a few years. Everyone are happy with that. An attacker would\njust need to acquire 21% of mining power to break the status quo and\nsend us all the way to 1MB. The only way to stop such attempt is to 51%\nattack the attacker. That'd be really ugly. \n\nFor technical and ethical reasons, I believe the thresholds for increase\nand decrease must be symmetrical: increase the block size when the\nx-percentile is bigger than the current size, decrease the block size\nwhen the (100-x)-percentile is smaller than the current size. The\noverall effect is: the block size remains unchanged unless 80% of miners\nagree to. \n\n \t* Please consider the use of \"hardfork bit\" to signify the hardfork:\n\nhttps://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/\n\n\nhttps://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki \n\n \t* Or, alternatively, please combine the hardfork with a softfork. I'm\nrewriting the specification as follow (changes underlined):\n\n \t* Replace static 1M block size hard limit with a floating limit\n(\"hardLimit\").\n\n\t* \n\nhardLimit floats within the range 1-32M, inclusive.\n\n\t* \n\nInitial value of hardLimit is 1M, preserving current system.\n \t* Changing hardLimit is accomplished by encoding a proposed value\nwithin a block's coinbase scriptSig.\n\n \t* Votes refer to a byte value, encoded within the pattern \"/BVd+/\"\nExample: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is\nmore than one match with with pattern, the first match is counted.\n \t* Absent/invalid votes and votes below minimum cap (1M) are counted as\n1M votes. Votes above the maximum cap (32M) are counted as 32M votes.\n \t* A new hardLimit is calculated at each difficult adjustment period\n(2016 blocks), and applies to the next 2016 blocks.\n \t* Calculate hardLimit by examining the coinbase scriptSig votes of the\nprevious 12,000 blocks, and taking the 20th percentile and 80th\npercentile.\n \t* New hardLimit is the median of the followings:\n\n \t* min(current hardLimit * 1.2, 20-percentile)\n \t* max(current hardLimit / 1.2, 80-percentile)\n \t* current hardLimit\n\n \t* version 4 block: the coinbase of a version 4 block must match this\npattern: \"/BVd+/\"\n \t* 70% rule: If 8,400 of the last 12,000 blocks are version 4 or\ngreater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)\n \t* 80% rule (\"Point of no return\"): If 9,600 of the last 12,000 blocks\nare version 4 or greater, reject all version \u003c= 3 blocks. (testnet4: 750\nof last 1000)\n \t* Block version number is calculated after masking out high 16 bits\n(final bit count TBD by versionBits outcome).\n\nJeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:\n\u003e BIP 100 initial public draft:\n\u003e https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]\n\u003e \n\u003e Emphasis on \"initial\" This is a starting point for the usual open\n\u003e source feedback/iteration cycle, not an endpoint that Must Be This\n\u003e Way.\n\u003e \n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki\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\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/9bfb6c46/attachment.html\u003e"}