<rbrunner7> I came up with a question about those temporary rolling DNS checkpoints that we discussed yesterday in the meeting: Once we have those active on mainnet, is there something that amounts to an emergency off switch for the checkpoints?

<rbrunner7> I suspec the answer is "Yes": Whoever or whatever pushed the checkpoints to DNS just has to stop, puff, checkpoints gone right away.

<rbrunner7> The background of this is a slight uneasiness of mine about the whole thing. This feature is new, it's not exactly trivial, it's a quite sharp sword so to say, and might have complex dynamics on the network because it's only a soft fork and behavior might depend on the percentage of nodes having them active.

<rbrunner7> Plus, what make me think the most: It may turn out to be quite hard to test this feature well beforehand, because there is only one mainnet, and testing "under realistic conditions" is very hard or maybe next to impossible. So if we deploy, there will be a "residual risk" that something unexpected goes wrong. Hence my question [... too long, see mrelay.p2pool.observer/e/2d2K5rEKd2h1MDlN ]

Records can be stopped or removed

<drinksomemilk:matrix.org> What are the risks with a potential dns spoofing attack?

there is DNSSEC :)

See general information on docs.getmonero.org/infrastructure/monero-pulse as well

Realistically, approximately how long are DNS checkpoints going to be active?

Are we talking a year+?

until the threat is gone, midipoet, or a different solution is workable

Qubic wants to move to doge within months

if they aren't actively doing selfish, they can exist as a Grim Trigger as rucknium mentioned en.wikipedia.org/wiki/Grim_trigger

Or Tit for tat en.wikipedia.org/wiki/Tit_for_tat but that opens up the ability to stop and try to find a better timing afterwards

What would be the trigger condition?

Surely, if the vulnerability exists a new attacker could publish a 10+ re-org before we are able to renable the checkpoints, or would be have some watch tower system (seems impossible if we don't have eyesight on who the new attacker is).

The fact that Qubic was so public about their attack has helped us, but a different attacker needn't be so loud.

<rucknium> My original idea assumed that enabling checkpoints is undesirable for the protocol since it reduces decentralization. If the assumption is true, enabling checkpoints puts both the protocol and Qubic in a worse state than now. To avoid the worse state for both sides (and keep the status quo, both sides would punish indefinitely [... too long, see mrelay.p2pool.observer/e/4K2K-bEKaEpodE1E ]

<rucknium> If it is believed that another attacker may try to perform deep re-orgs, then rolling DNS checkpoints should probably be enabled regardless.

<rucknium> Taken at face value, Qubic is trying to perform a bribery coup. To succeed, they have needed to be public about it.

<rucknium> Bribery of miners

midipoet: if a system is setup ahead of time, checkpoints can be reactive to bring back to previous chain. but that hasn't been talked about yet

The current focus has been very much on an overt attacker and explicitly Qubic - as a bandaid, not the long term solution

<rbrunner7> What is the relation between checkpoints and hardforks? Assuming that we are forced to keep them up for longer, and also have to hardfork, would that go together? Or would we have to pause them for "hardfork day"?

<rucknium> AFAIK, there is no specific reason that they would have to be paused. The format of the checkpoints is <height>:<block_hash>. The same format would persist through a hard fork.

I think rbrunner7 is asking, what if the checkpoints are followed by a node not going through the hard fork

An extension to include version or identifier to which hardfork you are on might be useful :)

or otherwise, these monerod can be considered not updated nodes, and if the old operators want to keep them before hardfork they can edit out the dns entries or disable dns checkpoints

<ofrnxmr> Or not enable them

<rbrunner7> I had indeed both questions, but started with the first one :) Good to hear that for a normal, uncontested hardfork it's probably no technical problem to just keep checkpoints going through the whole hardfork period.

<rbrunner7> But the second question is also interesting: Is my freedom to stay on the old chain using the old software still intact if I am not ready to accept the new Monero software version? Seems that's not a big issue if some like-minded people that also want to stay take care of the checkpointing for the old chain.

<ofrnxmr> @rbrunner7: No

<ofrnxmr> Non-mining nodes never have a choice

<rucknium> There's a relevant TODO item 11 years old: monero-project/monero b261d92

<rucknium> > TODO: an easily configurable list of DNS servers to check for checkpoints as opposed to the hard-coded "checkpoints.moneropulse.org"

<ofrnxmr> non-checkpointed node will follow the longest chain

<ofrnxmr> Any node can, of course, do like ruck, tevador, vtnerd did on testnet, and create their own checkpoints

<ofrnxmr> If you want to stay on old hard fork, is the question? Of course. Just dont enable the checkpoints.

<ofrnxmr> Even if enabled, you wont magically join the hard fork, your node wouldnt be able to sync the new blocks

<interestingband:matrix.org> wow > <@ofrnxmr> Non-mining nodes never have a choice

<blurt4949:matrix.org> The grim trigger approach only works for us if we assume that Qubic is economically rational and that there are no externalities. We should not wait for Qubic to do something obnoxious before countering the threat

<blurt4949:matrix.org> something something, crush the rattlesnake