00:14:48 Testing some selfish mining now, but the main chain keeps getting ahead of me so im losing my work :P 00:16:25 Also building binary with tev's checkpoint, and will attempt a deep reorg theren 00:17:47

how do we do this in s decentralized way? 00:18:05

what is the core team gets compromised or the keys for checkpointing is compromised 00:18:13

what if 00:19:21 the sky is falling 00:23:17 ofrnxmr: I see your orphans: https://testnetnode1.moneroconsensus.info/ 00:23:48 I broadcast 1 chain so far 00:24:07 going for a deeper one 00:24:45 Lets go.. 8 or 9 blocks this time 00:25:23 Changing these domains, right? https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/checkpoints/checkpoints.cpp#L320-L324 00:26:11 Yeah 00:26:32 Im going to test locally first before attacking the public testnet 00:28:14 To really test it we would want to mine a longer chain starting just below 2813706. Do you agree? 00:29:11 We would want to test it with an active script updating the DNS records, but for now it can be tested with the static height. If one of us has enough hashpower 00:29:27 Yeah, going to pop my local down to like 715, then bring attacking chain to 705 and then attempt to reorg the 715 daemon 00:30:21 Just to see if it works at all :P 00:40:27 Just did a 9 block on the tip 00:40:34 Going to try the checkpoints now 00:40:57 My selfish method does work, and i imagine is what qubic is doing 00:42:04 Its hard to keep up with main chain though, so they must be losing a lot of blocks while trying to get lucky enough to get and stay ahead 00:42:34 When i tried at 500h/s, i was lost the 70% of my blocks .. 00:43:13 Probably just one thread is mining on testnet. Net hash is 620 H/s. 00:49:55 Im testing the dns checkpoints now.. lets see if this works 00:55:59 Well, that wasnt successful. Checking to see why not. Maybe it didnt download the checkpoints and i need to decrease the timer, or maybe need to enable testnet checkpoints 00:57:24 tev said ^ 00:57:25 > It seems that testnet checkpoints cannot be enabled anyways without changing the code. https://github.com/monero-project/monero/blob/master/src/cryptonote_core/cryptonote_core.cpp#L267 00:58:47 So, change that line, too? Probably can just remove `m_nettype != MAINNET || ` 00:58:55 Yeah, duh 00:59:31 Round 2 in a sec 01:00:57 On some of my testnet nodes I got `E Failed to parse block from blob` a lot on default log level. 01:02:24 From my 9 block reorg? 01:03:11 happened right after the 9 block re-org 01:03:34 happened on two of the three nodes I checked. 01:05:13 I think the dns chdckpoinfs need to have every checkpoint in them 01:06:08 They need to agree with the hardcoded checkpoints? 01:06:10 ``` 01:06:11 2025-08-18 01:04:16.245 W CHECKPOINT FAILED FOR HEIGHT 233000. EXPECTED HASH: <4f69bec2af6c0852412bdd10c19e6af10c8d738fe2618b5511a98efd03ab477e>, FETCHED HASH: <92eb8c2a1cdcb583365894f9a0be292a129fc2817abdae4bd61c95f0d3be4800 01:06:13 ``` 01:06:15 My node is trying to roll way back 01:06:53 Let me remove the checkpoints for testnet except for the new one 01:08:23 Actually/ i dont even know where thisb 233000 comes from 01:10:54 I see neither that height nor that hash in the code. Maybe the DNS record is being incorrectly parsed. 01:13:10 Wait, it's in a few GitHub issues: https://github.com/monero-project/monero/issues/3845 01:13:53 Yes, it's looking at the mainnet checkpoint sfrom DNS records: https://docs.getmonero.org/infrastructure/monero-pulse/#moneropulse-is-dns-based 01:15:05 `cryptonote_core.cpp` probably needs more edits to get it to look at the testnet domains when it's running testnet. 01:22:08 ` // if anything fishy happened getting new checkpoints, bring down the house` lolol 01:24:21 Monero code archaeology is always fun. 01:26:51 I guess i can just, for now, replace mainnet url 01:29:07 ``` 01:29:07 if (!tools::dns_utils::load_txt_records_from_dns(records, nettype == TESTNET ? testnet_dns_urls : nettype == STAGENET ? stagenet_dns_urls : dns_urls)) 01:29:09 return true; // why true ? 01:29:11 ``` 01:29:13 this is probably broken 01:38:49 Idk if it needs more than 1 source, but i thinknso 01:39:25 vtnerd can you try to add the txt entry to yours again 01:42:35 Rightl. I get `status: SERVFAIL` when I try `dig -t txt checkpoints.vtnerd.com +dnssec` 01:44:47 To what? 01:45:15 to the same, its not showing any entries :P 01:46:56 Oh dnnsec maybe, damnit 01:52:31 Yeah it's name cheap, didn't fetch for higher tier. Let me switch to checkpoints.leeclagett.com at easydns 01:55:20 All set try now 02:27:59 Hm. It doesnt try to rollback 02:29:30 ``` 02:29:31 2025-08-18 02:25:29.971 I Using public DNS server(s): 9.9.9.9 (TCP) 02:29:33 2025-08-18 02:25:29.975 I adding trust anchor: . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D 02:29:35 2025-08-18 02:25:29.975 I adding trust anchor: . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 02:29:37 2025-08-18 02:25:29.975 D Performing DNSSEC TXT record query for checkpoints.xmrdb.com 02:29:39 2025-08-18 02:25:29.976 D Performing DNSSEC TXT record query for checkpoints.leeclagett.com 02:29:41 2025-08-18 02:25:30.001 I Found TXT record for checkpoints.xmrdb.com 02:29:43 2025-08-18 02:25:30.001 I Found TXT record for checkpoints.leeclagett.com 02:29:45 2025-08-18 02:25:30.001 D Found 2/2 matching records from 2 valid records 02:29:47 2025-08-18 02:25:30.001 D DB map size: 29842946048 02:29:49 2025-08-18 02:25:30.002 D Space used: 8370765824 02:29:51 Hi ofrnxmr how is the dns checkpoint test going? 02:33:27 Isn't that the goal? 02:34:01 Yeah, i reorged the checkpointed block. Goal is for the checkpoint to rollback the chain 02:36:06 Its not rolling back riggt now though. It should say something like this ^ 02:38:26 Don't listen to BawdyAnarchist, who is another midwit flooding the discussion with noise. I remember him frequently posting in r/xmrtrader with his nonsensical ramblings and complete misunderstanding of economics. 02:40:49 1 sec, let me try again 02:43:42 @vtnerd, it worked 02:44:11 Rolled back to block *704 03:29:42 Using public DNS server(s): 9.9.9.9 (TCP) 03:29:43 Do we have to rely on centralized DNS servers like Quad9 or Cloudflare for checkpointing? 03:43:36 those servers query monero domains directly 03:43:59 you can setup your own recursive resolver to fetch these directly from monero pulse DNS servers, whatever they are 03:44:34 👍️ 04:08:17 qubic includes at maximum 19 transactions in their blocks, be it selfish or not 04:34:24

