05:40:05 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? 05:40:54 I suspec the answer is "Yes": Whoever or whatever pushed the checkpoints to DNS just has to stop, puff, checkpoints gone right away. 05:43:56 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. 05:46:46 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 https://mrelay.p2pool.observer/e/2d2K5rEKd2h1MDlN ] 07:47:20 Records can be stopped or removed 08:00:50 What are the risks with a potential dns spoofing attack? 08:01:29 there is DNSSEC :) 08:05:28 See general information on https://docs.getmonero.org/infrastructure/monero-pulse/ as well 14:18:51 Realistically, approximately how long are DNS checkpoints going to be active? 14:19:01 Are we talking a year+? 14:54:18 until the threat is gone, midipoet, or a different solution is workable 14:54:26 Qubic wants to move to doge within months 14:59:35 if they aren't actively doing selfish, they can exist as a Grim Trigger as rucknium mentioned https://en.wikipedia.org/wiki/Grim_trigger 15:01:59 Or Tit for tat https://en.wikipedia.org/wiki/Tit_for_tat but that opens up the ability to stop and try to find a better timing afterwards 16:39:33 What would be the trigger condition? 16:41:25 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). 16:42:18 The fact that Qubic was so public about their attack has helped us, but a different attacker needn't be so loud. 16:50:47 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 https://mrelay.p2pool.observer/e/4K2K-bEKaEpodE1E ] 16:52:29 If it is believed that another attacker may try to perform deep re-orgs, then rolling DNS checkpoints should probably be enabled regardless. 16:56:24 Taken at face value, Qubic is trying to perform a bribery coup. To succeed, they have needed to be public about it. 16:56:43 Bribery of miners 16:56:54 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 16:57:24 The current focus has been very much on an overt attacker and explicitly Qubic - as a bandaid, not the long term solution 17:50:21 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"? 17:56:42 AFAIK, there is no specific reason that they would have to be paused. The format of the checkpoints is :. The same format would persist through a hard fork. 17:58:05 I think rbrunner7 is asking, what if the checkpoints are followed by a node not going through the hard fork 17:58:45 An extension to include version or identifier to which hardfork you are on might be useful :) 17:59:27 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 18:23:46 Or not enable them 18:42:33 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. 18:42:48 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. 18:46:22 @rbrunner7: No 18:46:35 Non-mining nodes never have a choice 18:46:39 There's a relevant TODO item 11 years old: https://github.com/monero-project/monero/commit/b261d9207ba5cdc0334fab403204971f79b6ca03 18:46:39 > TODO: an easily configurable list of DNS servers to check for checkpoints as opposed to the hard-coded "checkpoints.moneropulse.org" 18:47:30 non-checkpointed node will follow the longest chain 18:48:11 Any node can, of course, do like ruck, tevador, vtnerd did on testnet, and create their own checkpoints 18:49:49 If you want to stay on old hard fork, is the question? Of course. Just dont enable the checkpoints. 18:50:27 Even if enabled, you wont magically join the hard fork, your node wouldnt be able to sync the new blocks 21:30:32 wow > <@ofrnxmr> Non-mining nodes never have a choice 22:47:32 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 22:47:46 something something, crush the rattlesnake