<o​frnxmr:xmr.mx> Testing some selfish mining now, but the main chain keeps getting ahead of me so im losing my work :P

<o​frnxmr:xmr.mx> Also building binary with tev's checkpoint, and will attempt a deep reorg theren

<n​oname-user0:matrix.org> how do we do this in s decentralized way?

<n​oname-user0:matrix.org> what is the core team gets compromised or the keys for checkpointing is compromised

<n​oname-user0:matrix.org> what if

<o​frnxmr:xmr.mx> the sky is falling

<r​ucknium:monero.social> ofrnxmr: I see your orphans: testnetnode1.moneroconsensus.info

<o​frnxmr:xmr.mx> I broadcast 1 chain so far

<o​frnxmr:xmr.mx> going for a deeper one

<o​frnxmr:xmr.mx> Lets go.. 8 or 9 blocks this time

<r​ucknium:monero.social> Changing these domains, right? github.com/monero-project/monero/bl…eckpoints/checkpoints.cpp#L320-L324

<o​frnxmr:xmr.mx> Yeah

<o​frnxmr:xmr.mx> Im going to test locally first before attacking the public testnet

<r​ucknium:monero.social> To really test it we would want to mine a longer chain starting just below 2813706. Do you agree?

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

<o​frnxmr:xmr.mx> Yeah, going to pop my local down to like 715, then bring attacking chain to 705 and then attempt to reorg the 715 daemon

<o​frnxmr:xmr.mx> Just to see if it works at all :P

<o​frnxmr:xmr.mx> Just did a 9 block on the tip

<o​frnxmr:xmr.mx> Going to try the checkpoints now

<o​frnxmr:xmr.mx> My selfish method does work, and i imagine is what qubic is doing

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

<o​frnxmr:xmr.mx> When i tried at 500h/s, i was lost the 70% of my blocks ..

<r​ucknium:monero.social> Probably just one thread is mining on testnet. Net hash is 620 H/s.

<o​frnxmr:xmr.mx> Im testing the dns checkpoints now.. lets see if this works

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

<r​ucknium:monero.social> tev said ^

<r​ucknium:monero.social> > It seems that testnet checkpoints cannot be enabled anyways without changing the code. github.com/monero-project/monero/bl…onote_core/cryptonote_core.cpp#L267

<r​ucknium:monero.social> So, change that line, too? Probably can just remove `m_nettype != MAINNET || `

<o​frnxmr:xmr.mx> Yeah, duh

<o​frnxmr:xmr.mx> Round 2 in a sec

<r​ucknium:monero.social> On some of my testnet nodes I got `E Failed to parse block from blob` a lot on default log level.

<o​frnxmr:xmr.mx> From my 9 block reorg?

<r​ucknium:monero.social> happened right after the 9 block re-org

<r​ucknium:monero.social> happened on two of the three nodes I checked.

<o​frnxmr:xmr.mx> I think the dns chdckpoinfs need to have every checkpoint in them

<r​ucknium:monero.social> They need to agree with the hardcoded checkpoints?

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

<o​frnxmr:xmr.mx> 2025-08-18 01:04:16.245 W CHECKPOINT FAILED FOR HEIGHT 233000. EXPECTED HASH: <4f69bec2af6c0852412bdd10c19e6af10c8d738fe2618b5511a98efd03ab477e>, FETCHED HASH: <92eb8c2a1cdcb583365894f9a0be292a129fc2817abdae4bd61c95f0d3be4800

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

<o​frnxmr:xmr.mx> My node is trying to roll way back

<o​frnxmr:xmr.mx> Let me remove the checkpoints for testnet except for the new one

<o​frnxmr:xmr.mx> Actually/ i dont even know where thisb 233000 comes from

<r​ucknium:monero.social> I see neither that height nor that hash in the code. Maybe the DNS record is being incorrectly parsed.

<r​ucknium:monero.social> Wait, it's in a few GitHub issues: monero-project/monero #3845

<r​ucknium:monero.social> Yes, it's looking at the mainnet checkpoint sfrom DNS records: docs.getmonero.org/infrastructure/m…ero-pulse/#moneropulse-is-dns-based

<r​ucknium:monero.social> `cryptonote_core.cpp` probably needs more edits to get it to look at the testnet domains when it's running testnet.

<o​frnxmr:xmr.mx> ` // if anything fishy happened getting new checkpoints, bring down the house` lolol

<r​ucknium:monero.social> Monero code archaeology is always fun.

<o​frnxmr:xmr.mx> I guess i can just, for now, replace mainnet url

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

<o​frnxmr:xmr.mx> if (!tools::dns_utils::load_txt_records_from_dns(records, nettype == TESTNET ? testnet_dns_urls : nettype == STAGENET ? stagenet_dns_urls : dns_urls))

<o​frnxmr:xmr.mx> return true; // why true ?

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

<o​frnxmr:xmr.mx> this is probably broken

<o​frnxmr:xmr.mx> Idk if it needs more than 1 source, but i thinknso

<o​frnxmr:xmr.mx> vtnerd can you try to add the txt entry to yours again

