đ
Original date posted:2016-09-10
đ Original message:Concept ACK.
For the details of executing the plan, I think the following is less disruptive:
1. Send a message with (max sequence - 1), notifying all nodes that the key will be retired on or before a date. People with systems relying on this key should either upgrade or ignore the revocation message. We don't know the actual date because the key is shared by many people.
With the max - 1 sequence, no message except the max sequence revocation message may override this message.
2. Send the revocation message at the pre-announced time, if no one have done that before
3. After a few months or so, publish the private key.
>
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
>
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
>
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
>
> Cheers,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Johnson Lau [ARCHIVE] /
npub1fyâŚp2mv9
2023-06-07 17:53:19
in reply to nevent1qâŚrjzt
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 17:53:19Event JSON
{
"id": "9b8ecce286a0d9f73f6fe26bdb53effc20057b0138aa266f8a540e9e55bf7e62",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686160399,
"kind": 1,
"tags": [
[
"e",
"ed97aecfd7231dd89e72db761c8234f2651c42cb9220c0490f6193a4323e2abb",
"",
"root"
],
[
"e",
"f81eae6bd588a3bb71b9e3b720893d0cd2143e85d6f2010fede4bca753bc68e1",
"",
"reply"
],
[
"p",
"5c0b7fca51fd4830b4d9f840de063faebeeabd3bb5dd118de9cdf50a6feaaf98"
]
],
"content": "đ
Original date posted:2016-09-10\nđ Original message:Concept ACK.\n\nFor the details of executing the plan, I think the following is less disruptive:\n\n1. Send a message with (max sequence - 1), notifying all nodes that the key will be retired on or before a date. People with systems relying on this key should either upgrade or ignore the revocation message. We don't know the actual date because the key is shared by many people.\n\nWith the max - 1 sequence, no message except the max sequence revocation message may override this message. \n\n2. Send the revocation message at the pre-announced time, if no one have done that before\n\n3. After a few months or so, publish the private key.\n\n \u003e \n \u003e One of the facilities in the alert system is that you can send a \n \u003e maximum sequence alert which cannot be overridden and displays only a \n \u003e static key compromise text message and blocks all other alerts. I plan \n \u003e to send a triggering alert in the not-distant future (exact time to be \n \u003e announced well in advance) feedback on timing would be welcome. \n \u003e \n \u003e There are likely a few production systems that automatically shut down \n \u003e when there is an alert, so this risks some small one-time disruption \n \u003e of those services-- but none worse than if an alert were sent to \n \u003e advise about a new system upgrade. \n \u003e \n \u003e At some point after that, I would then plan to disclose this private \n \u003e key in public, eliminating any further potential of reputation attacks \n \u003e and diminishing the risk of misunderstanding the key as some special \n \u003e trusted source of authority. \n \u003e \n \u003e Cheers, \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 \u003e",
"sig": "a51da77aae22da4ecbad1e82d05fa4908b9b2e11d68a84da7ad18a4123666a3857b2ecaf02f2b2f7ffd204f911c544e32369b1d4d3b01e96301eeee498e5631d"
}