<o​frnxmr:xmr.mx> Ill speedmine and try to get ahead kf main chain

<o​frnxmr:xmr.mx> Looks like if my node knows about an alt chain, it wont switch to that alt chain

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> Do your nodes see anything?

<o​frnxmr:xmr.mx> Or maybe they banned me?

<r​ucknium:monero.social> I don't see any change, but I don't see any ban statements, either. Try to clear all of your bans.

<o​frnxmr:xmr.mx> I cleared my bans

<o​frnxmr:xmr.mx> It tried to connect to peers but disconnects immediately

<o​frnxmr:xmr.mx> Restarted the node

<o​frnxmr:xmr.mx> try `bans` in your monerod, is 86.something in there?

<r​ucknium:monero.social> all four of my nodes with open ports have no bans.

<o​frnxmr:xmr.mx> matrix.monero.social/_matrix/media/…oad/xmr.mx/XgfLqvSEKYzhbWeyvXidzgfS

<o​frnxmr:xmr.mx> Damn, idk why mine is failing to connect

<r​ucknium:monero.social> try to connect as priority node to 185.141.216.147 with normal testnet p2pool port

<o​frnxmr:xmr.mx> Oh i have out peers now

<o​frnxmr:xmr.mx> Height 522

<r​ucknium:monero.social> I'm at 524

<o​frnxmr:xmr.mx> How abiut now

<o​frnxmr:xmr.mx> Mine shows youre at 530 now

<r​ucknium:monero.social> yes, 530

<o​frnxmr:xmr.mx> Did you get reorged?

<o​frnxmr:xmr.mx> Hm looks like i got reorged

<o​frnxmr:xmr.mx> Well, at least my malicious nodes did

<r​ucknium:monero.social> argh

<o​frnxmr:xmr.mx> Maybe your dns checkpoints were being pulled from the new reorged chain?

<o​frnxmr:xmr.mx> And mine followed the latest checkpoint?

<r​ucknium:monero.social> Oh. Yeah.

<r​ucknium:monero.social> I need the raw patch on the node that pushes up the DNS checkpoints.

<o​frnxmr:xmr.mx> this should do it

<r​ucknium:monero.social> New binary built on the DNS checkpoint node. Creating another attacking chain.

<v​tnerd:monero.social> 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

<v​tnerd:monero.social> 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

<o​frnxmr:monero.social> Hopefully theyd get forked off, then get forked back

<v​tnerd:monero.social> I don't follow why they would fork back - you mean because the alt chain stops being mined?

<r​ucknium:monero.social> I just sent out the attacking chain. testnetnode4.moneroconsensus.info is patched with the checkpoints (and is the origin of the checkpoints). testnetnode3.moneroconsensus.info is unpatched.

<r​ucknium:monero.social> Now I will attempt to mine on the old chain.

<v​tnerd:monero.social> Saw both here basically instantly, guess it wasn't a surprise since everyone on testnet is running without checkpoints

<r​ucknium:monero.social> On my patched node I see things like

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> 2025-08-19 00:57:06.427 I Host xxx.xxx.xxx.xxx blocked.

<r​ucknium:monero.social> 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]

<r​ucknium:monero.social> 2025-08-19 00:57:09.311 I SYNCHRONIZATION started

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> `0(out)+1(in) connection` on the patched node

<r​ucknium:monero.social> "old" chain has now overtaken the attacking chain. It's not spread throughout the network yet because of bans.

<v​tnerd:monero.social> 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

<r​ucknium:monero.social> Now seeing, on the patched node

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> 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]

<r​ucknium:monero.social> 2025-08-19 01:02:29.672 I SYNCHRONIZATION started