<r​ucknium:monero.social> Rightl. I get `status: SERVFAIL` when I try `dig -t txt checkpoints.vtnerd.com +dnssec`

<v​tnerd:monero.social> To what?

<o​frnxmr:xmr.mx> to the same, its not showing any entries :P

<v​tnerd:monero.social> Oh dnnsec maybe, damnit

<v​tnerd:monero.social> Yeah it's name cheap, didn't fetch for higher tier. Let me switch to checkpoints.leeclagett.com at easydns

<v​tnerd:monero.social> All set try now

<o​frnxmr:xmr.mx> Hm. It doesnt try to rollback

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

<o​frnxmr:xmr.mx> 2025-08-18 02:25:29.971 I Using public DNS server(s): 9.9.9.9 (TCP)

<o​frnxmr:xmr.mx> 2025-08-18 02:25:29.975 I adding trust anchor: . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

<o​frnxmr:xmr.mx> 2025-08-18 02:25:29.975 I adding trust anchor: . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

<o​frnxmr:xmr.mx> 2025-08-18 02:25:29.975 D Performing DNSSEC TXT record query for checkpoints.xmrdb.com

<o​frnxmr:xmr.mx> 2025-08-18 02:25:29.976 D Performing DNSSEC TXT record query for checkpoints.leeclagett.com

<o​frnxmr:xmr.mx> 2025-08-18 02:25:30.001 I Found TXT record for checkpoints.xmrdb.com

<o​frnxmr:xmr.mx> 2025-08-18 02:25:30.001 I Found TXT record for checkpoints.leeclagett.com

<o​frnxmr:xmr.mx> 2025-08-18 02:25:30.001 D Found 2/2 matching records from 2 valid records

<o​frnxmr:xmr.mx> 2025-08-18 02:25:30.001 D DB map size: 29842946048

<o​frnxmr:xmr.mx> 2025-08-18 02:25:30.002 D Space used: 8370765824

<d​oingitforplowsof:synod.im> Hi ofrnxmr how is the dns checkpoint test going?

<v​tnerd:monero.social> Isn't that the goal?

<o​frnxmr:xmr.mx> Yeah, i reorged the checkpointed block. Goal is for the checkpoint to rollback the chain

<o​frnxmr:xmr.mx> Its not rolling back riggt now though. It should say something like this ^

<d​oingitforplowsof:synod.im> 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.

<o​frnxmr:xmr.mx> 1 sec, let me try again

<o​frnxmr:xmr.mx> @vtnerd, it worked

<o​frnxmr:xmr.mx> Rolled back to block *704

<d​oingitforplowsof:synod.im> Using public DNS server(s): 9.9.9.9 (TCP)

<d​oingitforplowsof:synod.im> Do we have to rely on centralized DNS servers like Quad9 or Cloudflare for checkpointing?

those servers query monero domains directly

you can setup your own recursive resolver to fetch these directly from monero pulse DNS servers, whatever they are

<d​oingitforplowsof:synod.im> 👍️

qubic includes at maximum 19 transactions in their blocks, be it selfish or not

<n​oname-user0:matrix.org> how many of these checkpoints can we have before it starts slowing down the dns infrastructure

you should be able to remove redundant temporary ones, once you have moved further up the chain to the next checkpoints

<b​arthman132:matrix.org> Qubic is going after dogecoin next. x.com/c___f___b/status/1957139742388298154

<b​arthman132:matrix.org> Thoughts?

<l​eonarth_:matrix.org> it will take time for them to develop doge mining, meanwhile they'll mine monero

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

<b​asses:matrix.org> zcash rigged it so it becomes Doge

<b​arthman132:matrix.org> Yep that poll was never actually a choice and CFB was hinting at mining dogecoin for weeks now, but what did you actually expect?

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

<s​pirobel:kernal.eu> "develop dodge mining" -> buy older inefficent asic miners for cheap

<s​pirobel:kernal.eu> this is also possible for bitcorn btw

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

<s​pirobel:kernal.eu> 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

<s​pirobel:kernal.eu> 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

<s​pirobel:kernal.eu> 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

<b​arthman132:matrix.org> Bitcoin has a market cap bigger than Google and Apple. It’s just infeasible for somebody like CFB to go after bitcoin.

<s​pirobel:kernal.eu> 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

<s​pirobel:kernal.eu> etherum is more expensive to attack than bitcoin. there is literature on that look it up

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

<s​pirobel:kernal.eu> 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.

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

<s​pirobel:kernal.eu> 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.

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

<s​pirobel:kernal.eu> 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.

<s​yntheticbird:monero.social> spirobel please be diagnosed, spending 30 minutes talking to yourself is not sane.

<l​eonarth_:matrix.org> 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.

<l​eonarth_:matrix.org> what does this mean?

<l​eonarth_:matrix.org> printed from my monerod node

It literally spells it out for you

<b​arthman132:matrix.org> It doesn’t seem to be a large attack, because only 1 block has been orphaned so far in the past 24 hours

