17:02:30
rbrunner7:monero.social:
Meeting in a bit less than 1 hour
17:59:42
rbrunner7:monero.social:
Meeting time. Hello! https://github.com/monero-project/meta/issues/1311
18:00:19
sneedlewoods_xmr:matrix.org:
hey
18:02:15
rbrunner7:monero.social:
Hmm ... people busy Christmas shopping maybe :)
18:02:31
jberman:monero.social:
*waves*
18:02:32
jberman:monero.social:
sorry
18:02:56
rbrunner7:monero.social:
Alright, what are the reports about last week?
18:03:18
sneedlewoods_xmr:matrix.org:
while updating https://github.com/monero-project/monero-gui/pull/4437 I also fixed some issues I didn't notice before
18:03:25
sneedlewoods_xmr:matrix.org:
began to look back into the problem with setting restore height on wallet creation with the GUI
18:03:26
sneedlewoods_xmr:matrix.org:
also wrote a CCS proposal, but haven't made a merge request yet. Maybe someone wants to have a look first and give feedback https://repo.getmonero.org/SNeedlewoods/ccs-proposals/-/blob/SNeedlewoods-03_part-time_dev_work-Q1-26/SNeedlewoods-03_part-time_dev_work-Q1-26
18:04:23
rbrunner7:monero.social:
Do you have something reviewable already for the Wallet API and the use of that in the CLI wallet?
18:05:45
rbrunner7:monero.social:
Will have a look at your CCS proposal
18:05:46
sneedlewoods_xmr:matrix.org:
Not sure I understand, but this is "reviewable" I guess https://github.com/monero-project/monero/pull/10233
18:06:37
rbrunner7:monero.social:
I mean you don't plan to immediately change it again significantly, what could make an on-going review invalid so to say
18:08:05
jberman:monero.social:
Solved some lingering issues with the daemon/wallet2 noticed during stressnet (sporadic repeated double spend errors in the wallet, some connection drop issues), investigated/identified a cause of what looked like a regression in sync perf (depends builds are slow, GUIX builds fast), implemented jeffro's review comments on multithreaded verify. Continuing this week with tx relay v<clipped messag
18:08:06
jberman:monero.social:
2, getting all outstanding PR's shaped up, and may dig into a segfault reported by ofrn
18:08:08
sneedlewoods_xmr:matrix.org:
the only thing I'm planning to fix is "outgoing pending txs not showing up in `show_transfers`", else it should be pretty much done
18:08:34
sneedlewoods_xmr:matrix.org:
I assume some things will change because of review though
18:09:03
rbrunner7:monero.social:
"tx relay v2" is a pretty big change, right?
18:09:38
rbrunner7:monero.social:
Or maybe I confuse it with something else
18:10:23
jberman:monero.social:
it is, it's mostly implemented by 0xfffc already, but I have some changes in mind pointed out in review that I want to implement
18:11:03
jberman:monero.social:
and plan to work with 0xff on that
18:11:19
jberman:monero.social:
the current PR for reference: https://github.com/seraphis-migration/monero/pull/184
18:11:32
rbrunner7:monero.social:
That could be quite a big step forward
18:11:47
rbrunner7:monero.social:
Especially in times of many transactions
18:12:27
jberman:monero.social:
yep, we also apparently have some relay issues in the daemon, so I want to see this in the daemon first and then tackle the relay issues
18:12:38
jeffro256:monero.social:
Howdy sorry I'm late
18:12:53
rbrunner7:monero.social:
Not sure what you mean with "relay issues"
18:13:05
jberman:monero.social:
https://github.com/seraphis-migration/monero/issues/163
18:13:35
rbrunner7:monero.social:
Ah, ok. Might be present for quite a while already, but only surfacing now
18:13:45
jberman:monero.social:
seems to be the case
18:16:08
jberman:monero.social:
SNeedlewoods: you don't have to lower your paid hours for those reasons. you can include the time you expect to spend working in your proposal fine, no one should have an issue with that
18:16:31
rbrunner7:monero.social:
jeffro256: What kept you busy during last week?
18:17:57
jeffro256:monero.social:
Working on tx knowledge proofs integration (decode, spend, reserve, etc)
18:18:50
rbrunner7:monero.social:
Anything that is significantly more complex now among those because of Carrot?
18:18:52
jeffro256:monero.social:
Hoping to get that done this week
18:20:05
jeffro256:monero.social:
Uh not significantly in term of concepts, but now there's a bit more business logic because of different transactions types, and the difference b/t internal and external enotes. It's also probably going to require some RPC changes to the daemon
18:21:07
rbrunner7:monero.social:
Ok, if that's the worst that happens, quite alright :)
18:21:57
rbrunner7:monero.social:
Alright, anything to discuss beyond reports today?
18:22:58
ofrnxmr:monero.social:
stressnet didnt die with sustained 20+mb blocks
18:23:04
sneedlewoods_xmr:matrix.org:
thanks for your feedback, but I don't think I would feel well asking for more, I would like to give more than I take if possible
18:23:34
ofrnxmr:monero.social:
Main issue is probably that when templates are >2800txs, xmrig has problems connecting, and mining a block with it will crash the node
18:23:43
jberman:monero.social:
your call!
18:24:02
jeffro256:monero.social:
My old desktop server sounding like a jet engine tho
18:24:12
rbrunner7:monero.social:
Lol
18:24:25
ofrnxmr:monero.social:
Mining large blocks were often reorged by empty blocks, so thats potentially an issue - that people can produce artificially small blocks to win the block race
18:24:37
rbrunner7:monero.social:
Finally working like it should have all the time already
18:25:21
sneedlewoods_xmr:matrix.org:
laptop fans been spinning non-stop for days
18:25:54
rbrunner7:monero.social:
Is mining large blocks indeed somehow significantly slower? Where does that slowing happen, is that known?
18:26:12
ofrnxmr:monero.social:
Cpu usage spikes hard when getting alt chains
18:26:20
jberman:monero.social:
very rough idea that probably has problems: maybe difficulty should also factor in n txs
18:26:43
ofrnxmr:monero.social:
Probably can improve that logic to now download alt blocks unless the alt chain is longer than yours.. currently it seems to always download them (and probabky re-verifying the txs in them)
18:26:58
ofrnxmr:monero.social:
to not* download
18:27:41
ofrnxmr:monero.social:
Essentially, your node gets hammered with alt blocks (which could be bullshit attempts at selfish mining) even if your chain is longer
18:28:27
rbrunner7:monero.social:
But those alt blocks need to be correct regarding RandomX?
18:28:32
jberman:monero.social:
alt block handling does need a pass
18:28:59
rbrunner7:monero.social:
Another entry on a long list of such things maybe ...
18:29:00
ofrnxmr:monero.social:
yea, theyre valid blocks, just not an equal or longer chain
18:30:07
rbrunner7:monero.social:
That severly limits the potential to use them as some sort of DoS attack I guess, as long as our code does not handle them with good performance
18:30:46
ofrnxmr:monero.social:
Yeah, not fcmp problem, but ive seen my nodes becomes slightly unresponsive when adding alt blocks that have no chance of overtaking. And if my chain is longer, then my chain should be pushed to the peer. Currently (master) it works fine because the small blocks are sent to them fast enough to force them to reorg, but on stressnet the peer keep mining blocks on their shorter chain<clipped messag
18:30:48
ofrnxmr:monero.social:
before syncing the blocks from the longer chain
18:31:03
ofrnxmr:monero.social:
Reorg doesnt happen until theyve actually synced the final block that surpasses their chain height
18:31:21
ofrnxmr:monero.social:
So you can essentially game this by setting your download speed to something low, so you dont receive blocks fast
18:32:48
ofrnxmr:monero.social:
anyway, not an fcmp issue. Just a big block issue
18:33:38
rbrunner7:monero.social:
Aka "the bug" ... as it was brutally simplified in some Reddit discussions ...
18:34:13
rbrunner7:monero.social:
Correct the "bug", and no more block size limit needed, presto :)
18:34:42
rbrunner7:monero.social:
Well, not everybody can be a dev and know how awfully interconnected things can be
18:36:06
rbrunner7:monero.social:
Alright, looks like we may be through with immediately important things for now. Thanks everybody for attending, read you again next week!
18:38:01
sneedlewoods_xmr:matrix.org:
thanks, see ya
18:39:16
ofrnxmr:monero.social:
I H8 the txpool
18:40:19
ofrnxmr:monero.social:
So many issues stemmed from the pool 🥲
18:42:21
jberman:monero.social:
it's significantly improving with the latest ya?? seems like just the not relayed issue is the last remaining main thing
18:42:48
jberman:monero.social:
and I guess that segfault but I don't think that's a txpool issue
18:44:22
ofrnxmr:monero.social:
I "think" this might be related to v2
18:44:43
jberman:monero.social:
are you running v2?
18:45:00
ofrnxmr:monero.social:
I dropped v2 commits recently, so not anymore
18:45:45
jberman:monero.social:
you were running v2 when you encountered this too? https://github.com/seraphis-migration/monero/issues/163
18:45:55
ofrnxmr:monero.social:
looks like v2 might be relaying txs 1 at a time
18:47:02
ofrnxmr:monero.social:
Honestly not sure. I think no
18:47:15
ofrnxmr:monero.social:
With v2 i was seeing 1000-15000 not relayed
18:47:30
ofrnxmr:monero.social:
Honestly not sure. I think not
18:49:11
jberman:monero.social:
the current v2 PR has an issue where it silently stops relaying >100 txs
18:49:33
jberman:monero.social:
which is one of the things I was going to work on
18:50:28
jberman:monero.social:
so ya, we'll see where we're at post-tx relay v2 once ready, and with some other changes to re-relaying for I made strictly for stressnet rolled back
18:50:47
ofrnxmr:monero.social:
Sounds good
18:57:51
jberman:monero.social:
also, eventually we probably want to get rid of the auto-ban change on stressnet.. we really should solve all the issues causing unexpected /extraneous bans and nodes should be able to stay connected during stressnet
18:58:05
jberman:monero.social:
sorry the auto unban*
18:58:10
jberman:monero.social:
after 2 mins
19:10:07
0xfffc:monero.social:
Let me know if there any help I can do