<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