<r​ucknium:monero.social> ```

<v​tnerd:monero.social> Just saw the swap back on the priority node first, then the other one about 25 seconds later

<v​tnerd:monero.social> 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

<v​tnerd:monero.social> For the first reorg that is and the more similar peers

<o​frnxmr:xmr.mx> patched node is on 583

<o​frnxmr:xmr.mx> Which is the main chaib

<r​ucknium:monero.social> Heckpointed chain is now at 582, hash 29f3bb

<v​tnerd:monero.social> Did it ever switch? Should've never swapped if I understand your setup correctly

<r​ucknium:monero.social> #Qubic defeated

<r​ucknium:monero.social> My unpatched nodes all switched over the the checkpointed chain at about 01:04:30

<o​frnxmr:xmr.mx> Thats what my hashpointed node is on

<r​ucknium:monero.social> and no big re-org noticed on your checkpointed node?

<r​ucknium:monero.social> notices*

<o​frnxmr:xmr.mx> nope. Didnt even get the alt chain

<o​frnxmr:xmr.mx> Shows no alt chains

<o​frnxmr:xmr.mx> it did, however, ban various nodes

<o​frnxmr:xmr.mx> We likelt want to reduce the ban time for this offence

<r​ucknium:monero.social> It seems like it worked as expected, except maybe the peer banning. Monero nodes just like to ban each other.

<o​frnxmr:xmr.mx> i need ti grep logs, but i think these are an offence ban of some sort

<o​frnxmr:xmr.mx> Like "node sent chain with diff history, dropping connection +ban"

<v​tnerd:monero.social> 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

<v​tnerd:monero.social> *DNS checkpoints

<o​frnxmr:xmr.mx> I think nides that dont pick, should be reorged to the longest chain

<o​frnxmr:xmr.mx> That dont have dns* enabled

<o​frnxmr:xmr.mx> But my dns enabled node bans them

<v​tnerd:monero.social> 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

<b​oog900:monero.social> 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

<v​tnerd:monero.social> 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

<v​tnerd:monero.social> Yes

<b​oog900:monero.social> or ig just not update DNS until the timestamp

<o​frnxmr:xmr.mx> I just pushed a reorg

<o​frnxmr:xmr.mx> Have a few nodes on my side

<o​frnxmr:xmr.mx> 454e0

<o​frnxmr:xmr.mx> Its showing on testnetnode1.moneroconsensus.info

<o​frnxmr:xmr.mx> Now lets see if main chain can overtake

<v​tnerd:monero.social> Yes both picked it up here too

<o​frnxmr:xmr.mx> dns checkpoints say only 1 of them matched, so didnt use the checkpoint

<o​frnxmr:xmr.mx> Aend another reorg

<o​frnxmr:xmr.mx> sent another reorg

<o​frnxmr:xmr.mx> Theres a problem with the dns txt entries

<o​frnxmr:xmr.mx> im only getting results from 1 of them

<o​frnxmr:xmr.mx> testnetnode1.moneroconsensus.info this is building on my attacking chain

<o​frnxmr:xmr.mx> On another note, randomx hashrate went up in price by 15-30%

<r​ucknium:monero.social> Aha. I knew there was still a use for the tree view. Three chains with blocks at the same height, 2,814,585

<g​ingeropolous:monero.social> 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

<g​ingeropolous:monero.social> how often would this check be occuring?

<o​frnxmr:monero.social> :P first i orphaned the right branch db0d, then orphaned the left branch 0902

<o​frnxmr:monero.social> Ginger, does your "default" node match up with the tip here testnetnode1.moneroconsensus.info

<o​frnxmr:monero.social> I guess i can just check

<b​arthman132:matrix.org> 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.

<b​arthman132:matrix.org> 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.

<t​orir:matrix.org> 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.

<t​orir:matrix.org> Just use a remote node over Tor for payments.

<b​arthman132:matrix.org> That’s a very serious flaw though, because remote nodes can be malicious and can track monero transactions

<b​arthman132:matrix.org> That’s a very serious flaw though, because remote nodes can be malicious and can track monero transactions if they’re malicious

<b​arthman132:matrix.org> The danger of malicious nodes have been known for years and it’s recommended that you set up a node yourself.

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

<b​arthman132:matrix.org> 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.

<b​arthman132:matrix.org> 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

<o​frnxmr:xmr.mx> Off topic

<o​frnxmr:xmr.mx> [#monero:monero.social](https://matrix.to/#/%23monero:monero.social)

<b​arthman132:matrix.org> How is it off topic?

<k​ayabanerve:matrix.org> ofrnxmr @ofrnxmr:xmr.mx: I'd say it's perfect for here, actually

<k​ayabanerve:matrix.org> 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.

<s​yntheticbird:monero.social> hiding a node presence is a combination of traffic obfuscation and resistance to Active probing

<s​yntheticbird:monero.social> which is both hard

<k​ayabanerve:matrix.org> In comparison, IIRC, Tor tries to appear as an HTTPS connection. Not noise, but web traffic.

<k​ayabanerve:matrix.org> SyntheticBird: Easier if you don't accept incoming connections, but yeah.

<k​ayabanerve:matrix.org> 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

<k​ayabanerve:matrix.org> 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

<k​ayabanerve:matrix.org> I think boog did notable work on "contact lists'?

<s​yntheticbird:monero.social> contact lists?

<b​arthman132:matrix.org> How many remaining tests are needed for FCMP

<f​iatdemise:matrix.org> 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?

<f​iatdemise:matrix.org> zawy12/difficulty-algorithms #76#user-content-selfish

<f​iatdemise:matrix.org> I found his simulation post here easier to understand. zawy12/difficulty-algorithms #87

<a​rticmine:monero.social> This is worth serious discussion

<m​onerobull:matrix.org> qubic hasnt found any blocks in a while

<m​onerobull:matrix.org> are they working on reorgs again

not from what I can see

<a​rticmine:monero.social> The permitted time delay/ advance need to take into consideration:

<a​rticmine:monero.social> 1) Relativistic effects (The speed of light in fibre or to and from satellites

<a​rticmine:monero.social> 2) Switching times of Internet routers

<a​rticmine:monero.social> 3) The impact of censorship delays on network latency (For example the great firewall of China)

<a​rticmine:monero.social> .other latency delays in the Internet

<a​rticmine:monero.social> 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.

<a​rticmine:monero.social> 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

Ticket bots are just on the server right next to them, in Germany

<a​rticmine:monero.social> I have been successful from British Columbia in Western Canada

<a​rticmine:monero.social> Manually

<a​rticmine:monero.social> I estimate my handicap was about 200 ms

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I also see this at the default log level, right after a re-org:

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> 2025-08-19 01:43:24.363 W WARNING: no majority of DNS TXT records matched (only 1/2)

<r​ucknium:monero.social> 2025-08-19 01:46:03.982 W WARNING: no majority of DNS TXT records matched (only 1/2)

<r​ucknium:monero.social> 2025-08-19 01:52:45.455 W CHECKPOINT FAILED FOR HEIGHT 2814582. EXPECTED HASH: <29f3bb29d9949edfdbe7f49af2abf0e00c81680c16c00dbe47614cf14b6106ff>, FETCHED HASH: <6839d07d89b79d53264a7f199ce7a1315ce0b1aded7988cfd745f

<r​ucknium:monero.social> 79bdc392606>

<r​ucknium:monero.social> 2025-08-19 01:52:45.455 E Local blockchain failed to pass a checkpoint, rolling back!

<r​ucknium:monero.social> 2025-08-19 01:52:45.480 W Attempt to get hash from height 2814584 failed -- hash not in db

<r​ucknium:monero.social> 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

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> Unless anyone objects, I will clear those bans on the node in 30 minutes, which will probably end the netsplit.

<o​frnxmr:xmr.mx> My attacking node, at 2814933, is not using checkpointing

<o​frnxmr:xmr.mx> The issue here, is that the main chain (the one mining at 600h/s) got forked onto my attacking chain.

<o​frnxmr:xmr.mx> I think the way to fix, is to get the checkpointed chain ahead of the attacked one

<r​ucknium:monero.social> I think the checkpointing node is on the same main chain as the rest of the network

<r​ucknium:monero.social> I can also just set the checkpoints to the majority network by pointing my checkpointing script at a different node.

<r​ucknium:monero.social> The checkpointing node is at `2814599:767e539b978172ee1c602dfc7b7739289a40e64d12ffa072746f9f005c3c1287` , which is the correct hash for that height of the majority chain.

<d​iw_tim:matrix.org> <n​ioc> I think there are multiple flaws with the this approach. The paper (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<clipped message>

<d​iw_tim:matrix.org> 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<clipped message>

<d​iw_tim:matrix.org> 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.

<d​iw_tim:matrix.org> <n​ioc> I think there are multiple flaws with this approach. The paper (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<clipped message>

<d​iw_tim:matrix.org> 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<clipped message>

<d​iw_tim:matrix.org> 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.

<o​frnxmr:xmr.mx> I have 12 oeers as 281942

<o​frnxmr:xmr.mx> Including myself

<r​ucknium:monero.social> 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`

