00:05:55 Ill speedmine and try to get ahead kf main chain 00:05:59 Looks like if my node knows about an alt chain, it wont switch to that alt chain 00:06:01 Trying to pop my failed reorg blocks and reconnect would instantly ban the "honest" node. Had to restart the daemon to get my selfish node to reconnect 00:06:03 Do your nodes see anything? 00:06:05 Or maybe they banned me? 00:06:07 I don't see any change, but I don't see any ban statements, either. Try to clear all of your bans. 00:06:09 I cleared my bans 00:06:11 It tried to connect to peers but disconnects immediately 00:06:13 Restarted the node 00:06:15 try `bans` in your monerod, is 86.something in there? 00:06:17 all four of my nodes with open ports have no bans. 00:06:19 https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/XgfLqvSEKYzhbWeyvXidzgfS 00:06:25 Damn, idk why mine is failing to connect 00:06:42 try to connect as priority node to 185.141.216.147 with normal testnet p2pool port 00:07:26 Oh i have out peers now 00:07:39 Height 522 00:08:04 I'm at 524 00:10:17 How abiut now 00:10:36 Mine shows youre at 530 now 00:11:05 yes, 530 00:11:19 Did you get reorged? 00:11:33 Hm looks like i got reorged 00:11:40 Well, at least my malicious nodes did 00:11:41 argh 00:12:57 Maybe your dns checkpoints were being pulled from the new reorged chain? 00:13:10 And mine followed the latest checkpoint? 00:13:37 Oh. Yeah. 00:14:00 I need the raw patch on the node that pushes up the DNS checkpoints. 00:15:46 this should do it 00:31:52 New binary built on the DNS checkpoint node. Creating another attacking chain. 00:40:00 running 2 nodes, one connected to your node listed above, and one just whatever the p2p state is. fwiw I’m not a fan of these auto-checkpoints, but Im curious on these tests at least 00:42:13 oh and both mine are not running ofrn patch, so they both should get forked off, just wondering how long before the other node even realizes 00:45:04 Hopefully theyd get forked off, then get forked back 00:52:17 I don't follow why they would fork back - you mean because the alt chain stops being mined? 00:54:44 I just sent out the attacking chain. https://testnetnode4.moneroconsensus.info/ is patched with the checkpoints (and is the origin of the checkpoints). https://testnetnode3.moneroconsensus.info/ is unpatched. 00:55:14 Now I will attempt to mine on the old chain. 00:58:42 Saw both here basically instantly, guess it wasn't a surprise since everyone on testnet is running without checkpoints 00:59:47 On my patched node I see things like 00:59:47 ``` 00:59:49 2025-08-19 00:57:06.427 I Host xxx.xxx.xxx.xxx blocked. 00:59:51 2025-08-19 00:57:09.311 I [94.156.232.72:62085 INC] Sync data returned a new top block candidate: 2814554 -> 2814560 [Your node is 6 blocks (12.0 minutes) behind] 00:59:53 2025-08-19 00:57:09.311 I SYNCHRONIZATION started 00:59:55 ``` 01:00:34 `0(out)+1(in) connection` on the patched node 01:01:37 "old" chain has now overtaken the attacking chain. It's not spread throughout the network yet because of bans. 01:03:49 Yeah not seeing that on either of my nodes yet. The one with priority node for 185 isn't listing that as a connection either 01:03:52 Now seeing, on the patched node 01:03:53 ``` 01:03:55 2025-08-19 01:02:29.672 I [146.70.199.171:51596 INC] Sync data returned a new top block candidate: 2814569 -> 2814563 [Your node is 6 blocks (12.0 minutes) ahead] 01:03:57 2025-08-19 01:02:29.672 I SYNCHRONIZATION started 01:03:59 ``` 01:05:37 Just saw the swap back on the priority node first, then the other one about 25 seconds later 01:07:05 Actually it took some time for me to type so it's at 1:04:31 for the first reorg back and 1:04:53 for the other. I assume my connection to yours meant we had closer peers in common, etc 01:08:19 For the first reorg that is and the more similar peers 01:10:31 patched node is on 583 01:10:34 Which is the main chaib 01:13:15 Heckpointed chain is now at 582, hash 29f3bb 01:13:28 Did it ever switch? Should've never swapped if I understand your setup correctly 01:13:29 #Qubic defeated 01:14:43 My unpatched nodes all switched over the the checkpointed chain at about 01:04:30 01:15:22 Thats what my hashpointed node is on 01:15:51 and no big re-org noticed on your checkpointed node? 01:16:01 notices* 01:16:18 nope. Didnt even get the alt chain 01:16:32 Shows no alt chains 01:16:51 it did, however, ban various nodes 01:17:18 We likelt want to reduce the ban time for this offence 01:19:23 It seems like it worked as expected, except maybe the peer banning. Monero nodes just like to ban each other. 01:19:58 i need ti grep logs, but i think these are an offence ban of some sort 01:20:17 Like "node sent chain with diff history, dropping connection +ban" 01:21:28 Sounds like it worked as detected, but I just dunno. They could intentionally fork the coin (assuming hashrate was real, which is in flux afaik) and make people pick a side. Every node that doesn't enable DNS nodes defacto picks their side 01:21:52 *DNS checkpoints 01:23:00 I think nides that dont pick, should be reorged to the longest chain 01:23:16 That dont have dns* enabled 01:23:27 But my dns enabled node bans them 01:25:52 Yes that's what I'm saying, if they have the 51% hashrate, why not make people pick a side and who should manage xmr. A little wild of a theory, and I'm not sure what exchanges would do etc 01:28:05 yeah I was thinking we would probably need to announce this in advance and have it activate in the node after a certain timestamp, to give some time for people to update 01:28:16 Its like bch/btc but an actual hostile takeover at that point. If this was rolled out in a hard fork, as default on, then everyone would defacto pick core side at least, but now it's all so messy 01:28:20 Yes 01:28:34 or ig just not update DNS until the timestamp 01:29:21 I just pushed a reorg 01:31:06 Have a few nodes on my side 01:31:15 454e0 01:31:33 Its showing on https://testnetnode1.moneroconsensus.info/ 01:31:45 Now lets see if main chain can overtake 01:31:50 Yes both picked it up here too 01:33:54 dns checkpoints say only 1 of them matched, so didnt use the checkpoint 01:42:20 Aend another reorg 01:42:27 sent another reorg 01:43:41 Theres a problem with the dns txt entries 01:44:05 im only getting results from 1 of them 01:46:13 https://testnetnode1.moneroconsensus.info/ this is building on my attacking chain 01:48:15 On another note, randomx hashrate went up in price by 15-30% 02:16:56 Aha. I knew there was still a use for the tree view. Three chains with blocks at the same height, 2,814,585 03:26:18 I think im seeing these reorgs on the xmrchain testnet node alt_chain_info: 8 blocks long, from height 2814585 (59 deep), diff 1123132353962: 3f31df9b5c10249a619caf3de9eff5e1fe54260d2ddfbfa7cc3d961338f903cb 03:36:43 how often would this check be occuring? 03:40:03 :P first i orphaned the right branch db0d, then orphaned the left branch 0902 03:41:31 Ginger, does your "default" node match up with the tip here https://testnetnode1.moneroconsensus.info/ 03:41:58 I guess i can just check 06:36:22 I there a way to hide the fact that you’re running a monero node? That type of technology could be useful if the government goes after monero. I know you can run a node over tor, but what about a idea that the node hides the fact it’s a monero node and tricks the isp into thinking it’s like a bitcoin node or something like that. 06:36:35 Is there a way to hide the fact that you’re running a monero node? That type of technology could be useful if the government goes after monero. I know you can run a node over tor, but what about a idea that the node hides the fact it’s a monero node and tricks the isp into thinking it’s like a bitcoin node or something like that. 06:41:09 If you are in that situation, it might be better to not run a node at all. Hiding the fact that you are hiding a node, especially on clearnet, sounds like a difficult research problem. 06:41:20 Just use a remote node over Tor for payments. 06:42:01 That’s a very serious flaw though, because remote nodes can be malicious and can track monero transactions 06:42:26 That’s a very serious flaw though, because remote nodes can be malicious and can track monero transactions if they’re malicious 06:45:54 The danger of malicious nodes have been known for years and it’s recommended that you set up a node yourself. 07:04:19 You can use a VPN to run a node if needed, some of them even allow port forwarding. Else you can setup your own VPN server 07:11:20 Yes, but you have to do that every single time you want to connect to the node, so if you mess up and accidentally forgot to turn on your vpn then your isp will be able to see the monero node. 07:26:37 But I think only relying on a vpn for this is not ideal, because most vpns will turn over their logs on you if asked. All vpns say they don’t log, but most of the time it’s bs and they log you anyways. So you even have to be careful which vpn service you choose 07:32:04 Off topic 07:32:11 [#monero:monero.social](https://matrix.to/#/%23monero:monero.social) 07:33:42 How is it off topic? 07:34:44 ofrnxmr @ofrnxmr:xmr.mx: I'd say it's perfect for here, actually 07:35:42 barthman132: The latest work from Bitcoin has its protocol appear as pure entropy to any passive observer. The same techniques could be applied to Monero, but it'd be a distinct effort than the current work on TLS for P2P. 07:35:43 hiding a node presence is a combination of traffic obfuscation and resistance to Active probing 07:35:45 which is both hard 07:36:06 In comparison, IIRC, Tor tries to appear as an HTTPS connection. Not noise, but web traffic. 07:36:30 SyntheticBird: Easier if you don't accept incoming connections, but yeah. 07:37:15 You can still be MITMd, and while there are some ways to build a directory to prevent that, you still need an initial access to the directory 07:37:53 But passive adversaries is where you can make a lot of progress and do some really neat things, and it still *helps* for more powerful adversaries 07:38:18 I think boog did notable work on "contact lists'? 07:39:05 contact lists? 07:48:53 How many remaining tests are needed for FCMP 11:31:13 Think this proposal by zawy to make selfish mining less likely by nodes rejecting blocks based on timestamp has potential? Or is there a flaw that makes it not viable? 11:31:13 https://github.com/zawy12/difficulty-algorithms/issues/76#user-content-selfish 11:31:15 I found his simulation post here easier to understand. https://github.com/zawy12/difficulty-algorithms/issues/87 12:21:26 This is worth serious discussion 12:24:07 qubic hasnt found any blocks in a while 12:24:45 are they working on reorgs again 12:27:51 not from what I can see 12:27:59 The permitted time delay/ advance need to take into consideration: 12:28:01 1) Relativistic effects (The speed of light in fibre or to and from satellites 12:28:03 2) Switching times of Internet routers 12:28:05 3) The impact of censorship delays on network latency (For example the great firewall of China) 12:29:09 .other latency delays in the Internet 12:37:28 An interesting metric of minimal Internet latency is obtaining tickets to the annual Chaos Computer Congress in Germany from locations far away from Germany ; for example western Canada. 12:37:29 The tickets sell out in about 500ms, relativistic latency is of the order of 100 - 200 ms and human reaction times are of the order of 300 ms 12:38:24 Ticket bots are just on the server right next to them, in Germany 12:39:46 I have been successful from British Columbia in Western Canada 12:40:03 Manually 12:41:37 I estimate my handicap was about 200 ms 13:21:49 https://github.com/monero-project/research-lab/issues/140 13:22:28 I think the experiments caused a netsplit on testnet. My checkpointed node is waiting at height 2814600. `sync_info` says that 11 other peers are at 2814600 or 2814599 with me. And I have 28 peers banned for 12 more hours. 13:23:39 I also see this at the default log level, right after a re-org: 13:23:49 ``` 13:23:51 2025-08-19 01:43:24.363 W WARNING: no majority of DNS TXT records matched (only 1/2) 13:23:53 2025-08-19 01:46:03.982 W WARNING: no majority of DNS TXT records matched (only 1/2) 13:23:55 2025-08-19 01:52:45.455 W CHECKPOINT FAILED FOR HEIGHT 2814582. EXPECTED HASH: <29f3bb29d9949edfdbe7f49af2abf0e00c81680c16c00dbe47614cf14b6106ff>, FETCHED HASH: <6839d07d89b79d53264a7f199ce7a1315ce0b1aded7988cfd745f 13:23:57 79bdc392606> 13:23:59 2025-08-19 01:52:45.455 E Local blockchain failed to pass a checkpoint, rolling back! 13:24:01 2025-08-19 01:52:45.480 W Attempt to get hash from height 2814584 failed -- hash not in db 13:24:03 2025-08-19 01:52:45.480 E Error in handle_invoke_map: Attempt to get hash from height 2814584 failed -- hash not in db 13:24:05 ``` 13:30:34 Unless anyone objects, I will clear those bans on the node in 30 minutes, which will probably end the netsplit. 13:33:52 My attacking node, at 2814933, is not using checkpointing 13:34:44 The issue here, is that the main chain (the one mining at 600h/s) got forked onto my attacking chain. 13:37:48 I think the way to fix, is to get the checkpointed chain ahead of the attacked one 13:39:33 I think the checkpointing node is on the same main chain as the rest of the network 13:40:30 I can also just set the checkpoints to the majority network by pointing my checkpointing script at a different node. 13:43:35 The checkpointing node is at `2814599:767e539b978172ee1c602dfc7b7739289a40e64d12ffa072746f9f005c3c1287` , which is the correct hash for that height of the majority chain. 13:44:48 I think there are multiple flaws with the this approach. The paper (https://eprint.iacr.org/2019/486.pdf) describes that other pools can become detectives only by infiltrating the selfish mining pool (such as Qubic in this case) and acting as sensors that retrieve information on coinbase transactions or merkleroot hashes. However, Qubic can prevent infiltration by implem 13:44:49 enting a whitelist for new miners, which is definitely possible for them as I suspect they're both renting hashes and collaborating with someone who has lots of rigs. Additionally, θ (the share of detectives) must be at least 50% of the hash rate for this strategy to be effective, which may not be feasible for the largest pools to implement, even if it benefits them. Don't forget 13:44:51 that Qubic is already incentivizing miners to switch by providing them with $QUBIC emissions. I do not see why Qubic cannot increase its emissions to prevent larger pools from becoming detectives, offering them a % share of selfish mined blocks in return, if they decide not to implement a whitelist. 13:45:00 I think there are multiple flaws with this approach. The paper (https://eprint.iacr.org/2019/486.pdf) describes that other pools can become detectives only by infiltrating the selfish mining pool (such as Qubic in this case) and acting as sensors that retrieve information on coinbase transactions or merkleroot hashes. However, Qubic can prevent infiltration by implementi 13:45:01 ng a whitelist for new miners, which is definitely possible for them as I suspect they're both renting hashes and collaborating with someone who has lots of rigs. Additionally, θ (the share of detectives) must be at least 50% of the hash rate for this strategy to be effective, which may not be feasible for the largest pools to implement, even if it benefits them. Don't forget tha 13:45:03 t Qubic is already incentivizing miners to switch by providing them with $QUBIC emissions. I do not see why Qubic cannot increase its emissions to prevent larger pools from becoming detectives, offering them a % share of selfish mined blocks in return, if they decide not to implement a whitelist. 13:47:04 I have 12 oeers as 281942 13:47:30 Including myself 13:48:39 I'm not saying that's the chaintip. I'm saying that the checkpointing node is on the correct chain, just not synced to tip because of bans. Try `print_block 2814599` 13:48:57 The block's hash should be 767e539b978172ee1c602dfc7b7739289a40e64d12ffa072746f9f005c3c1287 13:49:18 Both my nodes stayed on checkpointed side listed by Rucknium: 13:49:55 *both of my standare DNS checkpoints off nodes 13:50:16 This matches for me 13:50:50 I still have warnings in my (non-checkpointed) node about bad checkpoints 13:51:33 ``` 13:51:33 2025-08-19 13:49:19.700 W CHECKPOINT FAILED FOR HEIGHT 2814591. EXPECTED HASH: , FETCHED HASH: <98604bc2d637ed8120e4864459ab1e9715ae280c6349a12b4194d5c3df66eca9> 13:51:35 ``` 13:52:21 But 599 matches. Probably just some of the txt entries are on orphaned chain 13:52:30 🤔 how can that happen? 13:52:31 (the 599 checkpoint is built on top of my attacking chain) 13:53:32 I believe the earlier checkpoibts, 584, 585, 587, 591, were orphaned 13:54:08 w′ ← CreateTask(v, r, m', st, T, q) 13:54:09 To retrieve m' (the transaction list from the selfish pool), it is necessary to infiltrate the selfish pool and create the counter PoW task. This can be easily countered by Qubic, as they can prevent new miners through a whitelist, offer incentives to miners to stay within their pool, or distribute fake tasks. I apologize for overcrowding the conversation, and I am aware that ever 13:54:11 yone is currently working on DNS checkpointing (which is more important). I will refrain from further criticisms at this time. 13:54:53 Likely because of this ^. The "honest chain" had no hashpower, and so never overtook the attacked chain 13:56:24 ofrnxmr: Ah, that could cause problems. If checkpoints somehow are set on incompatible chains. 13:59:35 The block hash for block 2814591 on testnet.xmrchain.net is different from the one in the DNS record. 14:00:41 Interestingly, I get a 500 Internal Server Error if I search the orphaned block's block hash on testnet.xmrchain.net , instead of even a "not found" message. It's probably a bug in the block explorer code. 14:01:35 I'll set the new checkpoints to the tip of the majority chain and clear bans. That should heal the netsplit. 14:02:45 Might also want to clear txt entries for orphaned blocks 14:03:44 I just have a rotating set of 10 checkpoint TXT DNS records. Once 10 new blocks are added, all those old checkpoints will be gone. 14:03:59 If i pop_blocks -> enforce = node fails to start w/ missing hash error 14:09:52 My script is updating the DNS records now. Just have to wait until 10: 14:09:53 ``` 14:09:55 Changed DNS TXT record number 1 to 2814945:cac950675ca0dd40d52c99146fdbe66c90df4d2eb4cc9a258eba54d0786f2f1f 14:09:57 Changed DNS TXT record number 2 to 2814946:e480c9eb8f8da671304fa8eb85415fdb1476f94fa978d0478cb8d9b0d8bab23e 14:09:59 ``` 14:16:41 I should write some logic into this script to not generate checkpoints on two incompatible chains. 14:17:22