13:52:00 <m-relay> <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:
13:52:00 <m-relay> <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] 
13:52:02 <m-relay> <w​oodser:monero.social>   2025-12-29 13:42:59.560	I SYNCHRONIZATION started
13:52:04 <m-relay> <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?
13:52:43 <m-relay> <o​frnxmr:xmr.mx> Ive never had that happen
13:52:57 <m-relay> <o​frnxmr:xmr.mx> Is the testnet only 2 daemons?
13:55:07 <m-relay> <o​frnxmr:xmr.mx> interested in output of alt_chain_info
13:59:00 <m-relay> <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)
13:59:40 <m-relay> <o​frnxmr:xmr.mx> Are both nodes mining?
13:59:54 <m-relay> <w​oodser:monero.social> no, only one
14:01:21 <m-relay> <o​frnxmr:xmr.mx> Are the blocks big?
14:01:47 <m-relay> <w​oodser:monero.social> no, not many transactions relatively
14:02:20 <m-relay> <w​oodser:monero.social> maybe 200 txs created in my test suite
14:03:25 <m-relay> <w​oodser:monero.social> actually more like 300
14:03:36 <m-relay> <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
14:04:10 <m-relay> <w​oodser:monero.social> completely stuck
14:05:00 <m-relay> <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?
14:06:29 <m-relay> <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
14:06:32 <m-relay> <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)
14:08:34 <m-relay> <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
14:09:03 <m-relay> <o​frnxmr:xmr.mx> (sync_info)
14:09:14 <m-relay> <w​oodser:monero.social> I can try to capture with log level 2 and check sync_info for next time it happens
16:34:34 <m-relay> <w​oodser:monero.social> was able to capture when the sync issue happens with log level 2: https://paste.debian.net/hidden/ef422713
16:35:51 <m-relay> <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
16:38:36 <m-relay> <w​oodser:monero.social> notable errors, in order of appearance, which repeat:
16:38:36 <m-relay> <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)
16:38:38 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:05.283	E [127.0.0.1:63560 INC] Sent invalid chain
16:38:40 <m-relay> <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] 
16:38:42 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:08.479	I SYNCHRONIZATION started
16:38:44 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:08.481	W monerod is now disconnected from the network
16:46:19 <m-relay> <w​oodser:monero.social> the result of monerod1 sync_info:
16:46:20 <m-relay> <w​oodser:monero.social> {"height":15095,"targetHeight":0,"nextNeededPruningSeed":4,"credits":0}
16:46:22 <m-relay> <w​oodser:monero.social> the result of monerod2 sync_info (where the errors appear):
16:46:24 <m-relay> <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}
17:07:30 <m-relay> <o​frnxmr:monero.social> Any idea how 14915 was orphaned?
17:08:29 <m-relay> <o​frnxmr:monero.social> Looks like back-to-back reorgs, and failed after trying to reorg onto orphan
17:09:55 <m-relay> <o​frnxmr:monero.social> Same thing happens when using checkpoints to try to reinstate an alt chain that was orphaned
17:10:48 <m-relay> <o​frnxmr:monero.social> cc [@jberman:monero.social](https://matrix.to/#/@jberman:monero.social) [@jeffro256:monero.social](https://matrix.to/#/@jeffro256:monero.social)
17:36:13 <m-relay> <w​oodser:monero.social> I do see that a block was added as alternative at 14914:
17:36:14 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:00.554	I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 14914
17:36:16 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:00.554	I id:	<441e0ef0f9ab347466eea51ce481743bd2deab27b3900b757faba69a8e346f2b>
17:36:18 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:00.554	I PoW:	<c43d1389442fcb9514e84c12dee0e487681c2b263b32a832b5bfbbdf1ec55300>
17:36:20 <m-relay> <w​oodser:monero.social> 2025-12-29 15:40:00.554	I difficulty:	500
17:36:52 <m-relay> <w​oodser:monero.social> which is surprising since only monerod1 is mining. that's the only alternative block added
17:42:34 <m-relay> <o​frnxmr:xmr.mx> I imagine this is the block that monerod1's chain builds on
17:43:27 <m-relay> <o​frnxmr:xmr.mx> amd was the chain that monerod2 was originally on
17:52:20 <m-relay> <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.
17:52:20 <m-relay> <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.
17:55:30 <m-relay> <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
17:55:52 <m-relay> <o​frnxmr:xmr.mx> To use tx_extra*
17:56:01 <Cindy> for a game, i wanted to shove a bunch of data into the tx_extra of random transactions :P
17:56:13 <Cindy> and have people find the transactions and put together the data
17:56:48 <m-relay> <o​frnxmr:xmr.mx> imm start a cex and start putting ppl's tax ids in the tx_extras
17:56:53 <m-relay> <r​ucknium:monero.social> Someone once put the script of _A Bee Movie_ into the tx_extra of a tx.
17:57:08 <m-relay> <o​frnxmr:xmr.mx> And the mrl logs
18:02:17 <m-relay> <r​ucknium:monero.social> Here's an old analysis of the tx_extra contents: https://github.com/noncesense-research-lab/monero_tx_extra/blob/master/ascii_data.md
18:02:18 <m-relay> <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
18:02:38 <Cindy> to shove an entire copy of super mario wonder into the monero blockchain
18:02:47 <Cindy> it would take 4,558,338 transactions
18:03:19 <m-relay> <o​frnxmr:xmr.mx> At ~1kb per tx? U sure?
18:03:32 <Cindy> yes
18:03:42 <m-relay> <o​frnxmr:xmr.mx> i woukd have guessed that super mario world was like 256kbb
18:03:52 <Cindy> super mario WONDER :P
18:03:52 <Cindy> the switch game
18:04:04 <m-relay> <o​frnxmr:xmr.mx> I thought it was a typo
18:04:15 <parazyd> lmao
18:04:18 <Cindy> also no, super mario world is 4 MB
18:04:19 <m-relay> <o​frnxmr:xmr.mx> I didnt know such blasphemy existed
18:04:22 <Cindy> it's a HiROM
18:05:04 <m-relay> <o​frnxmr:xmr.mx> Super mario world for nintendo color was 4mb?
18:05:34 <m-relay> <o​frnxmr:xmr.mx> super nintentdo**
18:05:43 <Cindy> i'm dumb, it's close to 1MB
18:06:04 <m-relay> <o​frnxmr:xmr.mx> 4 megabits
18:06:35 <Cindy> but wouldn't be much fun, cuz it wouldn't attract the attention of nintendo lawyers
18:20:53 <m-relay> <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.
18:23:02 <Cindy> 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
18:23:15 <Cindy> other than a PDF and the script for the bee movie
20:05:56 <m-relay> <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?
20:15:12 <m-relay> <o​frnxmr:xmr.mx> Did you send it with monero cli?
20:34:54 <m-relay> <g​emmakarlson:matrix.org> Not unfortunately, it was sent using a third party wallet.
20:36:10 <m-relay> <o​frnxmr:xmr.mx> You can only get the txkey from the wallet that sent the transfer
20:39:21 <m-relay> <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.
20:40:00 <m-relay> <g​emmakarlson:matrix.org> The wallet provider is not answering any emails, my concern is that my xmr is gone forever.
20:41:46 <m-relay> <o​frnxmr:xmr.mx> come to Monero Support, dev is the wrong place for this convo
20:45:46 <m-relay> <g​emmakarlson:matrix.org> Thank you very much.
21:30:40 <selsta> last chance to get something included in v0.18.4.5, I plan to tag in the next days
21:30:54 <selsta> https://github.com/monero-project/monero/issues/10261
21:32:31 <m-relay> <o​frnxmr:xmr.mx> Would a backport if this be ok? https://github.com/monero-project/monero/pull/9808
21:32:32 <m-relay> <o​frnxmr:xmr.mx> Not having colors is a bit annoying sonetimes
21:36:14 <selsta> yes, can you open a PR for it?
21:37:26 <m-relay> <o​frnxmr:xmr.mx> Yup
21:55:35 <sech1> https://www.reddit.com/r/Monero/comments/1pyzdpc/randomx_v2_update/
22:09:41 <Cindy> sech1: PowerPC JIT?
22:09:44 <selsta> .merge+ #10255 #10254 #10257 #10256 #10262 #10263
22:09:44 <xmr-pr> Added
22:09:48 <Cindy> but what machine?
22:10:12 <sech1> Too exotic
22:10:29 <Cindy> i guess i could mine on a devkit PS3
22:10:45 <Cindy> mine with light mode
22:10:45 <selsta> ofrnxmr: seems something does not compile
22:12:07 <Cindy> sech1: why does the draft PR say it then :P
22:12:12 <Cindy> or maybe it's just intrinsics
22:14:16 <sech1> Just intrinsics, no JIT
22:14:29 <selsta> 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.
22:26:08 <selsta> .merge+ 10252
22:26:08 <xmr-pr> Added
22:27:18 <selsta> ofrnxmr: please squash, it will compile now
22:28:50 <m-relay> <o​frnxmr:xmr.mx> Ok, i was just going to wait for it to compile before squashing
22:39:29 <selsta> .merge+ 10268
22:39:29 <xmr-pr> Added
22:42:14 <tobtoht> done
22:47:55 <selsta> ty
22:49:03 <selsta> we need people testing a full chain sync, i will start one later today
22:50:11 <m-relay> <o​frnxmr:xmr.mx> Any comments on https://github.com/monero-project/monero/pull/10240 ?
22:50:12 <m-relay> <o​frnxmr:xmr.mx> in my short tests, it speeds up sync by 30-70%.
22:50:14 <m-relay> <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
22:51:11 <m-relay> <o​frnxmr:xmr.mx> Speeds up when syncing w/o checkpoints**
22:52:55 <selsta> do you want to include it in the release?
22:53:07 <selsta> change looks ok
22:53:22 <m-relay> <o​frnxmr:xmr.mx> yeah, would be nice
23:06:00 <selsta> jberman: could you review 10240?
23:06:20 <selsta> change itself looks easy but i don't know what it does exactly
23:07:55 <m-relay> <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