03:31:08 84KJ3RRphmVYPqs1fVFyLB4xyGNQv1zAC1XCYFJMno1DKWLLaoQxqRRYR3PHKQkJiGfAdjcxhPBhyMJJuMB8VcoLJnZUgnZ 04:34:48 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? 05:03:37 I think you can do this with two monerod that unpeer 05:03:58 Make tx on first on wallet using some decoys from recent blocks 05:04:18 On second node orphan those recent blocks and mine empty or other txs 05:04:33 Reconnect second node, cause reorg 05:04:56 Tx would now be not valid 05:05:20 Nothing special 05:07:41 Yes 05:09:47 the hard part is choosing decoys from recent blocks 05:31:19 You could force this by otherwise spending from a just-unlocked output you have as well 05:33:34 True. can send both txs back to mempool 05:47:36 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 05:47:37 t is visible to all through testnet explorers might do the trick. 05:49:21 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 ... 05:50:56 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. 05:51:17 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 05:52:32 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) 05:53:27 You could make the transactions in the past, but that would also affect privacy by delaying the transaction a bit (makes it obvious) 05:54:25 Next time checkpoint reorgs are done in testnet maybe any of you can join it with the test transactions 05:58:33 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. 06:02:43 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? 06:17:11 ruck and ofrn are the ones testing it so you can inquiry :) 06:17:27 Ok, thanks. 06:30:25 Will break in a couple blocks. Maybe 10mins 06:40:01 @rbrunner7:monero.social 06:40:15 testnet.xmrchain.net 06:41:51 The txs in the txpook _were_ previously mined in blocks 2824678 and the receives and change spent/mined in 2824689 06:42:20 Those txs should now all(?) Be stuck in the txpool 06:45:00 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 06:45:54 Hmm. Will we now see only indirectly, by those transactions not getting mined for longer and longer times, that they are invalid? 06:46:24 We'll see in the next block if they are mined 06:46:43 Then 10 blocks from now if they are "re-validated" 06:46:46 Like those 3 last transaction in the mempool on xmrchain with an age of 112:03:15 06:47:33 those were already there. Not sure who sent them, but could be txs invalidated by prior reorgs 06:48:54 The first 12 txs were mined again. Lets see what happens to the 14 that rely on them 06:49:50 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 06:50:47 `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 07:01:13 Yeh, those txs dont appear to be mineable 07:02:25 I'm mining on the checkpointed chain now, to "overthrow" my attacking chain, which should put these txs back in their block 07:09:22 Done. testnet is back on checkpointed chain 10:46:59 When the txs get reorged and invalidated, have you tried making another tx? 10:47:01 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 11:16:03 "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? 11:21:57 You need to upset the global output index. 11:23:09 I think. On testnet, with only the coinbase txs usually, the original referenced output index would still be the same. 11:35:30 yes. similar to checkpointing on eth by FFG. 12:14:38 By the way, is already somebody running the "moneroconsensus" web app with the nice orphans display not for mainnet, but for testnet? 12:18:25 testnetnode [1-4 ].moneroconsensus.info 12:19:28 Right : https://testnetnode1.moneroconsensus.info/ , https://testnetnode2.moneroconsensus.info/ , https://testnetnode3.moneroconsensus.info/ , and https://testnetnode4.moneroconsensus.info/ 12:20:23 Node 4 is the _checkpointing_ node. Node 3 is _checkpointed_. Nodes 1 and 2 are not enforcing checkpoints. 12:26:37 On testnet now, if you `set_log verify:trace` and `start_mining `, 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. 12:27:14 They aren't technically double spends. You can check with `print_pool_stats`: 12:27:15 `0 double spends, 0 not relayed, 0 failing, 3 older than 10 minutes (oldest 4 days ago), no backlog` 12:28:51 If you need a testnet address to mine to, you can use mine :) `9uk5eY8waibQp7MMwpo3JrcMFatbiGtHKcTHMEzxWE39An8R3VTbztTPcJ7MDYEVVrAC4ueSV5KzP4GMTTwGoGBjAtKFp7i` 12:39:40 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" https://libera.monerologs.net/monero-community/20240426#c369252-c369253 12:40:36 The three invalid txs have been in the testnet txpool for 78 hours (check with `print_pool_stats` in the Monero node console) 12:43:09 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? 12:45:25 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). 12:45:28 boog900 , yes. Tx rejected for dbl spend 12:45:44 This *is* the normal, standard, old testnet, not some additional 4 node private "testnet" that you run, right? 12:45:49 Otherwise, the checkpointed nodes get stuck on a shorter minority chain. 12:46:01 @rbrunner7:monero.social: Normal testnet, yes 12:47:01 I think I need a while to fully wrap my head around this all ... 12:47:28 What we have been doing is running an "attack" and then switching mining back to checkpointed nodes to simulate a successful majority chain overtake. 12:49:04 That should probably be changed IMO 12:49:45 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. 12:49:47 Having the tx invalidated is bad enough, needing to wait a week to resend is even worse 12:50:20 Manual flushing of the nodes mempool will clear them iiuc 12:50:47 Yes but the whole network or at least the miners need to do that 12:51:18 True.. enforce DNS mempool flushing :D 12:51:29 Is that as bad as it sounds? 12:52:11 People who get "reorg'd out" have to have 1 week, as the whole system is set up now? 12:52:14 *have to wait 12:53:18 Yes 12:53:36 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. 12:53:37 Splendid 12:53:48 think* 12:53:49 (I guess I thunk it, too) 12:54:34 Ruck, yes, the old txs become valid if the old chain makes a come-from-behind victory 12:55:39 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 12:55:54 at least, the ones that were prev confirmed. Not sure about mempool txs that were invalid 12:56:35 Instead of flushing: why dont we accept txs like this? Bad privacy cant be the only reason 12:56:54 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... 12:58:41 everyones XMR being locked for a week could increase the price :D 13:00:04 this scenario probably just wasn't factor in when the code was written 15:41:03 unknown if they monitor this channel so maybe post a TL;DR to #monero-research-lounge 15:41:25 that 1 week timeout sounds pretty bad, on top of having txs invalidated 15:42:11 but afaik that needs 10+10 deep reorgs minimum (to invalidate inputs)? 15:42:25 after confirmation 15:42:32 ah no, old tx is left in mempool. F 15:42:41 so 10+ is enough 15:43:08 if tx picks decoys or outputs from exactly the spendable recent set 15:44:06 10+ is enough, particularly if an unlock tx is spent 15:44:13 Unlocked* 15:45:15 Spend -> wait 10 blocks -> spend newly unlocked outputs -> reorg -> soends from newly unlocked txs become invalid 15:47:13 " that 1 week timeout sounds pretty bad, on top of having txs invalidated" invalidating outputs is also an issue in fcmp 15:49:09 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) 15:50:10 if the height it's made at > than height of previous 15:50:19 but this is per key image ... 15:50:29 so it could be replaced by multiple sub txs 16:06:47 it would only allow txpool double spends, right? 16:07:47 as for txs already in blocks we either get the chain back or they are permanently invalid 16:21:44 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 16:22:23 to do a double spend with this method you'd need 20+ reorg 16:22:54 confirmations to be able to use decoy/output + confirmations of your own tx to become spendable 16:23:06 assuming merchant uses 10 block confirmation 16:23:45 if it reorgs less than that, the tx just drops out and re-queues, or it becomes invalid before it would have been spendable 16:25:10 this is for being able to do it without emitting blocks yourself ^ 16:25:36 if you control block emission you are able to have 10+ or even without global output index invalidation 16:30:16 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 16:31:09 By replace the tx I mean mine the double spend in the top block of the reorg 16:34:20 the 20 method allows anyone that knows such a big tx is coming to do it 16:34:31 regardless of miner being on it or not, just needs timing on the double spender 16:41:56 Yeah 19:45:13 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 19:48:46 Resolution tracking can be found here: https://status.matrix.org/#