<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

<b​oog900:monero.social> When the txs get reorged and invalidated, have you tried making another tx?

<b​oog900:monero.social> I would think you would have to wait 7 days for the one that got reorged to be dropped from nodes pools but I am not sure

<r​brunner7:monero.social> "Done. testnet is back on checkpointed chain" Is this the reason why this whole exercise has *not* left transactions in the pool that are unmineable because invalid and now wait days before they expire?

<r​ucknium:monero.social> You need to upset the global output index.

<r​ucknium:monero.social> I think. On testnet, with only the coinbase txs usually, the original referenced output index would still be the same.

<a​ntilt:we2.ee> yes. similar to checkpointing on eth by FFG.

<r​brunner7:monero.social> By the way, is already somebody running the "moneroconsensus" web app with the nice orphans display not for mainnet, but for testnet?

testnetnode [1-4 ].moneroconsensus.info

<r​ucknium:monero.social> Right : testnetnode1.moneroconsensus.info , testnetnode2.moneroconsensus.info , testnetnode3.moneroconsensus.info , and testnetnode4.moneroconsensus.info

<r​ucknium:monero.social> Node 4 is the _checkpointing_ node. Node 3 is _checkpointed_. Nodes 1 and 2 are not enforcing checkpoints.

<r​ucknium:monero.social> On testnet now, if you `set_log verify:trace` and `start_mining <testnet_main_address>`, you will see `E Failed to check ringct signatures!`. I think it's because of those 3 old txs in the txpool that were invalidated because of a deep re-org.

<r​ucknium:monero.social> They aren't technically double spends. You can check with `print_pool_stats`:

<r​ucknium:monero.social> `0 double spends, 0 not relayed, 0 failing, 3 older than 10 minutes (oldest 4 days ago), no backlog`

<r​ucknium:monero.social> If you need a testnet address to mine to, you can use mine :) `9uk5eY8waibQp7MMwpo3JrcMFatbiGtHKcTHMEzxWE39An8R3VTbztTPcJ7MDYEVVrAC4ueSV5KzP4GMTTwGoGBjAtKFp7i`

<r​ucknium:monero.social> More evidence that those 3 txs were in a set of re-orged blocks: sech1 said "72 hours is the standard timeout. If there was a reorg, transactions from reorg'd blocks stay for 1 week" libera.monerologs.net/monero-community/20240426#c369252-c369253

<r​ucknium:monero.social> The three invalid txs have been in the testnet txpool for 78 hours (check with `print_pool_stats` in the Monero node console)

<r​brunner7:monero.social> All very interesting, thanks! Not sure I fully understand: If I as an outsider try now to deep-reorg testnet, will I succeed, or will I fail because of active checkpointing?

<r​ucknium:monero.social> Miners mining on top of the checkpointed block(s) need to eventually produce the longest chain, for the re-org to fail against non-checkpointed nodes (which are the vast majority of them).

<o​frnxmr:xmr.mx> boog900 , yes. Tx rejected for dbl spend

<r​brunner7:monero.social> This *is* the normal, standard, old testnet, not some additional 4 node private "testnet" that you run, right?

<r​ucknium:monero.social> Otherwise, the checkpointed nodes get stuck on a shorter minority chain.

<r​ucknium:monero.social> @rbrunner7:monero.social: Normal testnet, yes

<r​brunner7:monero.social> I think I need a while to fully wrap my head around this all ...

<r​ucknium:monero.social> What we have been doing is running an "attack" and then switching mining back to checkpointed nodes to simulate a successful majority chain overtake.

<b​oog900:monero.social> That should probably be changed IMO

<r​ucknium:monero.social> The checkpointing node's RPC endpoint is at `185.141.216.147:28089` , so you can just mine to that with xmrig, from anywhere. That's a simulation of the honest pools enforcing checkpointing on the nodes that provide them with block templates.

<b​oog900:monero.social> Having the tx invalidated is bad enough, needing to wait a week to resend is even worse

Manual flushing of the nodes mempool will clear them iiuc

<b​oog900:monero.social> Yes but the whole network or at least the miners need to do that

True.. enforce DNS mempool flushing :D