it's no attack. "there might be large hash rate changes" "Or it could be just sheer bad luck."

that spells it out

<s​yntheticbird:monero.social> 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

<b​asses:matrix.org> turn it off and on again

<r​ottenwheel:unredacted.org> it's called click, click, block/ignore user, click X. carry on about your day, kitty cat.

<r​ottenwheel:unredacted.org> 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.

<b​asses:matrix.org> or move to Antarctica

new blocks mined by qubic shows they are no longer merge mining tari p2pool.io/explorer/block/13238f88dc…c831fbb9eca7e43c764383a39b7e5454a3e

l​ordx3nu:matrix.org any updates about the hashrate rental?

hopefully that rental lands on p2pool if possible :D

<1​7lifers:matrix.org> no

<1​7lifers:matrix.org> put that rental towards me

<1​7lifers:matrix.org> :3

<l​ordx3nu:matrix.org> Total amount donated was almost 19 xmr last I checked

<l​ordx3nu:matrix.org> 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.

<l​ordx3nu:matrix.org> 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.

and if you get any, dump it into renting more, infinite profit :)

<l​ordx3nu:matrix.org> Yeah I will. I don't know how much revenue I'd get for only one day of mining.

<1​7lifers:matrix.org> mine to unmineable pool

<1​7lifers:matrix.org> so you get more btc to spend on rentals

<1​7lifers:matrix.org> infinite money glitch

<m​onero.arbo:matrix.org> just fyi, I love MO, but they aren't selling or distributing the XTM again since TradeOgre went down

<m​onero.arbo:matrix.org> they will eventually, but waiting on a new exchange I guess

qubic pools have been diverging from tip a few times, they might be selfish mining again

<1​7lifers:matrix.org> oh, how selfish of them

<1​7lifers:matrix.org> :c

<l​ordx3nu:matrix.org> I'll be checking my phone. If there is an urgent need for hash send me a notification.

they will be starting the marathon for 24h at 12:00 UTC, or in 10 minutes

MoneroOcean is fine too, if you can't set up p2pool easily for the rental

<v​enture:monero.social> tevador while modeling, I noticed that your requirement

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

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

<v​enture:monero.social> (can't DM him, since he's behind the bridge)

<s​pirobel:kernal.eu> 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. 🤖

<b​arthman132:matrix.org> Qubic is only getting 1.50gh/s right now

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.

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.

<f​reeman:cypherstack.com> There's no zugzwang in blockchain, so any winning strategy can be stolen 🙂

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).

A trivial example of such a stretegy is "block has to be signed by the centralized authority" :P

"Block has to be signed by a centralized authority" is outside of the scope of PoW.

So I clam that it's a valid proof by contradiction, provided that the only thing used for consensus is hashrate.

*claim

qubic seems to be delaying blocks for a bit again, selfish started?

Today their hashrate is fluctuating around 30%, not really enough for profitable selfish mining.

their pools have also gone down a few times so it has been hard to look via pools how they are mining consistently

hard to say if it's DDoS or usual pool changes they do

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

competent operators, you know

and from tracking ofrnxmr they lose way more blocks themselves than they orphan

it is indeed PR

they seem to not be selfish mining at the moment, their blocks aren't really delayed from what pools are mining

<v​enture:monero.social> tevador: I agree with moneromoo , your prove doesn't account for PoW strategies that can differentiate between H and A.

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

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

<v​enture:monero.social> "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<clipped messa

<v​enture:monero.social> he expected payout of the victim in half (from 40% to 20%)"

<v​enture:monero.social> please remember, the effort I highlighted will not contribute to cumulative difficulty

<v​enture:monero.social> **attempt again by finding a whole new block hash** <-- highlighted PoW effort

<v​enture:monero.social> *"current PoW" rather, not sure but I think the modification would still count as "pure PoW"

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.

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.

Checkpoints, "asking a friend" etc. don't count.

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

was just making the general point, if too flippantly.

<v​enture:monero.social> i understand moneromooo

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

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

<v​enture:monero.social> the boat has not sunken yet, after that A and H should be seen more atomically, ie, rewrite-attempts to the main chain

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.

<v​enture:monero.social> it anchors to scarce resource OVER time.

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

<v​enture:monero.social> a 55% major player is not by himself existing alone malicious.

A new node joining the network has no knowledge about any block overriding.

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

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.

It's not an eclipse attack. You connect to several nodes and download two different chains. Which one is the correct one?

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

<v​enture:monero.social> i doubt there will be multiple branches

<v​enture:monero.social> at inception / checkpoint time

I'm afraid your doubt is not a sufficiently well defined consensus mechanism.

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.

<v​enture:monero.social> that is true. trusted seed nodes might be needed for inception, IBD/sync

"Trusted" is not something a decentralized consensus mechanism should need.

<v​enture:monero.social> ok. I guess then we can bury it, I think.

Monero has no such thing currently (apart from the emergency DNS checkpoints).

<v​enture:monero.social> ok, then we can bury it, I think.

<b​awdyanarchist:matrix.org> 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 <clipped m

