00:53:18 I have done some more thinking about rolling DNS checkpoints and am now less favorable on them again. Not that my opinion matters much haha. I do admit that rolling DNS checkpoints are a good pragmatic solution to "mitigate" deep re-orgs until a more comprehensive solution to selfish mining is ready. Here are some of my concer [... too long, see https://mrelay.p2pool.observer/e/sZbXq7MKSHlCTXct ] 01:02:17 1) the keys are individual and they are DNSSEC, that's also where tevador's 2/3rds +1 % (supermajority two-thirds rule) 01:02:55 these subdomains would be kept separate from the main domains which can be removed/rotated as needed 01:04:15 4) DNS servers DDOS as in, major ISP ddos across a distributed servers (and any of these queried work). 01:04:16 If the records don't agree or are obsolete, well, the miners always follow the "longest" chain 01:04:48 there isn't need for any code in place, that's the default behavior. the checkpointing just pins a specific height to a given id 01:05:22 it doesn't make the blocks appear or manually move the nodes forward, the nodes are always moving forward. it sets the "rear" 01:05:28 Perhaps the biggest issue with the rolling DNS checkpoint idea, is that creates an environment where the likelihood is higher (than pure longest chain rule) of prolonged chain splits. Although it is fairly unlikely that this would be an issue in practice, if the balance of hashrate following checkpoints was say about 60% and 4 [... too long, see https://mrelay.p2pool.observer/e/7OGDrLMKWFNXOUpC ] 01:05:50 and as for > If the checkpointing idea is released and adopted, can we be sure that it won't be used longer than necessary when other solutions are ready or that it won't be used for other purposes? 01:06:14 that's up to monero community to address (plus the previously discussed writing about what will be done with them) 01:07:01 the other alternative as it is now, before any long term hardfork, is that people can do worse on the chain and get invalidated decoys with the already discussed issues 01:07:30 How many different servers / signing keys would there be? Also what does DNSSEC mean? And tevador's proposal means that a minimum of 2/3rds vote is needed for a checkpoint to be valid? > 1) the keys are individual and they are DNSSEC, that's also where tevador's 2/3rds +1 % (supermajority two-thirds rule) 01:07:45 and remember - checkpoints are not a one way door. If deployment of them ends up with higher issues than expected due to network effect, they can just stop being issued or removed. 01:07:59 The suggestion is to increase from 4 -> 7 01:08:06 and 50%+1 to 2/3rd +1 01:08:17 right now 3/4 need to agree to have a checkpoint valid 01:08:46 if more are added and threshold is set, it'd be 5/7 that need to agree 01:09:21 each checkpointing subdomain has a set of signing keys 01:09:24 https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions 01:09:49 it authenticates DNS records 01:10:11 these records can be signed offline, then pushed to DNS secondary servers that can serve but not sign new records 01:11:03 As an example I wrote a simple DNS + DNSSEC server that serves exactly the TXT records needed, signed, and allows DNS Zone transfers for secondary DNS servers to then provide https://git.gammaspectra.live/P2Pool/monero-highway#cmd-dns-checkpoints 01:11:20 https://dnsviz.net/d/checkpoints.gammaspectra.live/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk= 01:11:43 This automatically replicates right now across Hurricane Electric's DNS secondaries and 1984.hosting DNS secondaries 01:12:14 And how deep are the proposed checkpoints again? I still am of the opinion that the closer to 10 we are the better. As chain splits are more likely if the depth is to close to the tip. Especially if Qubic and CFB go maniac mode and want to cause chaos. I think it is already the case that CFB is hesistant to reorg deeper than 10, so that seems like the most reasonable number 01:13:50 my suggestion is depth of two "from tip", to account for around 5 previous records missing, due to TTL 01:14:01 If checkpoints are less than 5 blocks deep from the tip, then CFB could try to reorg deeper than that causing chain splits. I mean he could do that still with 10 block checkpoint, but it is harder and I think even he has limits to how much chaos he wants to create 01:14:10 that'd get it around the 10 mark with a sliding window of 10 checkpoints 01:14:22 > If checkpoints are less than 5 blocks deep from the tip, then CFB could try to reorg deeper than that causing chain splits. 01:14:28 I don't follow that point haha 01:14:32 if he can do 5 he can do 10 01:14:44 or 20, like, on demand 01:14:59 DNS checkpoints aren't instant 01:15:28 assume they can get to good clients within a few seconds, but many users DNS servers will lag behind around 5-7 minutes 01:16:06 you need to keep this into account to set the checkpoints with the point that they will be there when the clients receive them, in a workable way, for the purpose needed 01:16:27 if you set a checkpoint at 9 and the client receives it when we are 20 deep, they hold no weight except to make more splits 01:17:05 the closer to tip, it eliminates the ability to make splits, but you also want to leave the tip to behave naturally via highest work 01:18:04 Ok, I think I better understand now. You're saying that there are lags in people receiving all the checkpointed info so in practice a 2 depth checkpoint only enforces like a 10 block finality or something like that 01:19:00 you want to have a margin of error to account that clients would need 5/7 of the DNS domains matching some of the records 01:19:08 DataHoarder: Wouldn't it be easier for splits to occur though? As CFB just needs to reorg one block deeper than the checkpoint. But I might misunderstand the degree of incremental difficulty for him to reorg one block deeper 01:19:25 that is a reorg, which reorgs back 01:19:33 the point is to make 10+ infeasible 01:19:44 to prevent transaction invalidation and double spend 01:20:10 you can ensure the core players have a good setup, but everyone else that opts in also needs to receive good data in a timely manner even if lagging behind 01:20:36 the 10-block range is within the confirmation window, more and that's where the issues appear @fr33_yourself 01:20:38 I agree that to the extent that most mining hash follows the checkpoints then it would make 10+ double spend and reorgs infeasible 01:21:13 depth set to two, qubic tries to reorg below that, but it'd make no difference if it was a checkpoint or not. they can already do that 01:21:34 but extending this to 10+ is not something that is desired, and the point of the checkpoints 01:22:49 Correct. The "honest" mining pool admins need to be able to receive the data quickly from the signing servers. > you can ensure the core players have a good setup, but everyone else that opts in also needs to receive good data in a timely manner even if lagging behind 01:23:08 from measurements it's like 15s latency when you query things properly :) 01:23:58 depending on DNS setup as well (and we'd want some variety) that can add some as well 01:24:42 some DNS servers from ISPs can and will enforce 5m TTL 01:29:00 > depth set to two, qubic tries to reorg below that, but it'd make no difference if it was a checkpoint or not. they can already do that 01:29:00 Yes, but isn't it a possibility that Qubic could do a fairly deep reorg (via selfish mining) after checkpoints are enabled. And in this hypothetical scenario they could persist mining and building on their deep reorg chain, and possibly with some honest miners (if they don't follow the check pointed chain, but just follow stan [... too long, see https://mrelay.p2pool.observer/e/hvfZrLMKZmFrOEhp ] 01:30:33 In the current setup with selfish mining the reorg passes through which is disruptive, but after Qubics reorgs are "released" the network remains on a single chain. 01:31:30 see that'd invalidate some transactions but then the chain would come back 01:31:40 where the current situation is that they'd never come back 01:31:56 and it'd allow double spending, invalidation as well 01:32:45 if their point is "profit" their coins there would be useless 01:33:12 How would the checkpointing situation allow the chain to "come back"? As long as there are two meaningfully sized groups of hashrate building on different chains then this would cause a currency split if one of two groups doesn't defect in a shortperiod of time. > see that'd invalidate some transactions but then the chain would come back 01:33:38 > As long as there are two meaningfully sized groups of hashrate building on different chains then this would cause a currency split if one of two groups doesn't defect in a shortperiod of time. 01:33:38 The one that has the monetary majority 01:34:24 this includes hashpower and some specific merchants 01:35:32 > if their point is "profit" their coins there would be useless 01:35:32 Maybe, but isn't this contingent on exchanges, merchants and majority of the ecosystem configuring their nodes such that they follow the checkpoints (not just the miners following the checkpoints, but even exchanges etc). Because otherwise if some exchanges nodes or merchants nodes are configured to simply follow longest chain [... too long, see https://mrelay.p2pool.observer/e/ovDxrLMKWm1SSHEt ] 01:35:56 note DNS checkpoints were originally released to explicitly address that situation of a "split" due to consensus issues coming from a bug 01:36:18 nodes would opt-in as needed 01:36:29 Yes, I agree that after the "currency split". Then the more valuable currency and it's accompanying chain will be followed / mined > The one that has the monetary majority 01:36:31 also - note that the current attacker being qubic does not mine 24/7 01:38:18 also read up https://github.com/monero-project/monero/issues/10064 01:38:23 DataHoarder: What does this point mean? Why is this relevant to our current discussion? Ohhhh I see what you mean. It would be difficult for them to persistently continue building on their "naughty reorg chain" because they only mine in marathons. So in the event of a chainsplit their chain would die unless CFB overrules their current decentralized AI B.S. and starts mining Monero full time 01:38:38 this is where the 2/3rds was mentioned in the comments 01:38:56 correct, fr33_yourself. 01:39:27 checkpoints also prevent a generally covert attacker from implementing one-off attacks 01:40:26 You mostly mean merchants that do meaningful transaction volume, exchanges, and proportion of hashpower distributed between the two competing split chains. Whichever has "more" of those aspects would end up winning the split. Pretty much like what happened with BTC and BCH > this includes hashpower and some specific merchants 01:41:03 Except for one side they know which is the canonical chain 01:41:25 DataHoarder: Yep, because if they can't persistently build on their reorg chain, then it just gets orphaned off. It's like a game of stamina. 01:41:39 and the other would temporarily be elsewhere, then flip. it not being permanent matters, plus users on the wrong side can still opt-in to checkpoints or at least see the warnings 01:42:04 it is more valuable to do short selfish attacks or literally just mine 01:42:23 they are orphaning others atm but their implementation is not strictly giving higher profits 01:44:37 DataHoarder: How would it still be valuable to do short selfish mining attacks if the checkpoint depth is 2 blocks? Wouldn't that make short reorgs impossible? Unless it is like exactly 1 or 2 blocks deep. Or you mean even with checkpointed depth of 2, Qubic could still possibly pass a 3 block depth reorg due to latency? 01:45:12 depth of 2 is, if blocks 100 101 102 exist, you are checkpointing 100 01:45:27 they could still make their own version of 101, 102, and 103 and publish these 01:45:44 ending up with 2-1 orphaned blocks depending how many they do 01:46:02 they could also do 102, 103 and orphan 102 only 01:46:23 say clients have an older one 01:46:33 reorg could happen there, but it's still within conf window 01:46:40 then as blocks get built it reorgs back 01:46:52 all of that can happen within the 10-block interval and it's all ok 01:47:43 the point being that blocks coming out of the 10-conf window should be well checkpointed by overlapping height/time intervals to account for lucky chances or network delays on DNS records 01:48:44 I see where you guys are coming from and you are making good points. It is a powerful practical tool, but I guess the philosophical angle is still a bit murky since the rolling dns checkpoints still introduce a centralized point of trust. But in practice it perhaps it isn't such a big deal because all honest miners and network [... too long, see https://mrelay.p2pool.observer/e/oZmirbMKX2hSdmdT ] 01:49:06 what was mentioned on previous MRL meeting as well was to start building up documentation around the purpose itself and what activation window we are talking about for the bandaid 01:49:20 > the philosophical angle is still a bit murky since the rolling dns checkpoints still introduce a centralized point of trust 01:49:26 yeah, read on https://github.com/monero-project/monero/issues/10064 and that's a major point 01:50:04 Roger, I will read it now. I appreciate your points and explanations. 01:51:16 good testing has been done on testnet to find pain points and issues to bring that up, and others that need fixing on monero to get a better system for it, but these are not consensus breaking changes (they are just in the DNS checkpoints subsystem) 02:02:29 The most important point is rolling dns checkpointing is temporary bandaid (and can be switched off) until more permanent solution is ready, i lost track if PoP will be implemented alongside it? 02:07:55 yeah. they must never become a permanent solution on their own. their purpose is for emergency situations as originally deployed, for consensus split resolution, so this is stretching usage a bit already 02:08:35 lightly adapting them to fit this better as well, but when other solutions come in, they should be gone quick 02:14:57 @fr33_yourself: At a depth of 3 or more 02:17:04 For 10 years, the network has essentially never disagreed / reorged beyond 3 blocks. Any discrepency that large is likely to be a dishonest attempt to have an unfair advantage (selfish mining or otherwise mining while disconnected from the rest of network) 02:17:39 the checkpoints should be following the chain post-any honest reorgs 02:25:30 DNS checkpointing only really helps against deep reorgs (9+), but it doesn’t address selfish mining. Many miners, myself included, are noticing reduced rewards it feels like our work is being undercut, and over time that could make small/medium-scale mining harder to sustain. 02:25:30 I’m curious: aside from DNS checkpointing, are there any other solutions currently being discussed to mitigate selfish mining on Monero? 02:27:52 > it doesn’t address selfish mining 02:27:53 if applied on those depths, it reduces their ability to do long chains and "wait" for the chain to catch up. it limits them to short lucky chains, and their work resets every couple of heights 02:28:11 they can't count on monero getting unlucky and them being lucky anymore 02:28:47 so their risk their chain gets orphaned is way higher, which makes it less profitable for them to use that strategy as optimally (or not really for them) as they have been doing 02:29:06 but yeah, it is still viable but with reduced orphan depths 02:29:55 note they also are getting quite orphaned by monero itself https://qubic-snooper.p2pool.observer/tree/ :) 02:41:57 @rucknium:monero.social can you edit https://github.com/monero-project/meta/issues/1263#issuecomment-3255876843 to have the logs in a "code" block via ``````? I think github is trying to sanitize html tags so only users with invalid html names get shown over the bridge :D