<r​brunner7:monero.social> Is that as bad as it sounds?

<r​brunner7:monero.social> People who get "reorg'd out" have to have 1 week, as the whole system is set up now?

<r​brunner7:monero.social> *have to wait

<o​frnxmr:xmr.mx> Yes

<r​ucknium:monero.social> I thunk the reasoning for one week timeout is that the old chain may achieve a comeback. A come-from-behind victory over the attacking chain. Then those txs would be perfectly valid again.

<r​brunner7:monero.social> Splendid

<r​ucknium:monero.social> think*

<r​ucknium:monero.social> (I guess I thunk it, too)

<o​frnxmr:xmr.mx> Ruck, yes, the old txs become valid if the old chain makes a come-from-behind victory

<b​oog900:monero.social> For the txs already in blocks in the old chain it doesn't matter if they are added back to the txpool or not they are still in the old chain

<o​frnxmr:xmr.mx> at least, the ones that were prev confirmed. Not sure about mempool txs that were invalid

<o​frnxmr:xmr.mx> Instead of flushing: why dont we accept txs like this? Bad privacy cant be the only reason

<r​brunner7:monero.social> I am pretty sure that this all would cause such a chaos on mainnet that the remaining XMR supporting DEXes would close Monero until the storm is over - and Qubic will be more or less stranded when it comes to cash in their XMR mining loot...

<b​oog900:monero.social> everyones XMR being locked for a week could increase the price :D

<b​oog900:monero.social> this scenario probably just wasn't factor in when the code was written

unknown if they monitor this channel so maybe post a TL;DR to #monero-research-lounge

that 1 week timeout sounds pretty bad, on top of having txs invalidated

but afaik that needs 10+10 deep reorgs minimum (to invalidate inputs)?

after confirmation

ah no, old tx is left in mempool. F

so 10+ is enough

if tx picks decoys or outputs from exactly the spendable recent set

<o​frnxmr:xmr.mx> 10+ is enough, particularly if an unlock tx is spent

<o​frnxmr:xmr.mx> Unlocked*

<o​frnxmr:xmr.mx> Spend -> wait 10 blocks -> spend newly unlocked outputs -> reorg -> soends from newly unlocked txs become invalid

<o​frnxmr:xmr.mx> "<D​ataHoarder> that 1 week timeout sounds pretty bad, on top of having txs invalidated" invalidating outputs is also an issue in fcmp

<o​frnxmr:xmr.mx> Dropping invalid txs isnt grest either though, as it allows a double spend before anyone really notices. If the the invalid tx could be replaced with a valid one (wallet auto-resends the "failed" tx, sort of like rbf)

if the height it's made at > than height of previous

but this is per key image ...

so it could be replaced by multiple sub txs

<b​oog900:monero.social> it would only allow txpool double spends, right?

<b​oog900:monero.social> as for txs already in blocks we either get the chain back or they are permanently invalid

<b​oog900:monero.social> I suppose there could be a third chain that has the decoys but not the tx but that is pretty unlikely as if you have enough hash power to do that you can just double spend with a normal reorg

to do a double spend with this method you'd need 20+ reorg

confirmations to be able to use decoy/output + confirmations of your own tx to become spendable

assuming merchant uses 10 block confirmation

if it reorgs less than that, the tx just drops out and re-queues, or it becomes invalid before it would have been spendable

this is for being able to do it without emitting blocks yourself ^

if you control block emission you are able to have 10+ or even without global output index invalidation

<b​oog900:monero.social> Yeah but if you wanted to double spend you can just reorg 10 blocks and replace the tx. With your method it is not just the person double spending tx that gets replaced its all txs that reference outputs that are now gone

<b​oog900:monero.social> By replace the tx I mean mine the double spend in the top block of the reorg

the 20 method allows anyone that knows such a big tx is coming to do it

regardless of miner being on it or not, just needs timing on the double spender

<b​oog900:monero.social> Yeah

<x​mrscott:monero.social> matrix.org is down with no estimated time to recover... should anyone here have critical dev comms with someone on a matrix.org based account

<x​mrscott:monero.social> Resolution tracking can be found here: status.matrix.org/#