<b​awdyanarchist:matrix.org> the level of the asymptote. Meaning we'd have to continuously adjust the weight of each block, basically forever.

<b​awdyanarchist:matrix.org> 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%<clipped m

<b​awdyanarchist:matrix.org> hashrate to overcome the penalty).

<v​enture:monero.social> sorry, edited

<b​awdyanarchist:matrix.org> 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<clipped m

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

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

<b​awdyanarchist:matrix.org> 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<clipped m

<b​awdyanarchist:matrix.org> ential between block arrival, and differentials between the block headers.

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

<v​tnerd:monero.social> You’re basically re-stating the selfish-mining paper as I can tell

<a​ntilt:we2.ee> needs clock sync BFT - not trivial.

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

<b​awdyanarchist:matrix.org> The only "fuzz factor" happens due to block header propagation delays.

<v​enture:monero.social> you mean me or Bawdy? if you are referring to the mitigation section then yes, they had the same idea about choosing deterministically.

<v​enture:monero.social> instead of first-seen

<a​ntilt:we2.ee> if you know a protocol to agree on universal time, I'd like to know more about it

<v​enture:monero.social> oh, but they had a minor tweak in that only the miner software would be modified, the bitcoin client would have remained untouched.

<v​enture:monero.social> and I do agree with you here, vtnerd, that this might be leaving the attacker with more blocks than before.

<v​enture:monero.social> Anyways, I'm just saying it again: Sometimes one (me) has to burn oneself (aka doing the simulation), to see that the stove is indeed hot. I appreciate all the input and I will likely be proven wrong

<b​awdyanarchist:matrix.org> Monotonic just means that time only moves forward. Your node is simply counting the seconds elapsed since the last common ancestor (H0), and the arrival of new blocks. This does not require agreement on universal time. It merely requires that your computer can count seconds without diverging wildly over the course of a few hours. Which every electronic device does.

<v​tnerd:monero.social> but network latency makes this difficult to start with the original timestamp

<o​frnxmr:xmr.mx> for dns checkpoint mitigations, what logic should be use to decide when to push new checkpoints? have to be careful not to reorg back onto the wrong chain

<v​tnerd:monero.social> yes, this is the issue I’m having with the checkpoints suggestion. it hurts my head to reason about

<o​frnxmr:xmr.mx> Should the checkpoints be manually approved? automated via script?

<v​tnerd:monero.social> they need to be automated to make this useful, no?

<o​frnxmr:xmr.mx> automated: --reorg-notify >= 10 block reorg = issue checkpoint for parent block. _but_ qubic could add 1 more to their chain and resubmit it again?

<b​awdyanarchist:matrix.org> Do we typically see high variance in network latency for block header propagation?

I think there would have to be some manual input for the checkpoints. Anything else can be gamed.

