<w​oodser:monero.social> I've always seen that 2 local testnet monerods can occasionally become out of sync with each other during normal mining and usage, causing a bunch of these messages in monerod2:

<w​oodser:monero.social> 2025-12-29 13:42:59.560 I [127.0.0.1:28080 OUT] Sync data returned a new top block candidate: 2523 -> 3044 [Your node is 521 blocks (8.7 hours) behind]

<w​oodser:monero.social> 2025-12-29 13:42:59.560 I SYNCHRONIZATION started

<w​oodser:monero.social> I've never known what randomly causes this, but I have to rollback or reset the blockchain when it happens; the chain seems to be corrupted. it seems to be a bug, which of course we hope could never happen on mainnet. any ideas what could cause this or how to fix it?

<o​frnxmr:xmr.mx> Ive never had that happen

<o​frnxmr:xmr.mx> Is the testnet only 2 daemons?

<o​frnxmr:xmr.mx> interested in output of alt_chain_info

<w​oodser:monero.social> I would need to get the result of alt_chain_info next time it happens in my local environment. I somewhat regularly reproduce this on both my local environment and CI tests in GitHub)

<o​frnxmr:xmr.mx> Are both nodes mining?

<w​oodser:monero.social> no, only one

<o​frnxmr:xmr.mx> Are the blocks big?

<w​oodser:monero.social> no, not many transactions relatively

<w​oodser:monero.social> maybe 200 txs created in my test suite

<w​oodser:monero.social> actually more like 300

<o​frnxmr:xmr.mx> i was more on the angle of serialization limits being unable to pull the next batch of blocks. But it shouldnt have gotten stuck. Is the 2523 number increasing (slowly)? Or stuck stuck

<w​oodser:monero.social> completely stuck

<o​frnxmr:xmr.mx> And were both nodes at 2523 at the same time? (ie, this is the point where they split), or did it start falling behind before that. And only 2 nodes on the testnet?

<o​frnxmr:xmr.mx> checking sync_info and increasing the log level to 2 can both shed more light on the state (what blocks it has queued) and why its failing to sync 2524

<w​oodser:monero.social> I think they're in sync before the split happens. there's only 2 testnet nodes (briefly a third testnet node for one test which is stopped)

<o​frnxmr:xmr.mx> When there is only 1 peer, it only syncs 1 batch at a time, so i dont expect the queue to have more than the next batch, likely has nothing downloaded since its failing

<o​frnxmr:xmr.mx> (sync_info)

<w​oodser:monero.social> I can try to capture with log level 2 and check sync_info for next time it happens

<w​oodser:monero.social> was able to capture when the sync issue happens with log level 2: paste.debian.net/hidden/ef422713

<w​oodser:monero.social> it's happening during a stress test which submits many txs to the pool and flushes them, plus normal submit and relay

<w​oodser:monero.social> notable errors, in order of appearance, which repeat:

<w​oodser:monero.social> 2025-12-29 15:40:05.273 E Block recognized as orphaned and rejected, id = <faa23df5624f0a88f43f4342ce6b7839033e84d04393474f9626c14881663dd1>, height 14915, parent in alt 0, parent in main 0 (parent <039038af674b6e7394f06cfd5b53bba5aae8fb6a7960986835500c989c645a0b>, current top <441e0ef0f9ab347466eea51ce481743bd2deab27b3900b757faba69a8e346f2b>, chain height 14915)

<w​oodser:monero.social> 2025-12-29 15:40:05.283 E [127.0.0.1:63560 INC] Sent invalid chain

<w​oodser:monero.social> 2025-12-29 15:40:08.479 I [127.0.0.1:57617 INC] Sync data returned a new top block candidate: 14915 -> 14917 [Your node is 2 blocks (2.0 minutes) behind]

<w​oodser:monero.social> 2025-12-29 15:40:08.479 I SYNCHRONIZATION started

<w​oodser:monero.social> 2025-12-29 15:40:08.481 W monerod is now disconnected from the network

<w​oodser:monero.social> the result of monerod1 sync_info:

<w​oodser:monero.social> {"height":15095,"targetHeight":0,"nextNeededPruningSeed":4,"credits":0}

<w​oodser:monero.social> the result of monerod2 sync_info (where the errors appear):

<w​oodser:monero.social> {"height":14915,"spans":[{"connectionId":"a16ede9aa06b45c9ae80e63f498f4a4b","numBlocks":68,"remoteAddress":"127.0.0.1:28080","rate":7316212,"speed":100,"size":20075,"startHeight":15014}],"targetHeight":0,"nextNeededPruningSeed":4,"credits":0}

<o​frnxmr:monero.social> Any idea how 14915 was orphaned?

<o​frnxmr:monero.social> Looks like back-to-back reorgs, and failed after trying to reorg onto orphan

<o​frnxmr:monero.social> Same thing happens when using checkpoints to try to reinstate an alt chain that was orphaned