<r​ucknium:monero.social> The block's hash should be 767e539b978172ee1c602dfc7b7739289a40e64d12ffa072746f9f005c3c1287

<v​tnerd:monero.social> Both my nodes stayed on checkpointed side listed by Rucknium:

<v​tnerd:monero.social> *both of my standare DNS checkpoints off nodes

<o​frnxmr:xmr.mx> This matches for me

<o​frnxmr:xmr.mx> I still have warnings in my (non-checkpointed) node about bad checkpoints

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> 2025-08-19 13:49:19.700 W CHECKPOINT FAILED FOR HEIGHT 2814591. EXPECTED HASH: <c6fed0a752aacc76af6ed589059d8dc4eb2570cf827d4d68334525998b0cccd4>, FETCHED HASH: <98604bc2d637ed8120e4864459ab1e9715ae280c6349a12b4194d5c3df66eca9>

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> But 599 matches. Probably just some of the txt entries are on orphaned chain

<r​ucknium:monero.social> 🤔 how can that happen?

<o​frnxmr:xmr.mx> (the 599 checkpoint is built on top of my attacking chain)

<o​frnxmr:xmr.mx> I believe the earlier checkpoibts, 584, 585, 587, 591, were orphaned

<d​iw_tim:matrix.org> w′ ← CreateTask(v, r, m', st, T, q)

<d​iw_tim:matrix.org> 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<clipped message>

<d​iw_tim:matrix.org> yone is currently working on DNS checkpointing (which is more important). I will refrain from further criticisms at this time.

<o​frnxmr:xmr.mx> Likely because of this ^. The "honest chain" had no hashpower, and so never overtook the attacked chain

<r​ucknium:monero.social> ofrnxmr: Ah, that could cause problems. If checkpoints somehow are set on incompatible chains.

<r​ucknium:monero.social> The block hash for block 2814591 on testnet.xmrchain.net is different from the one in the DNS record.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I'll set the new checkpoints to the tip of the majority chain and clear bans. That should heal the netsplit.

<o​frnxmr:xmr.mx> Might also want to clear txt entries for orphaned blocks

<r​ucknium:monero.social> 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.

<o​frnxmr:xmr.mx> If i pop_blocks -> enforce = node fails to start w/ missing hash error

<r​ucknium:monero.social> My script is updating the DNS records now. Just have to wait until 10:

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> Changed DNS TXT record number 1 to 2814945:cac950675ca0dd40d52c99146fdbe66c90df4d2eb4cc9a258eba54d0786f2f1f

<r​ucknium:monero.social> Changed DNS TXT record number 2 to 2814946:e480c9eb8f8da671304fa8eb85415fdb1476f94fa978d0478cb8d9b0d8bab23e

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> I should write some logic into this script to not generate checkpoints on two incompatible chains.

<r​ucknium:monero.social> I don't see any complaints in the log of the checkpointed node about the DNS checkpoints now being higher than its current height.

<o​frnxmr:xmr.mx> Are your scripts updating on a timer? Or triggering with --block-notify?

<r​ucknium:monero.social> Just a timer. Actually, the script hanged, so it's restarting.

<d​iw_tim:matrix.org> Is there a way to visualize the current blocks on testnet while you're testing DNS checkpointing?

<r​ucknium:monero.social> diw_tim: Yes: testnetnode1.moneroconsensus.info testnetnode2.moneroconsensus.info testnetnode3.moneroconsensus.info testnetnode4.moneroconsensus.info

<d​iw_tim:matrix.org> Thanks

<r​ucknium:monero.social> testnetnode4 is the checkpointed node. It's also the checkpoint_ing_ node, i.e. the one that checkpoints are sourced from. You can see it's behind the other nodes.

<j​ohn_r365:monero.social> ArticMine: replying to your comment in the MRL room/channel.

<j​ohn_r365:monero.social> Quote: "The Qubic attack is based upon the centralization of pools not the underlying consensus protocol."

<j​ohn_r365:monero.social> My understanding is that the hash rate of XMR (and other PoW coins) is limited by the daily emission rate in fiat terms. For Monero that's about $118k per day currently.

<j​ohn_r365:monero.social> Were XMR emitting $1m per day, for example, we could expect a higher hash rate. Which would then force Qubic to spend more in CPUs to achieve the same results.

<j​ohn_r365:monero.social> I'm trying to bridge what I've said with what you've said, and I think I'm missing something. How does less centralisation of miners solve the the low daily emission rate in USD terms?

rucknium: irc.gammaspectra.live/108e5d1a66a4a8be/image.png did we make a square? I guess there's an extra node edge in the graph that is not necessary here

they both merged in one it seems :D

looks good in tree

<r​ucknium:monero.social> DataHoarder: Exactly. Tree view shows the situation fine.

<r​ucknium:monero.social> So tree view still has a use.

<r​ucknium:monero.social> I guess I could try to automatically detect this situation and default to tree view in that case.

<r​ucknium:monero.social> `if (more than two blocks at the same height) {...}`

it's fine, you could just make an alert there

<r​ucknium:monero.social> I hope and expect that this situation won't appear on mainnet :D

<r​ucknium:monero.social> This stuff should be useful for FCMP stressnet, too, if chainsplits appear like last time.

<d​iw_tim:matrix.org> Who's to say that Qubic might not increase their share of hash power as they gain more profit from increased emissions? Moreover, what determines the optimal amount of emissions? Bitcoin only has $47.83M in daily emissions per day, which is lower than Monero's when considering emissions/mcap.

<d​iw_tim:matrix.org> I'm not convinced about adjusting emission/fees, as it relies on predicting an inherently unpredictable outcome: the distribution of mining pools after altering the security budget for Monero. This could potentially incentivize miners from other chains or those who don't mine to start mining on Monero, but it could also give Qubic a short-term profit boost, allowing them to distri<clipped message>

<d​iw_tim:matrix.org> bute increased subsidies and further solidify their position in the network.

<r​ucknium:monero.social> Bribery attacks are hard to defend against in both PoW and PoS settings, AFAIK. See

<r​ucknium:monero.social> Judmayer et al. (2020) "SoK: Algorithmic Incentive Manipulation Attacks on Permissionless PoW Cryptocurrencies" eprint.iacr.org/2020/1614

<r​ucknium:monero.social> Karakostas, Kiayias, & Zacharias (2024) "Blockchain Bribing Attacks and the Efficacy of Counterincentives" arxiv.org/abs/2402.06352

<o​frnxmr:xmr.mx> All i did, was broadcast my chain, disconnect, and begin selfish mining again, then broadcast it again.

<r​ucknium:monero.social> I don't know if Qubic is truly being very successful in their miner bribery attempts. That's an empirical question that does not have a clear answer yet.

<o​frnxmr:xmr.mx> I think their "bribery" comes by way of renting their hashrate to us, then using the profit to add more hashrate each time

<o​frnxmr:xmr.mx> not bribery at all :P. More like smart business

<j​ohn_r365:monero.social> diw_tim: "Moreover, what determines the optimal amount of emissions?" - Presumably the larger number in fiat terms the better?

<j​ohn_r365:monero.social> I think we could all agree that if 1 XMR cost $10 and the daily emission rate was $4,320 - that's unlikely to be very

<j​ohn_r365:monero.social> *unlikely to be very secure

<j​ohn_r365:monero.social> But I also agree that it's difficult to change the emission curve now. I wasn't suggesting we did - the previous discussion was not about that.

<m​onero.arbo:matrix.org> the dollar value doesn't really change the network value to security budget ratio, so sure $10 XMR would be cheaper to attack, but attacking it would also be less lucrative

remember that an attacker might not want the lucrative part, just harm monero.

<j​ohn_r365:monero.social> Lyza: that assumes that the attack is about making profit. if the token represented an ideology, the attack could be designed to try and stifle the ideology. so $10 XMR would make attacking it cheap in those terms

<m​onero.arbo:matrix.org> granted, but I think a $10 price would mean XMR is already functionally dead in terms of reputation as well. price is fairly correlated with relevance

<m​onero.arbo:matrix.org> anyway I agree more budget is more better, even if just in USD terms

<a​ntilt:we2.ee> OT: every time I hear "nash equilibrium" I got that feeling... ppl are not rational all the time and games are not strictly defined in terms of boundaries.

<o​frnxmr:xmr.mx> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) can you mine on your checkpointed node to get ahead of the attacked chain?