<v​tnerd:monero.social> [BawdyAnarchist](matrix.to/#/@bawdyanarchist:matrix.org)I don’t think anyone has analyzed that, and it depends on whether the connection is overseas or not, etc

<v​tnerd:monero.social> like if your on the east coast of one college campus going to another, its super low latency. overseas via cable _was_ typically like +100ms RTT but I don’t know if thats come down

<v​tnerd:monero.social> I don’t see how as they’re hitting the speed of light, so the RTT can only come down due to hardware CPU latency

<v​tnerd:monero.social> tevador you’re probably right, but thats just insane

<b​awdyanarchist:matrix.org> Yes I wouldnt want to penalize starting at 0. There would need to be some band of non-penalty to account for latency. Probably on the order of seconds.

<o​frnxmr:xmr.mx> edit: checkpoint should be set to the tip block of honest chain, not the parent

<v​tnerd:monero.social> the problem is that you’ve got so many details in flux it makes the system harder to reason about ([ofrnxmr](matrix.to/#/@ofrnxmr:xmr.mx))

<v​tnerd:monero.social> if automated. but if manual someone has to constantly be at it

<o​frnxmr:xmr.mx> vtnerd: a few of these and qubic should be forced (financially) to honest mine

<v​tnerd:monero.social> except the problem is knowing when to update checkpoints. they aren’t doing selfishing mining 100% of the time and is also just kind of appears out of no where when they do

<v​tnerd:monero.social> meaning the person has to be watching the blockchain actiona 24/7 … right? like it has to be automated I think, and automation is tricky due to latencies and consensus

<o​frnxmr:xmr.mx> If you update right at the chain tip after seeing reorg, it will take a few mins (at least) for the dns to propagate. So, in any case, we risk orphaning some honest blocks. Hmm..

<o​frnxmr:xmr.mx> H1-H10 -> A1-A10 -> update dns to H10 -> HA11-HA13 are mined -> dns propagates or is checked -> A1-A10 and HA11-HA13 are dropped, rolling us back to H10

<o​frnxmr:xmr.mx> H=honest A=attacker HA=honest-on-attacker's-chain

DNS checkpoints update once per hour, so that's 24 checkpoints per day. That's doable by hand in an emergency. Yes, it would be messy with constant reorgs.

> @lordx3nu:matrix.org I'll be checking my phone. If there is an urgent need for hash send me a notification.

they are reporting their highest hashrate now

<o​frnxmr:xmr.mx> We can change 1hr -> something less in the release binaries, for mining pools to run

<v​tnerd:monero.social> I don’ see how (in the steps [ofrnxmr](matrix.to/#/@ofrnxmr:xmr.mx) listed) update dns to H10. Your basically checkpointing the chain tip, which is going to be messy as an honest reorg could happen

<o​frnxmr:xmr.mx> Highest ever?

They ramped up to 48.4%

<o​frnxmr:xmr.mx> Manually. The chain tip would be the honest one (like_ what you see on moneroconsensus.info)

I think for DNS propagation, you can't hope for much less than 1 hour anyways.

3.6GH/s or so they report

<v​tnerd:monero.social> tevador you think that number is accurate? kind of hard to tell given the history

<v​tnerd:monero.social> yeah thats thing, getting accurate information in real-time is so message

<v​tnerd:monero.social> *messy not message

We'll see if block production matches. But renting more can't hurt.

there is real time information that is quite accurate

<l​ordx3nu:matrix.org> i can do a 3hr for 50 mh

hoarding that data, but at least they have 3

it matches previous times

that said neither them nor monero has put a block out in the last 15 minutes

<o​frnxmr:xmr.mx> Checkpoints at 1hr would be brutal :/. Vtnerd or tevador, are you able to update your testnet records so we can see how long it takes them to update?

<v​tnerd:monero.social> it depends on the TTL, I can’t remember what mine were set to. but yes Ill change and report the exact time I hit publish here

<r​ucknium:monero.social> My uniformed view is that the DNS checkpoints should be updated frequently, regardless of whether a re-org attack is detected. Do it for the main chain block that is 3 blocks deep. Have the node that is feeding the DNS update script refuse to re-org deeper than 3.

<r​ucknium:monero.social> uninformed*

<v​tnerd:monero.social> I just worry about having 2 dns servers and the logistics of synchronizing the two

<v​tnerd:monero.social> we’d want 1 for this then, right?

<r​ucknium:monero.social> Yes, we will have to figure out what happens if/when the multiple DNS servers disagree because of update latency.

<r​ucknium:monero.social> I think update latency (DNS caching, etc., is an argument to update ASAP and not wait for an attack to be observed.

I updated checkpoints.xmrdb.com to height 2814363 at 19:19 UTC.

<r​ucknium:monero.social> I've been experimenting with an auto update script pointed to checkpoints.moneroconsensus.info and checkpoints.moneronet.info

<r​ucknium:monero.social> If you let a 10+ block re-org stand for any time, honest wallets could construct txs based on the attacking chain and then their txs could be made invalid by the reversion to the checkpointed chain, right?

<r​ucknium:monero.social> Due to referencing decoys or real spends in the attacking chain

<v​tnerd:monero.social> I just my DNS too. The previous TTL was 1 hour, its now 5 minutes which is the shortest easydns allows

Yes. But I think exchanges have increased their confirmation time to 50+ blocks these days, so it would still not be enough for actual double spends.

They reached 51%.

<r​ucknium:monero.social> xenu: It's time to add more hashpower, probably.

<m​x_mandelbrot42:matrix.org> Xenu, post that donation address here. I'm sending more

l​ordx3nu:matrix.org whatever you can throw at it

I also might have sent some.

If their hashrate is reported correctly, we need like 200 MH/s.

I think they just needed their 51% screenshot for twitter.

<m​x_mandelbrot42:matrix.org> I might have just sent a donation

<m​x_mandelbrot42:matrix.org> I might have just sent a donation ✊

<o​frnxmr:xmr.mx> Tevador, it updated

<o​frnxmr:xmr.mx> Maybe 10mins with 8.8.8.8

<o​frnxmr:xmr.mx> Vtnerd, yours updated too

<v​tnerd:monero.social> mine is still showing old value locally

<v​tnerd:monero.social> the TTL was 1 hour, so this is part of the issue with checkpoints being less than 1 hour

<v​tnerd:monero.social> with the new value presumably this won’t happen, but the async nature of the updates is problematic

<v​tnerd:monero.social> *the new value -> the new TTL value being 5 mins

<o​frnxmr:xmr.mx> 9999 and 8888 both show updated checkpoint (one on vps, one locally)

<l​ordx3nu:matrix.org> I ordered 75 MH for 3 hours. one of the pools is taking a while to turn on, and the guy running it says he is fixing the issue

<o​frnxmr:xmr.mx> Qubic reporting 4.06

<l​ordx3nu:matrix.org> I have 16 litecoin left in my balance, plus like 6 xmr I received today while I was at work

<o​frnxmr:xmr.mx> They must be selfish mining, considering their block output is comparatively low

<v​tnerd:monero.social> maybe, been hours since reorg though

<v​tnerd:monero.social> they might just ignore the 49% at some point if they think they can maintain it (and do in fact have that much hashpower)

<o​frnxmr:xmr.mx> 4.23 reported

<o​frnxmr:xmr.mx> 8.04 across all pools

<l​ordx3nu:matrix.org> i'm getting 81 MH out of 138. It's slowly creeping up

<o​frnxmr:xmr.mx> On MO? Did MO reported hashrate climb by 81?

<a​nnelinlol:matrix.org> wtf with qubic reports

<a​nnelinlol:matrix.org> they reports last found block 647452460921

<o​frnxmr:xmr.mx> Link?

<l​ordx3nu:matrix.org> it's on moneroocean

<l​ordx3nu:matrix.org> I was at 24 MH before

<a​nnelinlol:matrix.org> miningpoolstats.stream/monero but basically they report in via API

<a​nnelinlol:matrix.org> in reality they have 25% of last 1000 blocks mined

<a​nnelinlol:matrix.org> so they actually mad I guess or smth like that

<a​nnelinlol:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/CoiGxvSEoHFQmjGTUPqcJKwA

<a​nnelinlol:matrix.org> I’d fixed 50% and bought hashpower for it lol

<o​frnxmr:xmr.mx> They must be having bad luck. Theyre likely trying to pull off a 10 block reorg (or 12, as they proposed), and get close before being overtaken

<o​frnxmr:xmr.mx> Otherwise they should ~50% of recent blocks

<a​nnelinlol:matrix.org> their hashrate isn't real anyway

<o​frnxmr:xmr.mx> They juat hit 4/5 blocks. The hashrate is real btw, just not consistent

<a​nnelinlol:matrix.org> have you guys guesses where did they get the hashrate out of the air?

<a​nnelinlol:matrix.org> in past years, EU was shut down biggest botnet that mined Monero and it was only ~1 GH/s

<a​nnelinlol:matrix.org> so with current price they should have free electricity to get at least some economical sense

<a​nnelinlol:matrix.org> I can't get it.

<a​nnelinlol:matrix.org> if they have unlimited resources, why not buy more power and conclude actual 51%?

<a​nnelinlol:matrix.org> if they haven't, how do they continue operating it without any economical sense?

<a​nnelinlol:matrix.org> their fullnode is actually EFI application that have full control of target machine, you can power it off only by putting cable out of outlet

<a​nnelinlol:matrix.org> I just can't see that many people have free machine with 1TB RAM

<a​nnelinlol:matrix.org> I just can't see that many people have free bare metal machine with 1TB RAM

<a​nnelinlol:matrix.org> I just can't see that many people have free bare metal machine with 1TB RAM

<a​nnelinlol:matrix.org> whereas XMR you can mine on any toaster

<v​tnerd:monero.social> Wait what? Why? Everything about this is so confusing

<a​nnelinlol:matrix.org> github.com/qubic/core?tab=readme-ov-file#prerequisites

<a​nnelinlol:matrix.org> 2TB RAM, sorry.

I'll risk it and call Q liars, to few blocks on public chain and not consistent with any sane selfish mining strat, anyone disagree ?

<a​nnelinlol:matrix.org> Monero itself should be at least 500+ to be profitable in some countries, not in the EU.

<a​nnelinlol:matrix.org> Monero itself should be at least 500+ to be profitable in some countries, not in the EU.

<a​nnelinlol:matrix.org> that's why most of miners don't sell XMR instantly, but Qubic do.

<a​nnelinlol:matrix.org> their CEO does an exitscam every crypto season, in 2017s it was NXT, in 2020s it was IOTA, so now its qubic

<a​nnelinlol:matrix.org> their CEO does an exitscam every crypto season, in 2017s it was NXT, in 2020s it was IOTA, so now its qubic

<a​nnelinlol:matrix.org> literally botnet

<r​ucknium:monero.social> I set TTL to 60 seconds, which some DNS servers might not like.

<r​avfx:xmr.mx> yep, moneronet is still censored

<r​avfx:xmr.mx> Maybe they censor everything new that have monero in it to "protect us"

<s​yntheticbird:monero.social> NSFC - Not safe for child

TTL of 5m is probably respected more than 60s

<v​tnerd:monero.social> easydns has a lower limit of 5m best I can tell. otherwise its probably too much load on the server

<v​tnerd:monero.social> so its probably common that 60s is too low

<r​avfx:xmr.mx> moneroconsensus.info have 10800

<r​ucknium:monero.social> Thanks. I will set it to 5m going forward

<o​frnxmr:xmr.mx> I did a small reorg, will try for a 9 block one

<r​ucknium:monero.social> RavFX: AFAIK the TXT records can be set at a different TTL than the A records, which is what I have done.

<r​avfx:xmr.mx> yeah true. I just don't have hope for Quad9 considering they block the main domains A even if they have big TTL

<r​avfx:xmr.mx> And a lot of people are parroting to use 9.9.9.9

<o​frnxmr:xmr.mx> (i also changed dns checkpoints to check every 120 seconds btw)

<o​frnxmr:xmr.mx> Will do 9 blocks at height 2814426

I restarted all my mainnet nodes with --enforce-dns-checkpointing.

<a​nnelinlol:matrix.org> meanwhile XMR 276

<r​ucknium:monero.social> I'm now filling TXT records of `checkpoints.townforgepool.net` and `checkpoints.townforger.net` with tetsnet rolling checkpoints. Quad9 doesn't ban them. It will take a while for all 10 TXT records to fill.

<t​esttank:matrix.org> What’s address where can I send some neros to rent hashpower? Gonna send some when I get home

<l​owdegree:matrix.org> miningrigrentals.com

<v​tnerd:monero.social> xcancel.com/xenumonero/status/1957090056331497679

<v​tnerd:monero.social> 447d29b8j8DiBe8vVCgw6d6DQYmYdULL3PSxoqtdKjAPBaU32okTH622enuhtVHknzJWGBQZZSCLH1fNhgh8wdKDTqG9HgW

<l​ordx3nu:matrix.org> 🫡

<v​tnerd:monero.social> It's run by xenu:

<v​tnerd:monero.social> Or wait did you want to do it yourself? That's another question entirely

<v​tnerd:monero.social> Not to crap on xenu, but just make sure when renting hashrate,,etc, they're not just taking your money without actually running the algorithm. It's dicey for sure

<l​ordx3nu:matrix.org> yeah

<v​tnerd:monero.social> guys, I saw an alternative block 35 minutes ago, and the blockrate is really low right now

<v​tnerd:monero.social> or rather my node saw it, and Im reporting it no

id?

<v​tnerd:monero.social> e3c61eff13ceed28ed764a3037f24d21eee2eebf50a5bbe7f8c74982bdbda4f4

lemme see

I cannot find this one on my nodes, height?

<v​tnerd:monero.social> 3480792

<g​ingeropolous:monero.social> yeah xmrchain is showing 20 mins since last block

<l​ordx3nu:matrix.org> oh boy

I have 028d3ed62a466eaac75c5b2733948f36a98a818cd185b0977ddfe03f8f8ef070 there

<v​tnerd:monero.social> yes, so do I, but someone sent me an alternative block

pool api data shows qubic is mining on 3480799

so they are at tip

you can probably export it via get_block vtnerd

save the hex somewhere for further inspection

<v​tnerd:monero.social> my block did not relay, as per our node code to not re-relay unless it gets reorg to main chain

block came in finally :D

<g​ingeropolous:monero.social> and xmrchain says its 13 minutes old

<v​tnerd:monero.social> as an fyi, boog maybe? suggested we change this rule for alternative chain relaying

that'd be necessary for all the above selection mechanisms

<v​tnerd:monero.social> DataHoarder: can. you print block hex in the daemon? I think you can only print tx hex

<b​oog900:monero.social> Supportxmr not updating timestamps for templates?

you want result->blob

or if you mean the command line, hmm

don't know that one well

<o​frnxmr:xmr.mx> Rucknium my reorg attempt failed for unknown reasons. Will try again. The checkpointed node blocked my attacking node

<v​tnerd:monero.social> oh right, gotta curl it up I guess

it has equivalent stuff to rpc

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/zqECATwNhsTnuJiSPvxKmTlm

<m​onerobull:matrix.org> this is a bit silly

This image is not IRC friendly

<v​tnerd:monero.social> it shows qubic hashrate at 54.2% and the next pool at 14.3%

<m​onerobull:matrix.org> but more importantly, qubic with 28 blocks, the next one with 27

<v​tnerd:monero.social> right but thats 28/100 so who knows whats going on

<m​onerobull:matrix.org> they are reporting a bullshit hashrate

<m​onerobull:matrix.org> but its so brazenly bullshit

<m​onerobull:matrix.org> their own pool is even more insane, showing something stupid like 75% of network hash

<v​tnerd:monero.social> oh right I see you were on my side lol

They are either having very bad luck or selfish mining or faking

<b​arthman132:matrix.org> It’s so strange how is their hashrate so high, but their blocks actually went down from 33 to 28

<l​ordx3nu:matrix.org> the problem is they might be attempting a major reorg

<m​onerobull:matrix.org> hm lets see, either they nearly doubled their hashrate or they just started reporting bs numbers again

<m​onerobull:matrix.org> they are still mining regular blocks at their regular ~30% rate

<l​ordx3nu:matrix.org> yeah

<m​onerobull:matrix.org> the reported numbers are just plain bs

Their pool does not account for their own hashrate as lart

<l​ordx3nu:matrix.org> it was scary a few hours ago but so far it does seem like it was faked

As part of net hash*

So it shows that misleading 74%

<m​onerobull:matrix.org> one look at moneroconsensus tells you that the numbers are fake

Or it’s selfish mining?

<b​arthman132:matrix.org> Yeah there’s no way they actually have that number

<m​onerobull:matrix.org> nah miner

<m​onerobull:matrix.org> explorer.jetskipool.ai/xmr-tracker

<m​onerobull:matrix.org> i think they just added a 2x multiplier on their reported hash lmao

currently their pools api show they are mining on monero tip

usually this shows elsewhere higher or lower if selfish

or we see block delays several minutes before they abandon or submit

<m​onerobull:matrix.org> they have the same hash as before

<v​tnerd:monero.social> oh and as a follow-up, iirc the selfish-mining paper says to relay first unpublish block in chain under certain conditions

<v​tnerd:monero.social> thus I was worried that I was first to see a massive reorg

<v​tnerd:monero.social> *not iirc, just re-read it, thats what it says to do

does it make sense to bother miningpoolstats admin with that? At this points it should avoid reporting their hashrate and just report based on blocks found

<v​tnerd:monero.social> even blocks found it messy because they kept jumpg on/off mining monero

<v​tnerd:monero.social> *is messy

00:07:24 <m-relay_> <v​tnerd:monero.social> thus I was worried that I was first to see a massive reorg

I was asking for the hex to see who it was yeah

we can decode them

<v​tnerd:monero.social> you want the whole thing? I got it

<v​tnerd:monero.social> pastebin of (your) choice

debian, privatebin works

if it was on the new irc bridge you could just post it, it'd make a paste for relevant parts :D

<v​tnerd:monero.social> do you want the metadata that came with that blob or just the blob? its matter of leaking stuff to debian

no need

just the hex blob

<b​arthman132:matrix.org> Qubic back down to 1.82gh/s

<v​tnerd:monero.social> paste.debian.net/hidden/edae3f90

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/uhmVJnZCzGlaIHSNGXwXvaFj

lemme see

<o​frnxmr:xmr.mx> People on irc cant see screenshots

bridge one of these days :)

just ... priorities

they claimed hashrate was wrong, it's going down now

<b​arthman132:matrix.org> At least we have confirmation that they do lie about their hashrate

not a know one from any entity, vtnerd. here's tx extra nonce 0000000000000002ed3c3123f000000000000000000000000000000000000000

you'd have to match against recent blocks found by pools and see if any is similar

<o​frnxmr:xmr.mx> Datahoarder: regarsing screenshots, its on the homeserver

<v​tnerd:monero.social> look for patterns in nonce behavior you mean to compare against this?

<o​frnxmr:xmr.mx> Could be reenabled

if it gets re-enabled (requiring signatures) that would just work

yeah vtnerd

the new one proxies the auth to any target server fine

<v​tnerd:monero.social> DataHoarder: is it worth doing you think? the only thing gained is that we learn which pool produced the block but not so much info global sense

nah. I see some low level blocks happen at times when old peers connect to you for syncing up

<v​tnerd:monero.social> or worse we learn nothing because it was some weird solo miner doing something

you won't believe what cursed monerod we find people on p2pool are connected two

to*

<v​tnerd:monero.social> yeah Ive seen it happen before, it was just the timing of the block throughput had me going “oh here we go"

we see their txs drop to 0 as they selfish mine so they are disconnected from the network

<t​uxsudo:nitro.chat> Seems like this isn't a reasonable thing, given they were mining almost ~2GH/s of their hashrate with regular blocks, right?

<t​uxsudo:nitro.chat> And now they are reporting much lower hashrate, so if they wanted to show it was real, they could have done it.

<t​uxsudo:nitro.chat> Monerod still reporting ~5.48GH/s, which makes me think they just made their API suddenly report over double 😂

monerod is reporting an estimate over the last 720 blocks

calculated from the network difficulty

<r​ucknium:monero.social> ofrnxmr: I just did a 16-block re-org on testnet. What happened to your node with the checkpoints enabled?

<r​ucknium:monero.social> Maybe you can package your changes into a raw patch. Are you on master or release?

<o​frnxmr:xmr.mx> Master

<o​frnxmr:xmr.mx> Lets see

<o​frnxmr:xmr.mx> Kk

<r​ucknium:monero.social> I'm on release. I don't know if applying your raw patch directly would work, but I could at least do it manually if I see a raw patch.

<o​frnxmr:xmr.mx> I think it will work, not many/any changes to these files to conflict

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

<o​frnxmr:xmr.mx> 2025-08-18 23:29:57.327 D Skipping prepare blocks. New blocks don't belong to chain. [1614/1832]

<o​frnxmr:xmr.mx> 2025-08-18 23:29:57.327 E Block with id: <db513bdb9db15c2864c41b4a4e4948ae42ac7fa3e4586783faf980c432ec5c60>

<o​frnxmr:xmr.mx> 2025-08-18 23:29:57.327 E can't be accepted for alternative chain, block height: 2814465

<o​frnxmr:xmr.mx> 2025-08-18 23:29:57.327 E blockchain height: 2814481 2025-08-18 23:29:57.327 W dropping connections to 155.138.134.171:28080

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

<o​frnxmr:xmr.mx> Is this it?

<o​frnxmr:xmr.mx> Looks like same thing that happened when i tried it

<r​ucknium:monero.social> For the re-org, I set `--keep-alt-blocks --offline` on the node, then mined to it through xmrig. Then exited and started again without the `--offline`. I don't know if the `-keep-alt-blocks` is necessary.

<o​frnxmr:xmr.mx> It also banned everyone

<r​ucknium:monero.social> What does `status` say?