how many of these checkpoints can we have before it starts slowing down the dns infrastructure 04:57:25 you should be able to remove redundant temporary ones, once you have moved further up the chain to the next checkpoints 05:14:37 Qubic is going after dogecoin next. https://x.com/c___f___b/status/1957139742388298154 05:18:01 Thoughts? 06:07:46 it will take time for them to develop doge mining, meanwhile they'll mine monero 06:08:58 Yes, but it seems like they’re moving on and they squeezed as much as they could from monero and are going to dogecoin to pump their coin up again. 06:09:44 zcash rigged it so it becomes Doge 06:10:21 Yep that poll was never actually a choice and CFB was hinting at mining dogecoin for weeks now, but what did you actually expect? 06:14:41 Shitcoins like Qubic require hype to stay alive just like nfts. The minute people feel like the coin is losing value or is stagnating. it usually begins a big sell off. 06:20:25 "develop dodge mining" -> buy older inefficent asic miners for cheap 06:21:00 this is also possible for bitcorn btw 06:30:11 It would take more asics than on the current market to have any chance of a 51% attack on Bitcoin. So no it’s not really possible against bitcoin 06:36:12 Do we know that? How much did bitmain actually make & sell? also that is not the case if bitcoin dips a bit and hashrate falls. plus trailing edge foundry prices will keep falling. it just becomes easier and easier to pull this off as we keep moving along. Only counteraction is bitcoin price going up for ever. but that is not a law 06:37:17 and again: we dont know how miners act in this type of siutation: if a large enough number decides to sell their miners the network is shut down until a whale / the community outbids the attacker 06:38:01 and again: we dont know how miners act in this type of situation: if a large enough number decides to sell their miners the network is shut down until a whale / the community outbids the attacker 06:43:01 Bitcoin has a market cap bigger than Google and Apple. It’s just infeasible for somebody like CFB to go after bitcoin. 06:45:06 its just 10 billion to attack. if you start sizing into miners and people recognize they might jack up the prices or people panic sell them and the price drops 06:46:13 etherum is more expensive to attack than bitcoin. there is literature on that look it up 06:47:56 Yeah bitcoin and ethereum are pretty much the 2 safest crypto against 51% just because of how big they actually are. You really think if Qubic said they’re going to attack Bitcoin anybody other than delusional qubic people would take it seriously? 06:51:28 both things can be true: 1. qubic people are delulu and they cant do shit. 2. bitcoin is not as expensive to turn off as people think it is. 06:53:25 It would take a serious actor like a well developed country like the US to realistically have a chance to do a 51% against those two. 06:56:23 in the case of etherum no. there is no chance. Because they can slash the attacker stake until the attacker has to give up. In the case of bitcoin if the protocol is not changed the US could command the fabs they have access to produce asics. So in this case the US could win. 06:58:39 Question is the US straight up doesn’t have any real incentive to actually take down bitcoin in the first place. Bitcoin is easier to track than fiat currency. 06:59:51 A more interesting example would be: China wants to teach the US a lesson after it decides on building a BTC reserve. Can they with their limited access to trailing edge fabs, out bid the US? again it is not about stealing funds it is about denial of service. Whoever has more access to ASICs + energy can shut down the network. 07:52:07 spirobel please be diagnosed, spending 30 minutes talking to yourself is not sane. 09:24:28 2025-08-18 04:56:20.158 W There were 24 blocks in the last 20 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network or under attack, or your computer's time is off. Or it could be just sheer bad luck. 09:24:33 what does this mean? 09:25:15 printed from my monerod node 09:29:24 It literally spells it out for you 09:30:30 It doesn’t seem to be a large attack, because only 1 block has been orphaned so far in the past 24 hours 09:33:58 it's no attack. "there might be large hash rate changes" "Or it could be just sheer bad luck." 09:34:04 that spells it out 10:11:28 guys my computer is saying is saying to turn off and because its 150°C and there is fire all around the case what does that mean 10:46:45 turn it off and on again 10:47:43 it's called click, click, block/ignore user, click X. carry on about your day, kitty cat. 10:48:29 you clutter the channel more by calling them out than simply ignoring and moving on. sooner or later they'll stfu when not getting the attention they're looking for. very simple. 10:48:40 or move to Antarctica 11:24:08 new blocks mined by qubic shows they are no longer merge mining tari https://p2pool.io/explorer/block/13238f88dc96252e6b7d0522ada6bc831fbb9eca7e43c764383a39b7e5454a3e 11:27:53 lordx3nu:matrix.org any updates about the hashrate rental? 11:28:54 hopefully that rental lands on p2pool if possible :D 11:31:00 <17lifers:matrix.org> no 11:31:05 <17lifers:matrix.org> put that rental towards me 11:31:06 <17lifers:matrix.org> :3 11:32:32 Total amount donated was almost 19 xmr last I checked 11:34:19 Unfortunately I could not get p2pool to work (i was also uncomfortable broadcasting my IP) so I am using monero ocean. I've used that in the past and don't want funds to go to waste. 11:35:25 I have 24 MH running for the next 27 hours and still have more than half of the funds to apply in short term rentals in case of reorgs. 11:38:11 and if you get any, dump it into renting more, infinite profit :) 11:40:36 Yeah I will. I don't know how much revenue I'd get for only one day of mining. 11:40:46 <17lifers:matrix.org> mine to unmineable pool 11:40:50 <17lifers:matrix.org> so you get more btc to spend on rentals 11:40:53 <17lifers:matrix.org> infinite money glitch 11:42:33 just fyi, I love MO, but they aren't selling or distributing the XTM again since TradeOgre went down 11:42:53 they will eventually, but waiting on a new exchange I guess 11:44:12 qubic pools have been diverging from tip a few times, they might be selfish mining again 11:44:49 <17lifers:matrix.org> oh, how selfish of them 11:44:50 <17lifers:matrix.org> :c 11:48:44 I'll be checking my phone. If there is an urgent need for hash send me a notification. 11:50:53 they will be starting the marathon for 24h at 12:00 UTC, or in 10 minutes 12:14:59 MoneroOcean is fine too, if you can't set up p2pool easily for the rental 12:27:47 tevador while modeling, I noticed that your requirement 12:27:49 "Then remember to model a scenario when a new node joins the network and is presented with the attacker's chain that has a much higher cumulative difficulty." 12:27:51 shifts the attack vector to an eclipse attack.. not entirely sure that is a fair concern. sorry, all, just wanted to drop this here, not to argue about it 12:31:33 (can't DM him, since he's behind the bridge) 12:34:21 waaaa rottenwheel is pro cancel culture now? a bit like a byzantine node with a protocol bug. everyone moves to peace and harmony he flips back to cancel mode. 🤖 13:31:59 Qubic is only getting 1.50gh/s right now 14:33:35 venture:monero.social: To save you some work, here is a math proof that no consensus algorithm that relies only on PoW can be secure from an adversary with >50% of the hashrate (hr). Proof by contradiction. 14:33:35 Let there be such a consensus algorithm. Let H be the honest actors and A the attacker. If hr(A) > hr(H), there must be some strategy S that H can employ for their chain to always win. Then let hr(A) < hr(H) and let A employ strategy S. The attacker wins. 14:42:22 There's no zugzwang in blockchain, so any winning strategy can be stolen 🙂 15:07:20 If there are strategies that H can use but not A, this is not a contradiction. While this may seem pedantic, it's how you find stuff, by exploring new parts of the problem space (I am not implying there is stuff to be found here, just saying the proof is no proof). 15:08:23 A trivial example of such a stretegy is "block has to be signed by the centralized authority" :P 15:12:57 "Block has to be signed by a centralized authority" is outside of the scope of PoW. 15:13:38 So I clam that it's a valid proof by contradiction, provided that the only thing used for consensus is hashrate. 15:14:08 *claim 16:25:21 qubic seems to be delaying blocks for a bit again, selfish started? 17:42:23 Today their hashrate is fluctuating around 30%, not really enough for profitable selfish mining. 17:48:15 their pools have also gone down a few times so it has been hard to look via pools how they are mining consistently 17:48:47 hard to say if it's DDoS or usual pool changes they do 17:48:52 Theyd probably be more profitable if they honest-mined imo. Their POC selfish mining seems to be primarily about PR to try to obtain more hashrate 17:48:56 competent operators, you know 17:49:15 and from tracking ofrnxmr they lose way more blocks themselves than they orphan 17:49:17 it is indeed PR 17:50:29 they seem to not be selfish mining at the moment, their blocks aren't really delayed from what pools are mining 18:01:56 tevador: I agree with moneromoo , your prove doesn't account for PoW strategies that can differentiate between H and A. 18:01:57 consider what A is doing, he is rewriting history, working in the past and under pure PoW will catch up with H. But just the fact that there is a delay (more confirmations are safer than fewer), means PoW / cumulative difficulty can differentiate. 18:01:59 I'm going to repeat myself now below, but I won't argue about it anylonger and attempt to show that in a simulation. Unfortunately, I'm not verse in enough in proof writing, to formalize that. It would need to include the concept of entropy, time and work I guess. 18:02:01 "it's maybe easier to see when you think of effort or hashrate as thermodynamic work, general flow of entropy. the adversary mines need to "mine" backwards that direction since every time the hash-coin-toss fails for him, he needs to attempt again by finding a whole new block hash. and that will happen 50% of the time. he will be able to succeed in the other half, hence slashing t he expected payout of the victim in half (from 40% to 20%)" 18:02:05 please remember, the effort I highlighted will not contribute to cumulative difficulty 18:04:12 **attempt again by finding a whole new block hash** <-- highlighted PoW effort 18:05:26 *"current PoW" rather, not sure but I think the modification would still count as "pure PoW" 18:07:36 You can't differentiate between A and H solely with hashes and timestamps. Anything you do to make the minority's chain win can be replicated by the attacker. Remember that block arrival times is not something that can be used for consensus. That information is lost for future blockchain verifiers. 18:08:59 Your goal is: Presented with two competing chains A and H, give me (a new node joining your network) a definitive set of rules which chain to select, which always selects H no matter what. 18:10:16 Checkpoints, "asking a friend" etc. don't count. 18:10:59 I agree a lot more with that ("solely with hashes and timestamps"). My point (I was flippant, sorry) is that solutions are often found by slightly relaxing inputs or constraints, and equating "PoW" with this more restricted set of inputs above may discourage exploration of these slightly differnt problem spaces. Of course, it might be wasted time if there's really nothing to be found, I 18:11:05 was just making the general point, if too flippantly. 18:13:08 i understand moneromooo 18:13:09 it's just sometimes you need to see / make the experiment yourself and fail for yourself. it's like with the hand on the stove. learning by experience thing 18:15:16 checkpoints, "asking for a friend" needs to be there at inception in the form of trusted seed nodes. I don't cater for eclipse attacks. 18:15:17 the boat has not sunken yet, after that A and H should be seen more atomically, ie, rewrite-attempts to the main chain 18:16:08 PoW is essentially just hashes and timestamps. Consensus must anchor on some scarce resource to prevent sybil attacks. In this case the resource is hashing power. Yes, you can add other resources to the mix (staked coins, disk space etc.), but I don't think that's PoW anymore. 18:18:39 it anchors to scarce resource OVER time. 18:18:41 an attacking entity can always be detected red-handed when blocks are overriden. (aka going back in time, so he needs extra time to catch up, which can be leveraged) 18:18:43 a 55% major player is not by himself existing alone malicious. 18:19:32 A new node joining the network has no knowledge about any block overriding. 18:20:09 "checkpoints, "asking for a friend" needs to be there at inception in the form of trusted seed nodes. I don't cater for eclipse attacks. " 18:20:37 And yes, the genesis block is technically a checkpoint if you want to be pedantic. But you can assume that both A and H anchor at the latest hardcoded checkpoint. 18:21:29 It's not an eclipse attack. You connect to several nodes and download two different chains. Which one is the correct one? 18:24:53 I don't think we should see H and A that distinct. they are acting in unison until the A wants to override a particular block. A doesn't exist without H, nothing to attack. 18:24:53 i doubt there will be multiple branches 18:25:14 at inception / checkpoint time 18:28:52 I'm afraid your doubt is not a sufficiently well defined consensus mechanism. 18:29:32 The attacker will simply spawn a fake chain from the latest checkpoint, with valid PoW hashes and fake timestamps. Your goal is to somehow detect the fake chain. 18:29:43 that is true. trusted seed nodes might be needed for inception, IBD/sync 18:31:46 "Trusted" is not something a decentralized consensus mechanism should need. 18:33:07 ok. I guess then we can bury it, I think. 18:33:15 Monero has no such thing currently (apart from the emergency DNS checkpoints). 18:33:24 ok, then we can bury it, I think. 18:33:43 Update on my research. Depth Penalty is almost certainly the way to go. Still based on monotonic time elapsed (not depth of reorg), but we avoid having to keep track of blockweight adjustments indefinitely into the past. An asymptote fails to maintain the established-history time-weight advantage, because an attacker eventually gains equivalent time-weighting for their blocks, at the level of the asymptote. Meaning we'd have to continuously adjust the weight of each block, basically forever. 18:33:45 Penalizing latecomers is mathematically equivalent, and only has to be invoked when there's a competition. It's important though, that penalization is calculated per-block over the contested-chain period, not just the monotonic differential from the common ancestor to the competing head. In the case of a fully silent attacker it makes not difference (they're forced to pay in > 51% hashrate to overcome the penalty). 18:33:49 sorry, edited 18:33:58 But there's an edge case we must address ... *sniping*. An attacker builds up an advantage (say Qubic builds a 4 block temporary lead through natural variance), and keeps it hidden. H0 is the common ancestor, and H1 attempts to build on it. The attacker, knowing they'll begin incurring a time penalty, releases A1 the moment they see H1. They continue doing this until their tempora ry lead is about to end; at the last moment, releasing their final hidden block -> thus re-organizing the chain. So a modified selfish mining strategy. 18:34:01 What we still gain: A) Fully silent reorgs require significantly more than 51% to succeed. B) Modified selfish mining attacks quickly become transparently, in real time. Users can take protective actions. 18:34:10 I believe that even this modified selfish attack can be mitigated by comparing monotonic differentials of the attacker's block-header time, between blocks. Attackers must include a timestamp in the header, but they cant know exactly when they'll need to match H1, H2, ... Hx block-for-block. Thus, an additional penalty can be applied by nodes, based on mismatches in the time differ ential between block arrival, and differentials between the block headers. 18:34:13 I think there's a high probability that such a schema is devastating to both selfish mining, and mid/long chain silent reorgs, even with outsized portions of hashpower. 18:37:02 You’re basically re-stating the selfish-mining paper as I can tell 18:37:07 needs clock sync BFT - not trivial. 18:38:04 I dont think it does. We're using monotonic time. Simple differentials, as opposed to UTC syncronization. This would work even if your NTP was off 18:39:10 The only "fuzz factor" happens due to block header propagation delays. 18:39:20 you mean me or Bawdy? if you are referring to the mitigation section then yes, they had the same idea about choosing deterministically. 18:39:39 instead of first-seen 18:42:31 if you know a protocol to agree on universal time, I'd like to know more about it 18:42:46 oh, but they had a minor tweak in that only the miner software would be modified, the bitcoin client would have remained untouched. 18:42:47 and I do agree with you here, vtnerd, that this might be leaving the attacker with more blocks than before. 18:42:49