<o​frnxmr:xmr.mx> i screwed up and cant get on the checkpointed chain now :P

<o​frnxmr:xmr.mx> (or share the ip of that node so i can sync from it)

<r​ucknium:monero.social> Right. Side payments and/or transferable utility will blow up a lot of game equilibria.

<r​ucknium:monero.social> ofrnxmr: Yes, I will mine to it. It is starting to ban a lot of peers, however.

<r​ucknium:monero.social> It knows that it is behind the main chain, but then bans those nodes, probably because they are on the attacking chain.

<o​frnxmr:xmr.mx> ok thanks, try to overtake the attacked nodes

<r​ucknium:monero.social> I mean, the main chain = attacking chain now

<o​frnxmr:xmr.mx> My mistake for not testing peoperly

<o​frnxmr:xmr.mx> I should have had a checkpointed node that i could use to overtake the attacking node, but all of my nodes are stuck on attacking chain. I disnt use keep-alt-blocks

<r​ucknium:monero.social> The checkpointed/checkpointing node's RPC is `185.141.216.147:28089`. You can mine to that in the future.

<r​ucknium:monero.social> I think I have access to a more powerful rig than yours :P

<r​ucknium:monero.social> So I will mine fast to get beyond the current main chain. You will want to connect a node to `85.141.216.147` because it seems to be isolated from the network now.

