📅 Original date posted:2015-07-22
📝 Original message:Quoting Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>
> Having said that, in general triggering events without verifying a
> supermajority of miner support can be very dangerous. Without miner
> support the chain is insecure, and can be attacked. For instance a
> blocksize limit increase that a majority of miners choose not to
> implement raises huge risks of reorg for any miners who attempt to
> create large blocks, and huge risks of payment reversal for any
> merchants accepting transactions in such blocks. Note how with BIP102,
> extending the original Bitcoin chain is inherently an attack on the
> Garzik chain.
>
> For that reason I think BIP102 is extremely poorly designed. I can only
> conclude that Jeff Garzik is either deliberately trolling us and/or
> manipulating discussion with a badly designed proposal that he doesn't
> actually expect to be adopted verbatim, or is incompetent.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1
To avoid any risk of reorg, the hardfork may require that the first
block with GetMedianTimePast() after a pre-determined time (the "flag
block") MUST be version 0. The exception is applied ONLY to the flag
block.
Alternatively, the hardfork may require that the flag block MUST be
larger than 1MB. Comparing with exploiting the block version, this
does not require additional exceptions in consensus rules. However,
miner may need to artificially inflate the size of the flag block and
that could be trouble in coding. I don't have any preference.
Old nodes will not accept the new chain because it violates BIP66 /
block size limit. New nodes will not accept the old chain because its
flag block is not version 0 / not larger than 1MB.
This is actually checkpointing in a decentralized way. In that case,
we can say goodbye to the old chain forever, as long as all major
merchants and exchanges agree to upgrade. Miner support is less
relevant. It is a no-brainer for miners to support the new chain,
unless they don't want to sell or spend their bitcoin, or just give up
mining after heavily investing in ASIC.
jl2012
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 15:42:33
in reply to nevent1q…zarj
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Seen on
wss://relay.nostr.bandPublished at
2023-06-07 15:42:33Event JSON
{
"id": "d10d016241d8be06a4a49023c61e6f2c2805755db4c2d059177d732ca5faa1b5",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686152553,
"kind": 1,
"tags": [
[
"e",
"2e544b01cfe0620e95990efdfb39d6c5828a4b2f5866e5b209d567b2efd50207",
"",
"root"
],
[
"e",
"08525e6c66707ef939951bcad09eb8d8a1939964ef4f0b8116284bf6c822be1b",
"",
"reply"
],
[
"p",
"b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa"
]
],
"content": "📅 Original date posted:2015-07-22\n📝 Original message:Quoting Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e\n\u003e Having said that, in general triggering events without verifying a\n\u003e supermajority of miner support can be very dangerous. Without miner\n\u003e support the chain is insecure, and can be attacked. For instance a\n\u003e blocksize limit increase that a majority of miners choose not to\n\u003e implement raises huge risks of reorg for any miners who attempt to\n\u003e create large blocks, and huge risks of payment reversal for any\n\u003e merchants accepting transactions in such blocks. Note how with BIP102,\n\u003e extending the original Bitcoin chain is inherently an attack on the\n\u003e Garzik chain.\n\u003e\n\u003e For that reason I think BIP102 is extremely poorly designed. I can only\n\u003e conclude that Jeff Garzik is either deliberately trolling us and/or\n\u003e manipulating discussion with a badly designed proposal that he doesn't\n\u003e actually expect to be adopted verbatim, or is incompetent.\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1\n\nTo avoid any risk of reorg, the hardfork may require that the first \nblock with GetMedianTimePast() after a pre-determined time (the \"flag \nblock\") MUST be version 0. The exception is applied ONLY to the flag \nblock.\n\nAlternatively, the hardfork may require that the flag block MUST be \nlarger than 1MB. Comparing with exploiting the block version, this \ndoes not require additional exceptions in consensus rules. However, \nminer may need to artificially inflate the size of the flag block and \nthat could be trouble in coding. I don't have any preference.\n\nOld nodes will not accept the new chain because it violates BIP66 / \nblock size limit. New nodes will not accept the old chain because its \nflag block is not version 0 / not larger than 1MB.\n\nThis is actually checkpointing in a decentralized way. In that case, \nwe can say goodbye to the old chain forever, as long as all major \nmerchants and exchanges agree to upgrade. Miner support is less \nrelevant. It is a no-brainer for miners to support the new chain, \nunless they don't want to sell or spend their bitcoin, or just give up \nmining after heavily investing in ASIC.\n\njl2012",
"sig": "e4555492e827fa1da7e582ff21877b3d87e96dbde5cee63adb150d7cd72a3fe0c88380907a5639550be105912e90dfe13e698fcb39491589cb37d413c5b01c52"
}