š
Original date posted:2016-11-16
š Original message:On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:
> I think we are misunderstanding the effect of this change.
> It's still "OK" for a 50k re-org to happen.
> We're just saying that if it does, we will now have potentially introduced
> a hard fork between new client and old clients if the reorg contains
> earlier signaling for the most recent ISM soft fork and then blocks which
> do not conform to that soft fork before the block height encoded activation.
>
> I think the argument is this doesn't substantially add to the confusion or
> usability of the system as its likely that old software won't even handle
> 50k block reorgs cleanly anyway and there will clearly have to be human
> coordination at the time of the event. In the unlikely event that the new
> chain does cause such a hard fork, that coordination can result in everyone
> upgrading to software that supports the new rules anyway.
>
> So no, I don't think we should add a checkpoint. I think we should all
> just agree to a hard fork that only has a very very slim chance of any
> practical effect.
So, conceptually, another way to deal with this is to hardcode a blockhash
where we allow blocks in a chain ending with that blockhash to _not_ follow
BIP65, up until that blockhash, and any blockchain without that blockhash must
respect BIP65 for all blocks in the chain.
This is a softfork: we've only added rules that made otherwise valid chains
invalid, and at the same time we are still accepting large reorgs (albeit under
stricter rules than before).
I'd suggest we call this a exemption hash - we've exempted a particular
blockchains from a soft-forked rule that we would otherwise enforce.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/eef4afb9/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 17:54:19
in reply to nevent1qā¦8pq7
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 17:54:19Event JSON
{
"id": "296564c48e3d125eb1c04da08bc3992dc1875435b7f21be3b4a4d5ea4f2e984b",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686160459,
"kind": 1,
"tags": [
[
"e",
"50cde70d11f9c69cc787e52010ba0256918f920ad1f9811ad6566a1543ec1282",
"",
"root"
],
[
"e",
"1c076b88a6214542722c5e22925603cc6b5042407d0605fbb498ed78bb27c051",
"",
"reply"
],
[
"p",
"78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c"
]
],
"content": "š
Original date posted:2016-11-16\nš Original message:On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:\n\u003e I think we are misunderstanding the effect of this change.\n\u003e It's still \"OK\" for a 50k re-org to happen.\n\u003e We're just saying that if it does, we will now have potentially introduced\n\u003e a hard fork between new client and old clients if the reorg contains\n\u003e earlier signaling for the most recent ISM soft fork and then blocks which\n\u003e do not conform to that soft fork before the block height encoded activation.\n\u003e \n\u003e I think the argument is this doesn't substantially add to the confusion or\n\u003e usability of the system as its likely that old software won't even handle\n\u003e 50k block reorgs cleanly anyway and there will clearly have to be human\n\u003e coordination at the time of the event. In the unlikely event that the new\n\u003e chain does cause such a hard fork, that coordination can result in everyone\n\u003e upgrading to software that supports the new rules anyway.\n\u003e \n\u003e So no, I don't think we should add a checkpoint. I think we should all\n\u003e just agree to a hard fork that only has a very very slim chance of any\n\u003e practical effect.\n\nSo, conceptually, another way to deal with this is to hardcode a blockhash\nwhere we allow blocks in a chain ending with that blockhash to _not_ follow\nBIP65, up until that blockhash, and any blockchain without that blockhash must\nrespect BIP65 for all blocks in the chain.\n\nThis is a softfork: we've only added rules that made otherwise valid chains\ninvalid, and at the same time we are still accepting large reorgs (albeit under\nstricter rules than before).\n\nI'd suggest we call this a exemption hash - we've exempted a particular\nblockchains from a soft-forked rule that we would otherwise enforce.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/eef4afb9/attachment.sig\u003e",
"sig": "f29649ff3f68560373f2fcacc94b532adc20b7673b27bc5c19ddcb7b453f649018b2329380bcf33ca02f262dca77357281bd38cfb6623cf1b253756fc0eaa7c7"
}