<r​ucknium:monero.social> Is there a command to clear all bans? I forget.

<r​ucknium:monero.social> I got two inbound connections. We should see a re-org in the rest of the network soon.

<r​ucknium:monero.social> I think I got it. Re-orged everyone. I'll stop the fast mining on that node.

<o​frnxmr:xmr.mx> I got reorged onto your chain, i think

<o​frnxmr:xmr.mx> i didnt do anything manually

<o​frnxmr:xmr.mx> Looks like things heal ok

<o​frnxmr:xmr.mx> I dont think so? :S

<r​ucknium:monero.social> I guess you could do it programmatically through RPC. But command line is more convenient.

<r​ucknium:monero.social> I was banning a lot of peers. Just by luck two non-banned peers connected to me after I achieved the longest chain. AFAIK, on mainnet mass bans aren't as bad because there are so many nodes.

<o​frnxmr:xmr.mx> Yeah, ideally the bans should be shorter

<o​frnxmr:xmr.mx> Onstead of 86000 seconds, like 120 seconds

<o​frnxmr:xmr.mx> Long enough for main chain to get ahead

<v​tnerd:monero.social> Your probably right, but yikes I hate changing stuff like this

<o​frnxmr:xmr.mx> cryptonote_core.cpp L277, does this lock the daemon?

