<r​brunner7:monero.social> Meeting in a bit less than 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1311

<s​needlewoods_xmr:matrix.org> hey

<r​brunner7:monero.social> Hmm ... people busy Christmas shopping maybe :)

<j​berman:monero.social> *waves*

<j​berman:monero.social> sorry

<r​brunner7:monero.social> Alright, what are the reports about last week?

<s​needlewoods_xmr:matrix.org> while updating monero-project/monero-gui #4437 I also fixed some issues I didn't notice before

<s​needlewoods_xmr:matrix.org> began to look back into the problem with setting restore height on wallet creation with the GUI

<s​needlewoods_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 repo.getmonero.org/SNeedlewoods/ccs…lewoods-03_part-time_dev_work-Q1-26

<r​brunner7:monero.social> Do you have something reviewable already for the Wallet API and the use of that in the CLI wallet?

<r​brunner7:monero.social> Will have a look at your CCS proposal

<s​needlewoods_xmr:matrix.org> Not sure I understand, but this is "reviewable" I guess monero-project/monero #10233

<r​brunner7: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

<j​berman: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

<j​berman:monero.social> 2, getting all outstanding PR's shaped up, and may dig into a segfault reported by ofrn

<s​needlewoods_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

<s​needlewoods_xmr:matrix.org> I assume some things will change because of review though

<r​brunner7:monero.social> "tx relay v2" is a pretty big change, right?

<r​brunner7:monero.social> Or maybe I confuse it with something else

<j​berman: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

<j​berman:monero.social> and plan to work with 0xff on that

<j​berman:monero.social> the current PR for reference: seraphis-migration/monero #184

<r​brunner7:monero.social> That could be quite a big step forward

<r​brunner7:monero.social> Especially in times of many transactions

<j​berman: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

<j​effro256:monero.social> Howdy sorry I'm late

<r​brunner7:monero.social> Not sure what you mean with "relay issues"

<j​berman:monero.social> seraphis-migration/monero #163

<r​brunner7:monero.social> Ah, ok. Might be present for quite a while already, but only surfacing now

<j​berman:monero.social> seems to be the case

<j​berman: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

<r​brunner7:monero.social> jeffro256: What kept you busy during last week?

<j​effro256:monero.social> Working on tx knowledge proofs integration (decode, spend, reserve, etc)

<r​brunner7:monero.social> Anything that is significantly more complex now among those because of Carrot?

<j​effro256:monero.social> Hoping to get that done this week

<j​effro256: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

<r​brunner7:monero.social> Ok, if that's the worst that happens, quite alright :)

<r​brunner7:monero.social> Alright, anything to discuss beyond reports today?

<o​frnxmr:monero.social> stressnet didnt die with sustained 20+mb blocks

<s​needlewoods_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

<o​frnxmr: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

<j​berman:monero.social> your call!

<j​effro256:monero.social> My old desktop server sounding like a jet engine tho

<r​brunner7:monero.social> Lol

<o​frnxmr: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

<r​brunner7:monero.social> Finally working like it should have all the time already

<s​needlewoods_xmr:matrix.org> laptop fans been spinning non-stop for days

<r​brunner7:monero.social> Is mining large blocks indeed somehow significantly slower? Where does that slowing happen, is that known?

<o​frnxmr:monero.social> Cpu usage spikes hard when getting alt chains

<j​berman:monero.social> very rough idea that probably has problems: maybe difficulty should also factor in n txs

<o​frnxmr: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)

<o​frnxmr:monero.social> to not* download

<o​frnxmr:monero.social> Essentially, your node gets hammered with alt blocks (which could be bullshit attempts at selfish mining) even if your chain is longer

<r​brunner7:monero.social> But those alt blocks need to be correct regarding RandomX?

<j​berman:monero.social> alt block handling does need a pass

<r​brunner7:monero.social> Another entry on a long list of such things maybe ...

<o​frnxmr:monero.social> yea, theyre valid blocks, just not an equal or longer chain

<r​brunner7: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

<o​frnxmr: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

<o​frnxmr:monero.social> before syncing the blocks from the longer chain

<o​frnxmr:monero.social> Reorg doesnt happen until theyve actually synced the final block that surpasses their chain height

<o​frnxmr:monero.social> So you can essentially game this by setting your download speed to something low, so you dont receive blocks fast

<o​frnxmr:monero.social> anyway, not an fcmp issue. Just a big block issue

<r​brunner7:monero.social> Aka "the bug" ... as it was brutally simplified in some Reddit discussions ...

<r​brunner7:monero.social> Correct the "bug", and no more block size limit needed, presto :)

<r​brunner7:monero.social> Well, not everybody can be a dev and know how awfully interconnected things can be

<r​brunner7:monero.social> Alright, looks like we may be through with immediately important things for now. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> thanks, see ya

<o​frnxmr:monero.social> I H8 the txpool

<o​frnxmr:monero.social> So many issues stemmed from the pool 🥲

<j​berman:monero.social> it's significantly improving with the latest ya?? seems like just the not relayed issue is the last remaining main thing

<j​berman:monero.social> and I guess that segfault but I don't think that's a txpool issue

<o​frnxmr:monero.social> I "think" this might be related to v2

<j​berman:monero.social> are you running v2?

<o​frnxmr:monero.social> I dropped v2 commits recently, so not anymore

<j​berman:monero.social> you were running v2 when you encountered this too? seraphis-migration/monero #163

<o​frnxmr:monero.social> looks like v2 might be relaying txs 1 at a time

<o​frnxmr:monero.social> Honestly not sure. I think no

<o​frnxmr:monero.social> With v2 i was seeing 1000-15000 not relayed

<o​frnxmr:monero.social> Honestly not sure. I think not

<j​berman:monero.social> the current v2 PR has an issue where it silently stops relaying >100 txs

<j​berman:monero.social> which is one of the things I was going to work on

<j​berman: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

<o​frnxmr:monero.social> Sounds good

<j​berman: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

<j​berman:monero.social> sorry the auto unban*

<j​berman:monero.social> after 2 mins

<0​xfffc:monero.social> Let me know if there any help I can do