<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: xmrchain.net/tx/722057795c0d3e3dc72…5f15d5fdb42b7497605faddb53d3e0f74e4

<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.

<rucknium> But it was probably constructed with a ring member 10 blocks deep, then sent to the txpool. Now it's invalid.

<rucknium> Probably due to this index in its first ring: 139579914.

so they never stopped doing 10+

as claimed

I don't see that tx in my mempool yet

Can you get me the blob of that tx ^

<barthman132:matrix.org> Anybody thought they would just arbitrarily not do large reorgs eventually is not serious > <DataHoarder> so they never stopped doing 10+

They did explicitly post about that on their blog like yesterday :D

<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

<rbrunner7> You live dangerously doing so :)

I like their claims that they include txs from the other side too

their blocks had zero tx

<rbrunner7> Oh really? For that famous 18 block reorg?

I mean this last one

<rbrunner7> Ah, ok

but that one, had like 6 txs per block

not 100+ like monero side

<syntheticbird> two options: 1. They are lying. 2. the new fed misconfigured the botnet. I let anyone choose which one is more likely.

<rbrunner7> Wasn't the claim that they copy to pool every 15 seconds? Something can happen during 15 seconds.

<rbrunner7> *copy the pool

it's not relevant, they don't have template space

and they'd have to mine behind monero

The txid + blob + json paste.debian.net/1397186

wait

wrong one

ok, I still don't have it in my mempool

right one. that 44e0efb8f0ef99fda1df3a09dc561702d0ee398bd68e8da2a3fd5bbc4f9a0f0f messed my check up

The transfer was fast too, mini/main mostly witnessed a couple templates

so that tx was made within those 20s it took

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?

<ofrnxmr> Both

Why isn't the invalid tx simply removed from the pool?

old chain could come back

this prevents instant double spends without miner assistance

however, it gets stuck there for a week+ :)

ah ok, 3d chess. How many confirmations before it's removed ?

there aren't confirmations for it as it can't get validated

<ofrnxmr> tokr: 7 days, currently

<ofrnxmr> Were likely going to reduce that to somewhere between 6-24hrs.

<ofrnxmr> i lean towards at least 12hrs, so allow for (employment) shift changes to give time for proper tracking

<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.

<ofrnxmr> this in contrast to dropping it before anyone notices, and when they do notice the $ missing, there is no record of it

But it was never confirmed at a sensible confirmation count

The inputs were, and some of them (or decoys

got invalidated. you don't know which ones

Yes but in the end there's only 1 canonical chain

other one could come back :)

it could be the opposite situation, specially with checkpoints. but 7 days is too much

no not if confimation level is high enough

which in the current situation is 50 or more

it cannot get confirmed, regardless

you can't increase "confirmations"

<ofrnxmr> Yes it can. You can selfish mine for 500blocks and force a reorg

as spending it again could end up also invalidated

just cause you picked decoys

<ofrnxmr> (not datahoarder)

<ofrnxmr> Yes it can come back**

I can set my confirmation level to what ever I like.

that doesn't change how the transaction is made

which by design, takes the 10 block lock to select decoys

Yes I know, - which means a lot of txs gets invalidated on a 10+ reorg. But they won't appear on the reorged chain

reorg logs privatebin.net/?827fb9dbd7b0d967#Gw…AACnppXsDsAZmwUqA89dDJj4Gxtvc8vr3kr

<ofrnxmr:xmr.mx> Missing these lines :P

<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 mrelay.p2pool.observer/e/rriwv7YKTk1jN1JU ]

yep

it was full of

2025-09-18 17:29:27.540 I alternative blockchain size: 11 with cum_difficulty 512143515395354861

2025-09-18 17:29:27.862 E Transaction spends at least one output which is too young

then like 100 lines

<ofrnxmr:xmr.mx> 98 lines, yeah

that was a good estimate!

qubic's block page has been updated with the new reorg blocks.p2pool.observer/block/48907a…945ed7480f2eac9d63e613411722581ea68 irc.gammaspectra.live/bbfc3bb93bdff702/image.png and available event archive SVG is on blocks.p2pool.observer/event/reorg_sep18_10/plot.svg