<o​frnxmr:xmr.mx> There are some concerns about setting the value to 120 due to locking

You can set ban length per ban (at least via RPC).

<o​frnxmr:xmr.mx> Example from p2pool release notes: `--disable-dns-checkpoints is needed to avoid periodical lags when DNS is updated`

<o​frnxmr:xmr.mx> (L277 on master, not sure about release)

<v​tnerd:monero.social> Yeah that function call on 277 looks a little expensive, given that its supposed to load a json file too

<v​enture:monero.social> Hello all :)

<v​enture:monero.social> my idea was stupid. I see that now, bifurcation would not get resolved. ..and the numbers/percentages were out of touch needless to say

<v​enture:monero.social> I got another one, but I don't hold strong opinions anymore. I would appreciate a quick intuition check

<v​enture:monero.social> How about

<v​enture:monero.social> - we have an additional field "donation" (not sure if that can be a stealth address or not)

<v​enture:monero.social> - block rewards are paid out by the subsequent block (N+1) based on that donation field

<v​enture:monero.social> - rewards would be given to all competing blocks (uncles) uniformly

<v​enture:monero.social> outside of protocol, in stratum:

<v​enture:monero.social> - mine on the candidate that is the index of the sorted array of all candidate block hashes. (index is determined as first bits of the hashed array modulo len(candidates) )

