📅 Original date posted:2015-09-03
📝 Original message:Some comments:
* The 75% rule is meaningless here. Since this is a pure relaxation of
rules, there is no such thing as "invalid version 4 blocks"
*
The implication threshold is unclear. Is it 95% or 80%?
* Softfork requires a very high threshold (95%) to "attack" the
original fork. This makes sure that unupgraded client will only see the
new fork.
* In the case of hardfork, however, the new fork is unable to attack
the original fork, and unupgraded client will never see the new fork.
The initiation of a hardfork should be based on its acceptance by the
economic majority, not miner support. 95% is an overkill and may
probably never accomplished. I strongly prefer a 80% threshold rather
than 95%.
* As I've pointed out, using 20-percentile rather than median creates
an incentive to 51% attack the uncooperative minority.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
Having said that, I don't have a strong feeling about the use of
20-percentile as threshold to increase the block size. That means the
block size is increased only when most miners agree, which sounds ok to
me.
However, using 20-percentile as threshold to DECREASE the block size
could be very dangerous. Consider that the block size has been stable at
8MB for a few years. Everyone are happy with that. An attacker would
just need to acquire 21% of mining power to break the status quo and
send us all the way to 1MB. The only way to stop such attempt is to 51%
attack the attacker. That'd be really ugly.
For technical and ethical reasons, I believe the thresholds for increase
and decrease must be symmetrical: increase the block size when the
x-percentile is bigger than the current size, decrease the block size
when the (100-x)-percentile is smaller than the current size. The
overall effect is: the block size remains unchanged unless 80% of miners
agree to.
* Please consider the use of "hardfork bit" to signify the hardfork:
https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
* Or, alternatively, please combine the hardfork with a softfork. I'm
rewriting the specification as follow (changes underlined):
* Replace static 1M block size hard limit with a floating limit
("hardLimit").
*
hardLimit floats within the range 1-32M, inclusive.
*
Initial value of hardLimit is 1M, preserving current system.
* Changing hardLimit is accomplished by encoding a proposed value
within a block's coinbase scriptSig.
* Votes refer to a byte value, encoded within the pattern "/BVd+/"
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
more than one match with with pattern, the first match is counted.
* Absent/invalid votes and votes below minimum cap (1M) are counted as
1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
* A new hardLimit is calculated at each difficult adjustment period
(2016 blocks), and applies to the next 2016 blocks.
* Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile and 80th
percentile.
* New hardLimit is the median of the followings:
* min(current hardLimit * 1.2, 20-percentile)
* max(current hardLimit / 1.2, 80-percentile)
* current hardLimit
* version 4 block: the coinbase of a version 4 block must match this
pattern: "/BVd+/"
* 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
* 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750
of last 1000)
* Block version number is calculated after masking out high 16 bits
(final bit count TBD by versionBits outcome).
Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> BIP 100 initial public draft:
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>
> Emphasis on "initial" This is a starting point for the usual open
> source feedback/iteration cycle, not an endpoint that Must Be This
> Way.
>
>
>
> Links:
> ------
> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/9bfb6c46/attachment.html>;
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 17:39:17
in reply to nevent1q…4wdf
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 17:39:17Event JSON
{
"id": "6cb80e9e8820e8a999db7eb4f2bc7b6bd85ff1bfb294a0ff7b6a19bf8f75ca44",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159557,
"kind": 1,
"tags": [
[
"e",
"a137c877ff26a7c79ddcf309fc77d8729c3f5cc9c177f8e08369ded48fb80356",
"",
"root"
],
[
"e",
"820902d3aed1a5a5d4f3350e9d281c377613b27c25a6a1e5887bab3f1a3f8699",
"",
"reply"
],
[
"p",
"a384795310cea1937dda4d01ee8f14ca734b9a7ab60c62114a5656706e15e47f"
]
],
"content": "📅 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",
"sig": "4e44e5ca5255a88e756706079684de6f31a0e6c0c508940c8eacaa9249f55513d9e6a07b37223e0a2af9e215a365626c36e56e50755496964bdc974a1529913c"
}