<j​osephlepvrrvin:matrix.org> 84KJ3RRphmVYPqs1fVFyLB4xyGNQv1zAC1XCYFJMno1DKWLLaoQxqRRYR3PHKQkJiGfAdjcxhPBhyMJJuMB8VcoLJnZUgnZ

<r​brunner7:monero.social> Does anybody have software ready, or could build such with minimal effort, to submit transactions to testnet plus at the same time mine there withholding blocks and finally cause an actual re-org that is larger than 10 blocks, so it would be plain to see that such a reorg makes some transactions invalid?

I think you can do this with two monerod that unpeer

Make tx on first on wallet using some decoys from recent blocks

On second node orphan those recent blocks and mine empty or other txs

Reconnect second node, cause reorg

Tx would now be not valid

Nothing special

<o​frnxmr:xmr.mx> Yes

<o​frnxmr:xmr.mx> the hard part is choosing decoys from recent blocks

You could force this by otherwise spending from a just-unlocked output you have as well

<o​frnxmr:xmr.mx> True. can send both txs back to mempool

<r​brunner7:monero.social> What I want to achieve is a mostly psychological effect: Make it patently clear to hopefully almost everybody, without reasonable doubt, that you "break" Monero with reorgs larger than 10 blocks, so people able to do that on mainnet (hi, Qubic people reading along!) may think twice whether they really do want to break it. For that pychological effect to happen, an actual reorg tha<clipped message>

<r​brunner7:monero.social> t is visible to all through testnet explorers might do the trick.

<r​brunner7:monero.social> DataHoarder's instructions how to do it sound simple enough, but I myself probably do not have the necessary hashrate to pull it off, even with the low rate on testnet ...

<r​brunner7:monero.social> Of course doing such reorgs would also be a nice chance to test code that maybe was never really tested so far, because until now a reorg larger than 10 blocks was such a remote, almost mythical possibility, that maybe nobody bothered.

It is a break by design. I have seen some messages of CfB quoting one of my conversations from #monero-research-loungeabout the global output indices breaking on long reorgs past confirmation threshold

The confirmation threshold is more than just a way to delay txs but also selects how early decoys can be picked or resiliency of global output indices (assumes that anything over conf threshold must be static)

You could make the transactions in the past, but that would also affect privacy by delaying the transaction a bit (makes it obvious)

Next time checkpoint reorgs are done in testnet maybe any of you can join it with the test transactions

<r​brunner7:monero.social> Sure, it's a "break by design", nothing really interesting for Monero devs in the know, and nothing surprising - to us. I just got the impression that many people outside our close circle, some influential Qubic people included, are not yet fully aware, and still think that they can do a show of power with reorgs of, say, 20 blocks, without any serious consequences.

<r​brunner7:monero.social> DataHoarder, how deep will those "checkpoint reorgs" probably go? Indeed larger than 10 blocks? Maybe only if the checkpoint mechanism under testing does not work, right?

ruck and ofrn are the ones testing it so you can inquiry :)

<r​brunner7:monero.social> Ok, thanks.

<o​frnxmr:xmr.mx> Will break in a couple blocks. Maybe 10mins

<o​frnxmr:xmr.mx> @rbrunner7:monero.social

<o​frnxmr:xmr.mx> testnet.xmrchain.net

<o​frnxmr:xmr.mx> The txs in the txpook _were_ previously mined in blocks 2824678 and the receives and change spent/mined in 2824689

<o​frnxmr:xmr.mx> Those txs should now all(?) Be stuck in the txpool

<o​frnxmr:xmr.mx> The first batch of txs might be mined again in the next block, but 14 of the txs in the pool rely on 13 others. Or sonething like that

<r​brunner7:monero.social> Hmm. Will we now see only indirectly, by those transactions not getting mined for longer and longer times, that they are invalid?

<o​frnxmr:xmr.mx> We'll see in the next block if they are mined

<o​frnxmr:xmr.mx> Then 10 blocks from now if they are "re-validated"

<r​brunner7:monero.social> Like those 3 last transaction in the mempool on xmrchain with an age of 112:03:15

<o​frnxmr:xmr.mx> those were already there. Not sure who sent them, but could be txs invalidated by prior reorgs

<o​frnxmr:xmr.mx> The first 12 txs were mined again. Lets see what happens to the 14 that rely on them

<o​frnxmr:xmr.mx> After this, i'll do a big reorg to put the chain back on the checkpointed chain, which should put the txs back in their original blocks

<o​frnxmr:xmr.mx> `2025-09-02 06:46:34.320 E Transaction spends at least one output which is too young` this is in one of my node logs, and i see these same logs on mainnet when qubic does 9 block reorgs

<o​frnxmr:xmr.mx> Yeh, those txs dont appear to be mineable

<o​frnxmr:xmr.mx> I'm mining on the checkpointed chain now, to "overthrow" my attacking chain, which should put these txs back in their block

<o​frnxmr:xmr.mx> Done. testnet is back on checkpointed chain