blocks.p2pool.observer now shows when Tari blocks have been merge mined (and shows a link in the block page to view merge mined block) irc.gammaspectra.live/e41d34f0a348a173/image.png + example blocks.p2pool.observer/block/5fde6c…393b4a3d05ab35531bf759e5c1b320eddd0

<interestingband:matrix.org> Do you still think it wasn't for profit ? > <@ofrnxmr> Were not dealing with a profit driven attack

👍 Rucknium can we gain loose consensus that this is factual (to then be a blog post on getmonero surely) <@Datahoarder>: I have made this Timeline of Monero 18-block reorg on September 14th, 2025 github.com/WeebDataHoarder/Monero-Timeline-Sep14"

^ feel free to use the data logs and tables. Strip the intro header text as desired

The data ... well it's there. Hex blobs for block headers and for the transactions. The only mismatch would be the number of transactions - 115 invalidated vs 117 invalidated other people talk about

There might be more invalidated but those could have just been in the mempool-never made them to blocks

As such I don't have the txids readily nor an easy way to prove they existed at that point in time

And if anyone has monerod logs from that time, the reorg section would be relevant.

Timestamps for blocks obtained via ZMQ on arrival, not from their timestamp in header

<privacyx> mrelay.p2pool.observer/m/monero.social/NGLbxgRRXxvcwyEPCoJNZxeV.png (1000243732.png)

<privacyx> Are refering to this

<privacyx> mrelay.p2pool.observer/m/monero.social/qxwdqqeoFrAdaJpirgzWHPuH.png (1000243734.png)

I mean a node operator can show the reorg existed by logs alone

<privacyx> This my node logs

That timestamp you fetched is from block template creation

It will mismatch as block solution nonces are found later than that, then broadcasted

They should be within some seconds-minutes of them

<privacyx> Ok I see if find them in my logs

The way to verify the Tari inclusion is a bit more complex if you want to get the block id. I have added the relevant code to blocks.p2pool.observer, but the easiest way is to check the PoW hash of both sides (this gets prominently displayed usually)

Meanwhile x.com/c___f___b/status/1968195867770552507

> The level of incompetence in github.com/WeebDataHoarder/Monero-Timeline-Sep14 is baffling. Or the author lied. I invite him to an open debate on X.

Another point, is that p2pool miners included these transaction in templates as witnesses as well (another sidechain) plus the monero id of the orphaned blocks

This part felt redundant but these were included across main/mini/nano miners (and even some of the not updated p2pool chains!)

This is the last P2Pool Mini block before the reorg mini.p2pool.observer/share/c3411e7d…93cf41a9a786cc154961396c22c496a1e94

Sorry wrong link. mini.p2pool.observer/share/382aed1a…7ca653c44320dc51263112596565cb8ebbb

This block dump is mini.p2pool.observer/api/block_by_i…3c44320dc51263112596565cb8ebbb/full

It also includes yet another unknown transaction 7fa69b04b6c7d1aae9c8b84c7b9a540f4c4de024f5354c5f442c26809372e520 which is probably an invalidated one

<privacyx> Im sorry i though i could help I discovered my logs level was set to 0 so im no good

log level 0 still prints reorgs and depth

start/end as well

<privacyx> Ok i give it another go as my setup is as systemd

12:09:31 <br-m> <privacyx> mrelay.p2pool.observer/m/monero.social/NGLbxgRRXxvcwyEPCoJNZxeV.png (1000243732.png)

this has it

the reorganize on height

59 -> 78

<ofrnxmr:xmr.mx> @interestingband:matrix.org: Yes

<privacyx> mrelay.p2pool.observer/m/monero.social/haftrCvPHyRSLtHoBZbiDfHz.png (Screenshot 2025-09-17 214127.png)

<privacyx> mrelay.p2pool.observer/m/monero.social/YBoLBCWVPzjzXoeYfdGTdYOF.png (Reorg 14092025.png)

<privacyx> This all I could find in my logs are they helpful

<321bob321> Rude word in the log

privacyx:monero.social, yeah those timestamps match the disclosure time I have locally

I have provided the logs of my events as well

<rucknium> I'm using invalidated transaction cb559fa19ab075e6e9e7e0220289da4fa1f77914e9af661e3369d574c4fff8f9 as a case study for what happened during the re-org.

<rucknium> The youngest ring member in its single input has global output index 139283819.

The transaction for others blocks.p2pool.observer/tx/cb559fa19…f77914e9af661e3369d574c4fff8f9/json

<rucknium> In the honest chain that was re-orged, this index points to:

it was included as part of orphaned block 3499672 blocks.p2pool.observer/block/66736b…a5dac2c55c11d076684975fa62476f74e9d