<v​enture:monero.social> Hello all :)

<v​enture:monero.social> my idea was stupid. I see that now, bifurcation would not get resolved. ..and the numbers/percentages were out of touch needless to say

<v​enture:monero.social> I got another one, but I don't hold strong opinions anymore. I would appreciate a quick intuition check

<v​enture:monero.social> How about

<v​enture:monero.social> - we have an additional field "donation" (not sure if that can be a stealth address or not)

<v​enture:monero.social> - block rewards are paid out by the subsequent block (N+1) based on that donation field

<v​enture:monero.social> - rewards would be given to all competing blocks (uncles) uniformly. (maybe this needs to parent (N-1) + uncles from N-2... not sure)

<v​enture:monero.social> outside of protocol, in stratum:

<v​enture:monero.social> - mine on the candidate that is the index of the sorted array of all candidate block hashes. (index is determined as first bits of the hashed array modulo len(candidates) )

<t​orir:matrix.org> Rather than detective mining, would it be feasible to hardfork RandomX to fully rely on the contents of the previous block rather than only a hash of the previous block? That would force selfish mining pools to publish the entire block to all of their miners and make it possible for even a single defecting miner in their pool to publish the block.

<r​ucknium:monero.social> Maybe. But wouldn't hashing the whole block slow down hashing of blocks with a lot of txs, reducing the incentive to include them? I guess the whole block could be first hashed with a fast hashing algorithm, then sent into RandomX to achieve the desired effect and keep incentives aligned.

<t​orir:matrix.org> I was thinking the block would just be copied into the RandomX scratchpad at the start. Or maybe add an opcode that reads from the previous block instead of from memory. All that is necessary is that parts of the previous block *might* be included in the RandomX hash and that it can't be predicted which ones so you are forced to have the entire block on hand.

<t​orir:matrix.org> If the block can be hashed with a fast hash before going into RandomX the selfish pool could give the miners only that hash. The RandomX changes would need to be designed so that access to the unhashed block is required.

<r​ucknium:monero.social> I'm thinking that every time the nonce changes, you have to include the block. The miners increment the nonce.

<r​ucknium:monero.social> AFAIK.

<m​onerobull:matrix.org> detective mining seems like cope

<m​onerobull:matrix.org> way too easy to mislead the honest snooping miners

<t​orir:matrix.org> Looks like RandomX currently initializes the scratchpad by hashing the value to be hashed, then using that hash as the seed to an AES generator and fills the scratchpad with that. The previous block could be incorporated into the initial hash (which would slow it down), could be XORed into the scratchpad after it is generated (which would be pretty fast), XORed into the dataset so<clipped message>

<t​orir:matrix.org> mehow (I believe normally the dataset is static and only changes every 2048 blocks, so this would be a weird change), or accessed via an opcode modified to read from the previous block instead of from the scratchpad.

<t​orir:matrix.org> A lot of careful design went into RandomX and I'm not qualified to what would be the best way to accomplish this. Also my proposal is basically the same as monero-project/research-lab #98 so...

<t​orir:matrix.org> Though #98 would need to be adjusted to update the dataset every block if it were to work against selfish mining.

<a​rticmine:monero.social> If the Qubic pool were fully decentralized, where the individual miners on the Monero side have control over the blocks, there would be no attack regardless of the hash rate.

<a​rticmine:monero.social> There is no reason why in a centralised pool the block cannot be constructed by whomever found the solution, rather than by the pool