<o​frnxmr:monero.social> cc [@jberman:monero.social](https://matrix.to/#/@jberman:monero.social) [@jeffro256:monero.social](https://matrix.to/#/@jeffro256:monero.social)

<w​oodser:monero.social> I do see that a block was added as alternative at 14914:

<w​oodser:monero.social> 2025-12-29 15:40:00.554 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 14914

<w​oodser:monero.social> 2025-12-29 15:40:00.554 I id: <441e0ef0f9ab347466eea51ce481743bd2deab27b3900b757faba69a8e346f2b>

<w​oodser:monero.social> 2025-12-29 15:40:00.554 I PoW: <c43d1389442fcb9514e84c12dee0e487681c2b263b32a832b5bfbbdf1ec55300>

<w​oodser:monero.social> 2025-12-29 15:40:00.554 I difficulty: 500

<w​oodser:monero.social> which is surprising since only monerod1 is mining. that's the only alternative block added

<o​frnxmr:xmr.mx> I imagine this is the block that monerod1's chain builds on

<o​frnxmr:xmr.mx> amd was the chain that monerod2 was originally on

<r​ucknium:monero.social> binarybaron: Thanks. Sounds like it is the established protocol, but more forgiving of mistakes or temporary disconnections if the counterparty chooses to cooperate.

<r​ucknium:monero.social> During the debate about limiting tx_extra size, there was a popular misconception that atomic swaps required tx_extra. If you use tx_extra to carry messages, that misconception will become correct :D. You could talk to kayabanerve about it because Serai planned to use tx_extra for some info, AFAIK.

<o​frnxmr:xmr.mx> iiuc, its still bad for privacy to use tx for a service, since those txs are obv a different size as compared to a normal tx

<o​frnxmr:xmr.mx> To use tx_extra*

for a game, i wanted to shove a bunch of data into the tx_extra of random transactions :P

and have people find the transactions and put together the data

<o​frnxmr:xmr.mx> imm start a cex and start putting ppl's tax ids in the tx_extras

<r​ucknium:monero.social> Someone once put the script of _A Bee Movie_ into the tx_extra of a tx.

<o​frnxmr:xmr.mx> And the mrl logs

<r​ucknium:monero.social> Here's an old analysis of the tx_extra contents: github.com/noncesense-research-lab/…_tx_extra/blob/master/ascii_data.md

<r​ucknium:monero.social> > There are hundreds of messages, ranging from jokes to vulgarity. MANY include PII such as names, handles, transaction amounts, credit card info, and contact information

to shove an entire copy of super mario wonder into the monero blockchain

it would take 4,558,338 transactions

<o​frnxmr:xmr.mx> At ~1kb per tx? U sure?

yes

<o​frnxmr:xmr.mx> i woukd have guessed that super mario world was like 256kbb

super mario WONDER :P

the switch game

<o​frnxmr:xmr.mx> I thought it was a typo

lmao

also no, super mario world is 4 MB

<o​frnxmr:xmr.mx> I didnt know such blasphemy existed

it's a HiROM

<o​frnxmr:xmr.mx> Super mario world for nintendo color was 4mb?

<o​frnxmr:xmr.mx> super nintentdo**

i'm dumb, it's close to 1MB

<o​frnxmr:xmr.mx> 4 megabits

but wouldn't be much fun, cuz it wouldn't attract the attention of nintendo lawyers

<k​ayabanerve:matrix.org> Serai does expect a small (probably just ~100 bytes) amount of data in a Nonce field in TX extra. It's very friendly to the existing extra definition.

i wonder if before the tx_extra limit was added to monerod, did anyone sneak in a copy of a video game into the blockchain

other than a PDF and the script for the bee movie

<g​emmakarlson:matrix.org> hi everyone, I am experiencing problems with an outgoing transaction and cant find the txid of the said transaction ( never arrived ), when I try to get it using get_tx_key in the monero CLI wallet I get Error: no tx keys found for this txid, however the transaction was sent from this wallet, how can I retrieve the tx key?

<o​frnxmr:xmr.mx> Did you send it with monero cli?

<g​emmakarlson:matrix.org> Not unfortunately, it was sent using a third party wallet.

<o​frnxmr:xmr.mx> You can only get the txkey from the wallet that sent the transfer

<g​emmakarlson:matrix.org> I have access to the wallet but is a third party hot wallet and the information is not shown in the wallet. I imported the wallet to multiple wallets but its impossible to see.

<g​emmakarlson:matrix.org> The wallet provider is not answering any emails, my concern is that my xmr is gone forever.

<o​frnxmr:xmr.mx> come to Monero Support, dev is the wrong place for this convo

<g​emmakarlson:matrix.org> Thank you very much.

last chance to get something included in v0.18.4.5, I plan to tag in the next days

<o​frnxmr:xmr.mx> Would a backport if this be ok? monero-project/monero #9808

<o​frnxmr:xmr.mx> Not having colors is a bit annoying sonetimes

yes, can you open a PR for it?

<o​frnxmr:xmr.mx> Yup

sech1: PowerPC JIT?

.merge+ #10255 #10254 #10257 #10256 #10262 #10263

Added

but what machine?

Too exotic

i guess i could mine on a devkit PS3

mine with light mode

ofrnxmr: seems something does not compile

sech1: why does the draft PR say it then :P

or maybe it's just intrinsics

Just intrinsics, no JIT

ofrnxmr: I guess you can remove the changes to tests/unit_tests/logging.cpp, then it should compile. we have the test cases on master anyway.

.merge+ 10252

Added

ofrnxmr: please squash, it will compile now

<o​frnxmr:xmr.mx> Ok, i was just going to wait for it to compile before squashing

.merge+ 10268

Added

done

ty

we need people testing a full chain sync, i will start one later today

<o​frnxmr:xmr.mx> Any comments on monero-project/monero #10240 ?

<o​frnxmr:xmr.mx> in my short tests, it speeds up sync by 30-70%.

<o​frnxmr:xmr.mx> In 2015, this was introduces as "minimum of 4 or max available threads". Obviously all yhese years later, we have 8, 16 etc threads as standard on consumer hardware and i think its a bit stupid to limit to 4

<o​frnxmr:xmr.mx> Speeds up when syncing w/o checkpoints**

do you want to include it in the release?

change looks ok

<o​frnxmr:xmr.mx> yeah, would be nice

jberman: could you review 10240?

change itself looks easy but i don't know what it does exactly

<o​frnxmr:xmr.mx> I don't know what exactly it does, aside from the observation that cpu usage from from barely using 4 cores, to using all cores and sync speeds up dramatically