<rucknium> mrelay.p2pool.observer/p/kPjwibYKbWh1Z1cw/1.txt (code snippet, 4 lines)

<rucknium> In the main chain now, after the malicious re-org, the index points to:

<rucknium> mrelay.p2pool.observer/p/1sj0ibYKcVlNNUJQ/1.txt (code snippet, 4 lines)

<rucknium> Since the output public keys are different, the signature is invalid and the transaction cannot be confirmed on the main chain blockchain.

<rucknium> I will try to show that the signature is invalid with some Rust functions, but that would take a while to figure out. I will probably do a write-up without the Rust.

<rucknium> DataHoarder: Right. You can calculate the global output indices by computing a cumulative sum on the key_offsets. The last one is: 107324833 + 25163987 + 5140812 + 1061458 + 460873 + 90679 + 27 + 9441 + 9463 + 10674 + 1387 + 1372 + 2451 + 1747 + 3100 + 1515 = 139283819

Yeah, I have this code somewhere for observer already

<rucknium> If you view the transaction in a block explorer that still has it in its txpool, you will see that the block explorer thinks that the final ring member in the ring points to output c15f94b62df70d7ef044414ea48f6e099d3fe609fb032d19590cccfd2fa664f5 explorer.xmr.mx/tx/cb559fa19ab075e6…fa1f77914e9af661e3369d574c4fff8f9/1

<rucknium> I mean, points to output public key.

<rucknium> The transaction's own data only has the key_offsets, so the block explorer is erroneously pointing to the wrong output public key.

<rucknium> Block explorers like this one sometimes refer to the output public key as a "stealth address".

<rucknium> Reconstructing the global output index for the orphaned chain wasn't trivial, but wasn't too difficult, either.

As an alternative you could pop_blocks before the reorg, then submit_block all the saved templates, along with all its transactions

Then use the RPC to get values, and you have a node with this chain verified

FYI, they are attempting to take down the event archive, and dox me currently, they want it taken down :)

rucknium: I could build a json dump of all the indices they refer to by manually building this chain in code, if that's useful. would take a bit but I do have the code for it (why did past me write all these utilities?)

<rucknium> Take down the event archive? You mean the GitHub repo?

yep, they don't like it

<rucknium> You have it mirrored in 3 places at least IIRC

the event archive is only there on git, but it's a git repo which can be mirrored yeap

(and it's also signed!)

git clone it as it has the relevant block and tx data as well

<rucknium> Here's my draft code that reconstructs the output index for the orphaned chain and outputs the info for a specified invalidated tx: gist.github.com/Rucknium/d055e95c92b66ba7109194720e9dff2e

<rucknium> Your monerod needs the orphaned chain as an alt chain and the invalidated tx in its txpool.

<rucknium> I think I already do this in my draft R code. I mean, I do something in my draft R code and I think it's the same thing you're offering to do. > <DataHoarder> Rucknium: I could build a json dump of all the indices they refer to by manually building this chain in code, if that's useful. would take a bit but I do have the code for it (why did past me write all these utilities?)

if you don't want to use pop_blocks - this patch allows using submit_block RPC for lower depths irc.gammaspectra.live/f5571b32f03eb…6e166d835fb737f2f5dfe531780cc.patch

anyone that wants to verify can use a regular monero node and if they are missing the blocks ^ insert them via that

plus the missing transactions, but that already works via RPC

maybe we can post a concrete explainer using this, rucknium?

if it's only this specific example I can see slides working well

with showing the index as a "pointer" and replacing the square it points at

<rucknium> Which slides?

<rucknium> My plan is to use this (or another) tx for an explainer for my blog. Potentially later for getmonero.org if that's desired. The tone of my blog and getmonero.org would be different.

whoever this is trying to make threats

15:59:08 <m-relay> <w​agonbundle:matrix.org> dkat revealed the technical details. I won't share more info unless Monero devs cooperate, remove their false claims about Qubic, and promise not to report CFB or Qubic, causing delistings.

<rucknium> I need to make the diagrams. I will look into the privacy issue with reconstruction of rings, too. I think there are probably examples already on the blockchain, but I need to collect them.

<kill-switch:matrix.org> It seems reasonable to have a step by step walkthrough of sorts explaining the situation that could be followed by anyone who would have submitted those transactions or been on the other side of the transaction and that might have sent goods/services that weren't payed for (or how any user could be effected in the same way in the future); how the privacy of the sender is damaged, etc

<ofrnxmr> @anhdres:matrix.org draws good this type of stuff pretty good

<ofrnxmr> Ofrnenglish talks kinda bad sometimes

<anhdres:matrix.org> @rucknium:monero.social ping me if you want help

<rucknium> @anhdres:matrix.org: Thanks. Maybe I can sketch something out and you can complete it?

<anhdres:matrix.org> sure, how much time would I have? because I'd need to do this after work

<rucknium> @anhdres:matrix.org: Probably 36 to 48 hour turnaround time from when you receive the sketch. Does that sound alright?

<anhdres:matrix.org> should be alright. It'd depend on the complexity and amount of artwork but I guess it's not gonna be super fancy

<anhdres:matrix.org> count me in, glad to help

<ofrnxmr:xmr.mx> @anhdres:matrix.org: your subaddress/subaccount sketches were fire

<rucknium> Thank you!

<ofrnxmr:xmr.mx> I google them anytime someone asks me to explain

<rucknium> I think one or more inputs of about half of the invalidated txs have been spend in valid txs now.

did you get a match on key image?

<rucknium> I looked for the key images of the inputs of the invalidated txs in the main chain. I found 58 transactions that spent inputs that had these key images from the invalidated transactions.

<rucknium> That's the exact number of "double spends" I see when I print_pool_stats.

<rucknium> As expected, the node labels those invalidated transactions that have now had their inputs spent in different transactions as "double spends".

<rucknium> I will work on a privacy analysis of rings. I assume I (and any observer) can deduce the real spends of all of the rings associated with those key images.

58 double spends, 0 not relayed, 0 failing, 115 older than 10 minutes (oldest 3 days ago), estimated 2 block (4 minutes) backlog

I see the same on my witness node

This answers the query of "where are the double spends" ^ they just took some time

<ofrnxmr:xmr.mx> @rucknium: they are double spends :P

<ofrnxmr:xmr.mx> Node that has the invalid tx in mempool sees an incoming node sending another tx that spends the same key images = rejects the incoming tx as a double spend

Have they been mined in blocks now?

<rucknium> All in blocks. I will send the CSV in a moment

<rucknium> I think they can exist in the same node because they are double-spends. The node won't reject a valid block (which has the key image o a tx that is already in the txpool). The node will still keep the invalid tx in the txpool.

<rucknium> I think

The chain might reorg back :)

