18:39:12 <br-m> <rucknium> There was a 10-block re-org about an hour and a half ago. This tx is stuck in the txpool, probably because the global output index changed: https://xmrchain.net/tx/722057795c0d3e3dc72f3950c0c915f15d5fdb42b7497605faddb53d3e0f74e4
18:40:14 <br-m> <rucknium> I don't think this tx was confirmed in a block. The chain tip of the orphaned chain has hash 44e0efb8f0ef99fda1df3a09dc561702d0ee398bd68e8da2a3fd5bbc4f9a0f0f. It only containers the coinbase tx.
18:40:59 <br-m> <rucknium> But it was probably constructed with a ring member 10 blocks deep, then sent to the txpool. Now it's invalid.
18:43:21 <br-m> <rucknium> Probably due to this index in its first ring: 139579914.
19:00:22 <DataHoarder> so they never stopped doing 10+
19:00:28 <DataHoarder> as claimed
19:00:56 <DataHoarder> I don't see that tx in my mempool yet
19:01:20 <DataHoarder> Can you get me the blob of that tx ^
19:01:54 <br-m> <barthman132:matrix.org> Anybody thought they would just arbitrarily not do large reorgs eventually is not serious > <DataHoarder> so they never stopped doing 10+
19:02:21 <DataHoarder> They did explicitly post about that on their blog like yesterday :D
19:02:30 <br-m> <rbrunner7> Just for the record: If anybody claims that >=10 block reorgs do mess something up in a real way in Monero, CFB will challenge you to appear on X for a tough talk about your ignorance and/or your lies
19:02:59 <br-m> <rbrunner7> You live dangerously doing so :)
19:03:01 <DataHoarder> I like their claims that they include txs from the other side too
19:03:05 <DataHoarder> their blocks had zero tx
19:03:24 <br-m> <rbrunner7> Oh really? For that famous 18 block reorg?
19:03:31 <DataHoarder> I mean this last one
19:03:37 <br-m> <rbrunner7> Ah, ok
19:03:48 <DataHoarder> but that one, had like 6 txs per block
19:03:57 <DataHoarder> not 100+ like monero side
19:04:04 <br-m> <syntheticbird> two options: 1. They are lying. 2. the new fed misconfigured the botnet. I let anyone choose which one is more likely.
19:04:06 <br-m> <rbrunner7> Wasn't the claim that they copy to pool every 15 seconds? Something can happen during 15 seconds.
19:04:30 <br-m> <rbrunner7> *copy the pool
19:04:52 <DataHoarder> it's not relevant, they don't have template space
19:05:00 <DataHoarder> and they'd have to mine behind monero
19:08:57 <DataHoarder> The txid + blob + json https://paste.debian.net/1397186/
19:09:15 <DataHoarder> wait
19:09:19 <DataHoarder> wrong one
19:09:36 <DataHoarder> ok, I still don't have it in my mempool
19:10:55 <DataHoarder> right one. that 44e0efb8f0ef99fda1df3a09dc561702d0ee398bd68e8da2a3fd5bbc4f9a0f0f messed my check up
19:17:19 <DataHoarder> The transfer was fast too, mini/main mostly witnessed a couple templates
19:17:28 <DataHoarder> so that tx was made within those 20s it took
19:32:00 <tokr> So tx get decoys which subsequently gets orphaned. The tx itself gets orphaned and is returned to pool or is still in pool and is no longer a valid tx and is now stuck. Right?
19:32:47 <br-m> <ofrnxmr> Both
19:34:41 <tokr> Why isn't the invalid tx simply removed from the pool?
19:35:00 <DataHoarder> old chain could come back
19:35:12 <DataHoarder> this prevents instant double spends without miner assistance
19:35:40 <DataHoarder> however, it gets stuck there for a week+ :)
19:36:27 <tokr> ah ok, 3d chess. How many confirmations before it's removed ?
19:37:36 <DataHoarder> there aren't confirmations for it as it can't get validated
19:40:40 <br-m> <ofrnxmr> tokr: 7 days, currently
19:42:07 <br-m> <ofrnxmr> Were likely going to reduce that to somewhere between 6-24hrs.
19:42:07 <br-m> <ofrnxmr> i lean towards at least 12hrs, so allow for (employment) shift changes to give time for proper tracking
19:44:29 <br-m> <ofrnxmr> Example: merchant A has a cashier. End of shift, realizes that 18xmr that was previously confirmed is now showing as pending. Now their tech support can make note of the reversed invoices and hopefully resolve it with their customer.
19:44:29 <br-m> <ofrnxmr> this in contrast to dropping it before anyone notices, and when they do notice the $ missing, there is no record of it
19:45:52 <tokr> But it was never confirmed at a sensible confirmation count
19:47:14 <DataHoarder> The inputs were, and some of them (or decoys
19:47:23 <DataHoarder> got invalidated. you don't know which ones
19:49:10 <tokr> Yes but in the end there's only 1 canonical chain
19:50:30 <DataHoarder> other one could come back :)
19:50:47 <DataHoarder> it could be the opposite situation, specially with checkpoints. but 7 days is too much
19:51:04 <tokr> no not if confimation level is high enough
19:51:48 <tokr> which in the current situation is 50 or more
19:51:55 <DataHoarder> it cannot get confirmed, regardless
19:52:01 <DataHoarder> you can't increase "confirmations"
19:52:07 <br-m> <ofrnxmr> Yes it can. You can selfish mine for 500blocks and force a reorg
19:52:09 <DataHoarder> as spending it again could end up also invalidated
19:52:14 <DataHoarder> just cause you picked decoys
19:52:19 <br-m> <ofrnxmr> (not datahoarder)
19:52:35 <br-m> <ofrnxmr> Yes it can come back**
19:54:22 <tokr> I can set my confirmation level to what ever I like.
19:55:25 <DataHoarder> that doesn't change how the transaction is made
19:55:41 <DataHoarder> which by design, takes the 10 block lock to select decoys
19:58:57 <tokr> Yes I know, - which means a lot of txs gets invalidated on a 10+ reorg. But they won't appear on the reorged chain
20:01:24 <DataHoarder> reorg logs https://privatebin.net/?827fb9dbd7b0d967#GwqnKwadoAACnppXsDsAZmwUqA89dDJj4Gxtvc8vr3kr
20:03:33 <br-m> <ofrnxmr:xmr.mx> Missing these lines :P
20:03:33 <br-m> <ofrnxmr:xmr.mx> 2025-09-18 17:29:30.058 I ###### REORGANIZE on height: 3502871 of 3502880 with cum_difficulty 512142958256594465                                                                                                    2025-09-18 17:29:30.058 I  alternative blockchain size: 11 with cum_difficulty 512143515395354861         2025-09-1 [... too long, see https://mrelay.p2pool.observer/e/rriwv7YKTk1jN1JU ]
20:05:03 <DataHoarder> yep
20:05:06 <DataHoarder> it was full of
20:05:09 <DataHoarder> 2025-09-18 17:29:27.540	I  alternative blockchain size: 11 with cum_difficulty 512143515395354861
20:05:09 <DataHoarder> 2025-09-18 17:29:27.862	E Transaction spends at least one output which is too young
20:05:16 <DataHoarder> then like 100 lines
20:07:16 <br-m> <ofrnxmr:xmr.mx> 98 lines, yeah
20:10:48 <DataHoarder> that was a good estimate!
20:11:51 <DataHoarder> qubic's block page has been updated with the new reorg https://blocks.p2pool.observer/block/48907a02142963dcdbd46f6d83503945ed7480f2eac9d63e613411722581ea68  https://irc.gammaspectra.live/bbfc3bb93bdff702/image.png and available event archive SVG is on https://blocks.p2pool.observer/event/reorg_sep18_10/plot.svg