📅 Original date posted:2013-03-12
📝 Original message:>> Forks are caused by rejection criteria, hence:
>> 1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_.
>> 2. If you loosen some rejection criteria miners should upgrade _last_.
>> 3. If you keep the same criteria assume 2.
>
> And ... if you aren't aware that you're making a change ???
then only half should upgrade :-P
Well I thought I covered that by 3... But, question is of course if we could have been in a situation where 0.8 had been the one rejecting blocks?
So miners could go with a filtering approach: only connect to the network through a node of a version one less than the current. That would still have caused block 225430 to be created, but it would never have been relayed and hence no harm. (and if the issue had been in 0.8 the block would not even have been accepted there in the first place). Downside is some lost seconds.
/M
Michael Gronager [ARCHIVE] /
npub1nc…gw452
2023-06-07 13:37:28
in reply to nevent1q…3pxm
Author Public Key
npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452Published at
2023-06-07 13:37:28Event JSON
{
"id": "9da33d09444e767fc4725faa8073d653a8681e355dda95772d8aa471343c8036",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686137848,
"kind": 1,
"tags": [
[
"e",
"bf6db92ac74ed2040908c22a007eaccc4dacca3e534709bcb8876ea849933631",
"",
"root"
],
[
"e",
"9f6cdc7cf4f3b445aaa80b5fcc4f8d7bb4d5fcd5c8749bfe82ea0fc7bf1839c2",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2013-03-12\n📝 Original message:\u003e\u003e Forks are caused by rejection criteria, hence:\n\u003e\u003e 1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_.\n\u003e\u003e 2. If you loosen some rejection criteria miners should upgrade _last_.\n\u003e\u003e 3. If you keep the same criteria assume 2.\n\u003e \n\u003e And ... if you aren't aware that you're making a change ???\n\nthen only half should upgrade :-P\n\nWell I thought I covered that by 3... But, question is of course if we could have been in a situation where 0.8 had been the one rejecting blocks? \n\nSo miners could go with a filtering approach: only connect to the network through a node of a version one less than the current. That would still have caused block 225430 to be created, but it would never have been relayed and hence no harm. (and if the issue had been in 0.8 the block would not even have been accepted there in the first place). Downside is some lost seconds.\n\n/M",
"sig": "1de71eaf3c9b738000f8789dde2ef5d8d01d7b733aa241c77564675f3f1e2ee7155e2a22857a8eaf5e602ec58223b5bca46b8ee4d0c2ab96fbb2887946da5a64"
}