📅 Original date posted:2015-09-03
📝 Original message:Thanks - several good suggestions, including some in common. Will comment
& revise today.
Currently in "collecting" mode, to avoid duplicative comments in multiple
locales.
On Thu, Sep 3, 2015 at 3:57 AM, <jl2012 at xbt.hk> wrote:
> 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):
>
>
> 1. Replace static 1M block size hard limit with a floating limit
> ("hardLimit").
> 2.
>
> hardLimit floats within the range 1-32M, inclusive.
>
> 3.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> 4. Changing hardLimit is accomplished by encoding a proposed value
> within a block's coinbase scriptSig.
> 1. Votes refer to a byte value, encoded within the pattern
> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
> there is more than one match with with pattern, the first match is counted.
> 2. 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.
> 3. A new hardLimit is calculated at each difficult adjustment
> period (2016 blocks), and applies to the next 2016 blocks.
> 4. Calculate hardLimit by examining the coinbase scriptSig votes of
> the previous 12,000 blocks, and taking the 20th percentile and 80th
> percentile.
> 5. New hardLimit is the median of the followings:
> 1. min(current hardLimit * 1.2, 20-percentile)
> 2. max(current hardLimit / 1.2, 80-percentile)
> 3. current hardLimit
> 5. version 4 block: the coinbase of a version 4 block must match
> this pattern: "/BV\d+/"
> 6. 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)
> 7. 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)
> 8. 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/2be39ef3/attachment.html>;
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 17:39:22
in reply to nevent1q…l9el
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 17:39:22Event JSON
{
"id": "cb6406ffb52035b4a7af44ce11ec8242c3d49ac12d2b6c0424239e55efd2ca70",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686159562,
"kind": 1,
"tags": [
[
"e",
"a137c877ff26a7c79ddcf309fc77d8729c3f5cc9c177f8e08369ded48fb80356",
"",
"root"
],
[
"e",
"c525c94b6d2e4c161ad126a958df2e25854692fa0b61ad4529a61b3f81bdc04d",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2015-09-03\n📝 Original message:Thanks - several good suggestions, including some in common. Will comment\n\u0026 revise today.\n\nCurrently in \"collecting\" mode, to avoid duplicative comments in multiple\nlocales.\n\n\n\nOn Thu, Sep 3, 2015 at 3:57 AM, \u003cjl2012 at xbt.hk\u003e wrote:\n\n\u003e Some comments:\n\u003e\n\u003e\n\u003e - The 75% rule is meaningless here. Since this is a pure relaxation of\n\u003e rules, there is no such thing as \"invalid version 4 blocks\"\n\u003e\n\u003e\n\u003e -\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\n\u003e original fork. This makes sure that unupgraded client will only see the new\n\u003e fork.\n\u003e - In the case of hardfork, however, the new fork is unable to\n\u003e attack the original fork, and unupgraded client will never see the new\n\u003e fork. The initiation of a hardfork should be based on its acceptance by the\n\u003e economic majority, not miner support. 95% is an overkill and may probably\n\u003e never accomplished. I strongly prefer a 80% threshold rather than 95%.\n\u003e\n\u003e\n\u003e - As I've pointed out, using 20-percentile rather than median creates\n\u003e an 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\n\u003e a 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\n\u003e and decrease must be symmetrical: increase the block size when the\n\u003e x-percentile is bigger than the current size, decrease the block size when\n\u003e the (100-x)-percentile is smaller than the current size. The overall effect\n\u003e is: 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\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\n\u003e 1. Replace static 1M block size hard limit with a floating limit\n\u003e (\"hardLimit\").\n\u003e 2.\n\u003e\n\u003e hardLimit floats within the range 1-32M, inclusive.\n\u003e\n\u003e 3.\n\u003e\n\u003e Initial value of hardLimit is 1M, preserving current system.\n\u003e\n\u003e 4. Changing hardLimit is accomplished by encoding a proposed value\n\u003e within a block's coinbase scriptSig.\n\u003e 1. Votes refer to a byte value, encoded within the pattern\n\u003e \"/BV\\d+/\" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If\n\u003e there is more than one match with with pattern, the first match is counted.\n\u003e 2. Absent/invalid votes and votes below minimum cap (1M) are\n\u003e counted as 1M votes. Votes above the maximum cap (32M) are counted as 32M\n\u003e votes.\n\u003e 3. A new hardLimit is calculated at each difficult adjustment\n\u003e period (2016 blocks), and applies to the next 2016 blocks.\n\u003e 4. Calculate hardLimit by examining the coinbase scriptSig votes of\n\u003e the previous 12,000 blocks, and taking the 20th percentile and 80th\n\u003e percentile.\n\u003e 5. New hardLimit is the median of the followings:\n\u003e 1. min(current hardLimit * 1.2, 20-percentile)\n\u003e 2. max(current hardLimit / 1.2, 80-percentile)\n\u003e 3. current hardLimit\n\u003e 5. version 4 block: the coinbase of a version 4 block must match\n\u003e this pattern: \"/BV\\d+/\"\n\u003e 6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or\n\u003e greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)\n\u003e 7. 80% rule (\"Point of no return\"): If 9,600 of the last 12,000 blocks\n\u003e are version 4 or greater, reject all version \u003c= 3 blocks. (testnet4: 750 of\n\u003e last 1000)\n\u003e 8. Block version number is calculated after masking out high 16 bits\n\u003e (final bit 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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/2be39ef3/attachment.html\u003e",
"sig": "2147ff25b861afbbc37b874e00d5c01af88a5d2d122681222961b752f5b6a8a07a34a0297cfddc63ffbd240308d1fa70b58f59a06d0066e2fa3f065d48c15079"
}