<rucknium> DataHoarder: Here's the CSV: gist.github.com/Rucknium/d055e95c92…9dff2e#csv-file-of-spent-key-images

Thanks. I'll add this to a section in my gh repo (probably a different page) for now, if that's ok

<rucknium> Outputs that are spent in a single invalidated tx are not necessarily spent in a single valid tx later.

you'll get quoted as source :)

<rucknium> DataHoarder: Sounds good to me.

yeah, the inputs could be spread or swept

<rucknium> The code there should work fine to produce the CSV file as long as you didn't flush your txpool

I'll attempt to just talk about key image -> invalid txid : input index => valid txid : input index

I have the txpool and transactions :)

If a blogpost is being prepared > web.archive.org/web/20250917162408/…poch-178-recap-profitability-update

> Since the centralized exchanges increased their confirmation times, the 18 block reorg was safe to perform but it points to the existing problem in the Monero chain.

(no, it was not)

> Interestingly, Qubic and Monero developers are working together in Qubic Discord to figure out the details of this event, and the Qubic team is in discussion to place a voluntary limit on reorganizations to a maximum of 9 blocks once again. This proves Qubic’s “white hat” intentions once again.

(no, devs and most people are banned there)

I'm going to link docs.getmonero.org/cryptography/asymmetric/key-image for key image explainer, any better source than the PDF papers?

<rucknium> DataHoarder: This maybe: youtube.com/watch?v=TlVsMTeT_nE

<rucknium> And PDF/paper: moneroresearch.info/45 Wijaya, D. A., Liu, J. K., Steinfeld, R., Liu, D., & Yu, J. 2019, On The Unforkability of Monero.

I was trying to have a two liner in there :D

<rucknium> About the privacy impacts

I'll have the YT one

<rucknium> monero.stackexchange.com/questions/…and-how-is-it-different-than-monero

<datahoarder> mrelay.p2pool.observer/m/monero.social/GcTyAExWjfOwFHKuhTWUEbgY.png (image.png)

Development of a Book on a Finality Layer has moved to funding! ccs.getmonero.org/proposals/kayabaNerve-finality-layer-book.html

<321bob321> Is monerov, just monero injected with compound v ? To make a super hero.

<testtank:matrix.org> Does this mean that Serai development will get pushed back? @kayabanerve:monero.social

<testtank:matrix.org> n1oc: Does this mean that Serai development will get pushed back? @kayabanerve:monero.social

<kayabanerve:matrix.org> Somewhat. I generally have a few items I work on, as to give me something else to work on when I'm exhausted with one topic, but this is of a scale and a priority it'll take an extra week or two.