.merges

so when do we plan a new release?

<r​ottenwheel:kernal.eu> Ask in today's meeting?

<r​brunner7:monero.social> Quick reminder that we will have a meeting here today 18:00 UTC, not anymore in #no-wallet-left-behind:monero.social. Announcement: monero-project/meta #1053

sech1: luigi is away after wednesday for a bit

so we'd have to tag before that

And gui? I want to release p2pool 4.1 before that

I guess the time frame is the same for gui

<o​frnxmr:monero.social> We should keep this room for current repo stuff. Todays meeting probably an exception, but stuff that isnt on the repo should be in a different room.

<o​frnxmr:monero.social> i suggest renaming and readderessing nwlb to monero-next/upgrade/evolution, and doing the meetings there. -dev for current repo work, -next/upgrade/evolution for in progress dev work that is not on the repo, and mrl for ideas/research

<r​brunner7:monero.social> > We should keep this room for current repo stuff.

<r​brunner7:monero.social> Why would that be better? What issue, what potential problem would that solve?

<o​frnxmr:monero.social> nwlb is the place of discussion fkr the topics, it should be the place for the meeting

<o​frnxmr:monero.social> Problem is that nwlb is named incorrectly, its not just a wallet room

<o​frnxmr:monero.social> And doesnt have monero- addressing

<r​brunner7:monero.social> If we move FCMP discussions between meetings to here as well, things are ok then?

<r​brunner7:monero.social> We are hell-bent to introduce and hardfork to FCMP *as soon as possible*, right?

<o​frnxmr:monero.social> no, fcmp has 0 prevalence on monero-project/monero. Fcmp and seraphis should be in monero-next/upgrades/evolution (aka nwlb)

<o​frnxmr:monero.social> Its not finished, not even in review stage

<r​brunner7:monero.social> Why should GitHub repositories and their content or content that is missing there decide what we should or should not discuss here? I am pretty confused about the approach.

<o​frnxmr:monero.social> future protocol upgrades already have their own place of discussion, its just lost due to the naming if the room

<o​frnxmr:monero.social> The same reason nwlb even exist, rbrunner.

<r​brunner7:monero.social> Is this room overflowing with long and complicated discussions?

<o​frnxmr:monero.social> The logic of "move meeting to -dev" woukd also apply to "delete nwlb and move all discussion about seraphis and fcmo to -dev"

<o​frnxmr:monero.social> Nwlb is

<r​brunner7:monero.social> Apart from deleting what has historical value - yes, let's move!$

<r​brunner7:monero.social> All Monero development

<o​frnxmr:monero.social> I disagree

<o​frnxmr:monero.social> its not monero development until its on the repo. Seraphis is 2+n years away

<o​frnxmr:monero.social> Fcmp likely >12 months before hitting the repo

<r​brunner7:monero.social> And that's why we are not welcome to meet here weekly and discuss FCMP?

<o​frnxmr:monero.social> Yes

<r​brunner7:monero.social> Strange

<r​brunner7:monero.social> Where is the benefit, the win, the improvement only to discuss things here that are "in the repo". I ask again, is the room overflowing with too much stuff?

<o​frnxmr:monero.social> nwlb should be a room dedicated to upgrades that arent on repo yet

<o​frnxmr:monero.social> (nwlb should be renamed and readdressed)

<o​frnxmr:monero.social> The benefit is the same as "why we have nwlb" or "why we have mrl"

<o​frnxmr:monero.social> We dont have mrl meetings here for the same reason we shouldn't have seraphis or from meetings here

<o​frnxmr:monero.social> Seraphis or fcmp*

<o​frnxmr:monero.social> Re overflowing: no -dev is not, but mrl and nwlb are

<r​brunner7:monero.social> I can't follow. The MRL and the MWLB rooms are overflowing with too much stuff? Like, right now, this week, last week, last month?

<o​frnxmr:monero.social> Should we do mrl meetings in -dev?

<r​brunner7:monero.social> If I say no, I have lost?

<o​frnxmr:monero.social> Yes

<o​frnxmr:monero.social> :)

<r​brunner7:monero.social> Thing is: It seems, at least to me, that "research" and "development" are quite easy to make into two heaps. If you want to part "development" further into sub-heaps, you arrive, IMHO, exactly at the situation that prompted the resurrection of general-purpose dev meetings of yesteryears: Something will always fall through the cracks.

<o​frnxmr:monero.social> -dev meetings can still resume, but should focus on releases, triaging issues and prs, dev reports and potentially dev ccs discussion

<r​brunner7:monero.social> If you ask me, we will see pretty fast whether we are on the wrong track: If we have, after broadening the scope of the meeting, so many things to discuss that people lose overview and 1 hour is hopelessly too short, it's clearly "back to the drawing board". If we fare ok with a single meeting, well, "simple is simply simpler"

<r​brunner7:monero.social> If you have so many things to discuss in a dev meeting as you see it before your inner eye, why aren't there such meetings?

<o​frnxmr:monero.social> because i was banned

<o​frnxmr:monero.social> :)

<r​brunner7:monero.social> Oh, plot twist

<o​frnxmr:monero.social> i had no comments to make / no observations to observe. The above is how i think dev meetings are best served

<o​frnxmr:monero.social> they dont have to run an hour either

<r​brunner7:monero.social> Well, I am curious whether others will read and leave their opinion. I think I get your general idea now, but I still don't see enough improvement compared with a dead-simple meeting discussing all things Monero dev, whether on repo or off repo or whatever

<r​brunner7:monero.social> And with the meeting right here. The channel will bear about 300 new lines from the meeting.

<r​brunner7:monero.social> I am not sure you are fully awary how shy a kind of animals our real devs are, the ones actually writing C++ and Rust code. With too many meetings and too many rooms you don't win but they just run away and hide.

<r​brunner7:monero.social> And after all discussions are not at all restricted to this room, or 5 other dev related rooms at that. Proper place for dev related discussion are, to a large extent, GitHub issues.

<o​frnxmr:monero.social> Mrl, upgrades/next, dev

<o​frnxmr:monero.social> 3 rooms, 3 tiers of development, 3 distinct crowds, 3 purposes

"And that's why we are not welcome to meet here weekly and discuss FCMP?" , "Yes" :o

FWIW I consider this canonically on topic.

sech1: can you release that today?

yes, I'm waiting for CI to finish building the binaries

<0​xfffc:monero.social> My vote is to have the regular meeting in another room. Not that it is unrelated to here. No. It is just this room is extremely crowded. And there is always Q/A going on.

<r​brunner7:monero.social> Meeting here (at least for today ...) in a bit less than 1 hour

Arguably having the meetings in the 'core' rooms will increase visibility and participation

Having the meetings scattered across many rooms will probably reduce participation

plus, discussion related to the major refactoring being done to allow for future code additions is arguably pretty on topic

<r​brunner7:monero.social> 10 Monero devs with around 20 opinions :)

<f​arooqkz:mozilla.org> one day in the coming years i am getting involved in at least one of these:

<f​arooqkz:mozilla.org> - some crypto development(xmr? bch?)

<f​arooqkz:mozilla.org> - some kernel or firmware development(linux? freebsd?)

<f​arooqkz:mozilla.org> - some compiler development(sbcl?)

<f​arooqkz:mozilla.org> the idea is trying a new method of programming to tackle with problems which require a total new mindset, different than what i had till now.

<f​arooqkz:mozilla.org> one day in the coming years i am getting involved in at least one of these:

<f​arooqkz:mozilla.org> - some crypto development(xmr? bch?)

<f​arooqkz:mozilla.org> - some kernel or firmware development(linux? freebsd?)

<f​arooqkz:mozilla.org> - some compiler development(sbcl?)

<f​arooqkz:mozilla.org> the idea is trying a new method of programming to tackle with problems which require a total new mindset, different than what i had till now.

<f​arooqkz:mozilla.org> to be precise, in exactly one of these

<o​frnxmr:monero.social> <d​EBRUYNE> Arguably having the meetings in the 'core' rooms will increase visibility and participation << nwlb would become a "core" room

<o​frnxmr:monero.social> its current name and status is foggy as best

<o​frnxmr:monero.social> Its like "where we put everything that we dont know where to put, because its neither -dev or -mrl"

<o​frnxmr:monero.social> the same argument for creating nwlb is the same argument for expanding it to encapsule more than seraphis wallets (which it has already done, by becoming the come of all things seraphis, fcmp, and any other not-yet production items)

<o​frnxmr:monero.social> The only thing that needs to change is the room name and address, from nwlb to monero-pickaname

How about #monero-devel ? We'll make fedora and debian people both happy.

Windows people can stay in #monero :D And #monero-gui for Mac users.

<r​brunner7:monero.social> What does "devel" stand for? Just "development" abbreviated a bit differently?

Yes. Headers are in -dev packages for debian and -devel packages for fedora. Or vice versa, I always forget.

<r​brunner7:monero.social> So all clarity successfully eliminated :)

Thank you.

Just to clear something up for me, some version of fcmp *will* most probably end up in monero, barring unforeseen problem, correct ?

<r​brunner7:monero.social> Yes.

Thanks.

<o​frnxmr:monero.social> After audits, testing, and scaling is sorted

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

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

<s​needlewoods:monero.social> hey

<o​ne-horse-wagon:monero.social> Hello.

<v​tnerd:monero.social> Hi

<d​angerousfreedom:monero.social> Hi

Hello

<0​xfffc:monero.social> Hi everyone

hi

Is there an agenda for this meeting?

<h​into:monero.social> hello

<o​frnxmr:monero.social> No

<j​effro256:monero.social> howdy

<r​brunner7:monero.social> Before we come to the reports: We have a surprising amount of ideas floating around how many dev meetings with what kind of foci in which rooms we should hold.

<r​brunner7:monero.social> I propose to keep discussion about this *out of this meeting*

<r​brunner7:monero.social> I think we should use the time to discuss dev related things.

<r​brunner7:monero.social> Meta-discussion about meetings should go, IMHO, in a new issue in -meta on GitHub

<o​frnxmr:monero.social> Since were in dev, lets start with pressing dev matters.

<o​frnxmr:monero.social> 1. We have to tag by wednesday

<r​brunner7:monero.social> If people are ok with that, I can open such an issue later.

<r​brunner7:monero.social> What is there to report from last week?

<o​frnxmr:monero.social> Is everybody ready to tag, or are there any issues or PR's that need review or implementation asap

<r​brunner7:monero.social> Can you please hold back for 5 minutes more, so we can get the usual overview who did what during the last week? Thanks.

I'll release p2pool v4.1 today which needs to be included in monero-gui v0.18.3.4

<s​needlewoods:monero.social> added missing functions to the API, now just TODO's and QUESTIONs to fix, I think I can see the finish line, but it will probably still take a while

<o​frnxmr:monero.social> Sneedlewoods, this for what?

<o​frnxmr:monero.social> Seraphis?

<j​berman:monero.social> me: finalizing a draft PR + writeup for the fcmp++ integration, shooting to submit that PR by tomorrow. The PR so far includes a Rust FFI to use @kayabaNerve's fcmp++ crate, code to migrate existing cryptonote outputs into a merkle tree for fcmp++'s, growing the tree as the node syncs, an algo to trim the tree, and changes to the `cryptonote::transaction` class for fcmp++. I plan<clipped message>

<j​berman:monero.social> to also implement tx construction & verification, and consensus changes in that PR

<system> file df_draft_fcmp_v1.pdf too big to download (1184797 > allowed size: 1000000)

<d​angerousfreedom:monero.social> df_draft_fcmp_v1.pdf

<d​angerousfreedom:monero.social> This week I continued reading the code and theory of FCMP. I still don't understand the details of the circuits in the `prove` and `verify` functions and the exact details to fetch and store the tree in the database but I will improve my understanding with time since I'm much more familiar with the code and terms used. I believe it would be better to try to do something concrete n<clipped message>

<d​angerousfreedom:monero.social> ow. Here is a draft of my understanding so far of some concepts. There may be big errors and imprecisions and it is still very shallow. Take it with a big grain of salt. I will improve it as I also improve my understanding.

<r​brunner7:monero.social> @jberman: What will you PR against?

<j​effro256:monero.social> me: polishing the carrot doc and soliciting auditors (I have one meeting planned thus far)

<j​berman:monero.social> master in core Monero

<s​needlewoods:monero.social> Also started to prepare my incoherent notes of things I found during the API work all over the place and plan to create a github issue for that. Not sure if I should put it into monero-project issues though, because it's a bunch and I don't think it makes sense to create a github issue for everything I found suspicous.

<r​brunner7:monero.social> So much about "future stuff" :)

<0​xfffc:monero.social> Me: since Wednesday I was reviewing different PR. The big one is reproducible build PR 8929. Which review is almost complete.

<o​frnxmr:monero.social> off topic rbrunner, dont bait me

<r​ottenwheel:kernal.eu> Will that go into a separate fcmp branch for the time being? 🤔 Can't be marged on master till it's ready, no?

<o​frnxmr:monero.social> You asked nicely to leave that discussion out of this meeting

<r​brunner7:monero.social> Alright, understood.

<j​effro256:monero.social> It could be merged but not activated

<o​frnxmr:monero.social> Similar to some of koe's seraphis preparedness prs

<j​berman:monero.social> @rottenwheel I'm thinking it could remain a WIP draft PR until it's ready

<v​tnerd:monero.social> Me: worked on socks v5 - adding ipv6 support to proxy requests. Also worked on LWS frontend API project

<r​brunner7:monero.social> So soon people will be able to run their own LWS instances, are you nearing completion?

<o​frnxmr:monero.social> They already can

<s​needlewoods:monero.social> sorry ofrn, I'm slow, I think here you can get enough information what I'm working on in general monero-project/monero #9368#issuecomment-2168451558

<v​tnerd:monero.social> They are already able to run their own LWS instances, there just isn't many wallets supporting it because there's a decent amount of work to tx construction in particular

<r​brunner7:monero.social> I see.

<v​tnerd:monero.social> The LWS API is json, and is pretty straightforward I think

<0​xfffc:monero.social> One important thing is the PR 9404 [1] needs reviewer. The PR has been running on stressnet with different scenarios. And no issues has been reported. With this PR, we have instantaneous start up.

<0​xfffc:monero.social> 1. monero-project/monero #9404

i've already done all that work

vtnerd and rbrunnner

thank you endogenic

i've told you this a few times, but i havent ever been contavted by vtnerd

I told him a few times, but somehow we didn't end up being able to collaborate yet

The problem is that I haven't published it yet

<o​frnxmr:monero.social> endogenic, show and tell

The only reason I haven't done that is because I don't have help

you say show it but what happens is that everyone else is just going to use my stuff before I get to actually launch my own product - this is just because I don't have any funding or any help from anyone

so it sounds a little bit like a Catch-22, but I swear that I have done all of the work already

it's directly from wallet2

i'm sure we can figure something out, but I literally am programming right now and I'm so close to releasing this stuff but I've just had to make it better because of the fact that all this other work is happening meaning I have to progress even further before I can release

so if we had worked together, then I think it would've been released already

it's just not fair to me either

<r​brunner7:monero.social> Alright, looks like we are through with the reports. ofrnxmr , we have a pressing issue, tagging a new release?

it's actually been really difficult

to see this

geez so cold?

<o​frnxmr:monero.social> yes. We have to tag the new release by wednesday

<v​tnerd:monero.social> Is it in a private GitHub repo, or something completely offline?

me? vtnerd?

private repos

yes

long history

many commits

<r​brunner7:monero.social> Pardon my ignorance, why do we *have* to tag? Would a long pause result if we don't?

i've been homeless at times.. and many other things no one would believe lol

<o​frnxmr:monero.social> Im not sure about the reasoning dor 18.3.4, id have thought it should be 18.4.0 (?) Major minor patch, this isnt just a bugfix release.

<v​tnerd:monero.social> Then just make it public, it's the least friction. Theres probably no shot at keeping it private, it's unlikely people will support private wallet code

I don't intend to keep it private at all

it's not intended to be private

it's just intended to be ready before it's released publicly

But it puts me at a major disadvantage to release all my work when everyone else has so much funding and help

especially because my work is actually pretty interesting

I have a huge write up..

<o​frnxmr:monero.social> and selsta would be the one to ask about "why" wednesday, im just relaying the message

<r​brunner7:monero.social> Ok, do we have @selsta around, they may have the best overview what is needed in order to tag.

<r​ottenwheel:kernal.eu> Endogenic has been delivering groundbreaking code since before the 2000s!

vtnerd would you be open to collaborating with me privately on the lws support for 2-3 weeks max? then it all goes public

<r​brunner7:monero.social> Is anybody here right now directly involved in that release? With contributing PRs that may still not be re ready?

<r​ottenwheel:kernal.eu> He just hasn't been able because the life threats and lack of funding guys!

rottenwheel please, man, you're going to eat your words

you have no idea

what i have been through..

<o​frnxmr:monero.social> endo, please ignore

lws support is done tbh

on my side

<r​brunner7:monero.social> rottenwheel, @endogenic, maybe this special topic can wait until after this very meeting?

i just need to update ny client for vtnerds new api

as you know he added spenda and recvs

i think it both a negative and positive we have duplicated efforts around endogenics area of work/expertise. neg being the dupl efforts, positive being we have more than 1 developer who understands the problem and can pick apart each others implementation. but i think we should leave it at that for this meeting unless it is on the agenda

this was one of the things I was going to announce

<o​frnxmr:monero.social> create a private repo and invite vtnerd as collaborator?

<r​brunner7:monero.social> Whatever does not derail this meeting. Please?

The only thing is that vtnerd might have confidentiality agreements, or he might not be willing to enter into a confidentiality agreement with me

that's why I was really trying to just launch everything

to be honest, honest with you, it's going to be trivial for me to update my client to work with vtnerds new api format

it's just that I was having a little bit of difficulty getting something compiling and stuff like this just takes more time

<r​brunner7:monero.social> I don't have admin or any other special rights in here, by the way. If people insist on sabotaging this meeting, they will probably succeed.

there's no communication between me and him and so I can't just ask him about stuff

in other words, it's not like I'm paying him for his time so I don't feel comfortable asking him

<o​frnxmr:monero.social> **Regarding the release** << are there any prs that anyone is trying to get into the release or issues that need to be resolved?

we've asked a lot from him already to be honest

<o​frnxmr:monero.social> Plowsof has matrix ops

<j​effro256:monero.social> vtnerd: sorry I meant to address your comments on monero-project/monero #9135 earlier this week; thanks for the review. In your opinion after looking at the PR's code, once those issues are addressed, do you think it worth including in the next release?

yes I'm around

<v​tnerd:monero.social> jeffro256: I recall it being pretty much ready for inclusion

<o​frnxmr:monero.social> This is running on stressnet, but were unsure if it caused an increase in reorgs (?) Rucknium:

<j​effro256:monero.social> Btw that PR is running on the stressnet currently

<o​frnxmr:monero.social> The reorg increase _may_ have been due to a very poorly connected miner though

<j​effro256:monero.social> I was looking into this too, I *think* there were just more reorgs this time around, but I'm actively looking into it

<r​ucknium:monero.social> ofrnxmr: jeffro256 These was an increase in re-orgs around the time that we put that PR into release, but other code was put in release, too. It's not a controlled experiment.

r​brunner7: nothing is needed anymore on the -cli side, but if something is ready and well reviewed we can include it with the next round of merges

<r​ucknium:monero.social> And miner behavior isn't a controlled variable, either

<j​effro256:monero.social> There were already mass reorg messages before, but they didn't feel *as* common. Of course, there's been a lot of variables changed with the new fork

<r​brunner7:monero.social> Sorry, Murphy's law. My cable modem just had the idea to reboot now.

<r​brunner7:monero.social> Alright, seems I am back on track.

<j​effro256:monero.social> Sorry I keep duplicating people's thoughts delayed by 15 seconds lol

<j​effro256:monero.social> I will compile a stressnet node without the PR and observer reorg behavior

<j​effro256:monero.social> At any rate, it appears that the nodes are syncing just fine even with the increased messages

<r​brunner7:monero.social> @jeffro: I also saw the reorgs with a stressnet daemon without your PR ...

<o​frnxmr:monero.social> (Reorgs have calmed down a lot on both new and old stressnet)

<r​ucknium:monero.social> New stressnet isn't being spammed yet FWIW.

<r​brunner7:monero.social> Ok, looks like we have the release and the tagging sorted, yes? At least as far as meeting participants are concerned.

gui is tagged separately?

<o​frnxmr:monero.social> Rbrunner, spackle was having almost every block reorged. I hypothesise unrelate to jeffro's pr, and related to a poorly connected miner

I still need to have p2pool v4 in the next gui release

sech1: yes separately

<o​frnxmr:monero.social> You had aksed "why wednesday", im not sure thats been answered

<o​frnxmr:monero.social> I can only imagine luigi will be away for some time afterwards

proprietary

<r​brunner7:monero.social> Everything can run towards release without them after tagging? Surprises me a bit, but I don't know the details

rbrunner7: yes, apart from the auto-updater

<r​brunner7:monero.social> GitHub compiles, or people compile repeatable builds, and binaryfate signs and uploads?

yes

<r​brunner7:monero.social> Ok, nice.

<r​brunner7:monero.social> Ok, hopefully news about the wednesday deadline will reach everybody

<0​xfffc:monero.social> There is this one too 👆🏻.

<o​frnxmr:monero.social> monero-project/monero #9404 << for people on irc

<o​frnxmr:monero.social> (0xfffc's reference)

<r​brunner7:monero.social> You hope to have that reviewed and included until Wednesday?

9404 is a bit risky to include in this release in my opinion

<o​frnxmr:monero.social> monero-project/monero #9376

<o​frnxmr:monero.social> This one as well

<0​xfffc:monero.social> I am not hopeful about the “included” part.

<0​xfffc:monero.social> I believe is safe to include. IMHO.

<j​berman:monero.social> shooting to review 9404 this week. I can shoot to have it done by wed, but doesn't seem required for this release to me

would be nice if 9376 gets a second review

<j​effro256:monero.social> agreed

including deep internal changes in the daemon last minute isn't good

<r​brunner7:monero.social> I could have a look tomorrow at 9376

<o​frnxmr:monero.social> 9376 has been running on stressnet for a while now and works as expected. Much. Much faster started speed when txpool is large

<r​brunner7:monero.social> Yeah, if there is something wrong at all then maybe an unintended side effect, influence on something not yet thought about.

<r​brunner7:monero.social> Ok. Do we have some other subject to discuss now? Is the dev here that, with their question, made the ball roll towards a broader dev-meeting? Something with binary stuff in JSON maybe?

<o​frnxmr:monero.social> Yes

<r​brunner7:monero.social> Do you have a pointer?

<o​frnxmr:monero.social> rbrunners serialization / strings issue (he has a pr on stressnet) imho needs to be investigated and property implemented asap

<o​frnxmr:monero.social> Block sync size + the serialization issue = problems that we dont want on mainnet

<r​brunner7:monero.social> Yes, needs a taker, a dev with some free time on their hand. Which may be rare right now ...

rbunner7: well, I have extended monero-wallet-rpc with two endpoint for binary blob key image export/import, don't know if that fits here, and it would be cool if it could be included

<0​xfffc:monero.social> ( Very important )

<r​brunner7:monero.social> I think the connection is with cuprate

<r​ucknium:monero.social> hinto hinto suggested the binary JSON-RPC deprecation

<o​frnxmr:monero.social> We need to implement a dynamic BSS and/or need to fix the serialization / strings limitations

sorry, didn't want to disturb :/

<j​effro256:monero.social> BSS

<j​effro256:monero.social> ?

<r​brunner7:monero.social> How many blocks to sync in one gulp

<o​frnxmr:monero.social> bss= block sync size

<h​into:monero.social> hello, yes the issue could maybe use more discussion from other devs although I think any approach within reason will be reasonable: monero-project/monero #9422

<r​brunner7:monero.social> Ah, ok, there is already an issue as a nice place to discuss. So just needs more eyes, and people opining :)

<h​into:monero.social> I'm willing to make the changes to `monerod` although it may be faster if someone more familiar were to do it, at the very least I can review

<r​brunner7:monero.social> Do we run into nasty coordinating proplems if we change that with clients that use these endpoints?

<h​into:monero.social> jberman suggested deprecating the endpoints within 12 months, I'd assume they'd still work afterwards but are not recommended in documentation

<o​frnxmr:monero.social> ((We also need to stop using words interchangeably, ie "block" and "ban". Dns blocklist, banlist, block size, block time (ban), block time (blocks)

<o​frnxmr:monero.social> block-sync-size really means "batch size"))

<r​brunner7:monero.social> For the record, the issue that needs a competent dev for implementing a good longterm solution, about that "BSS" issue: spackle-xmr/monero #12

<o​frnxmr:monero.social> ^^ this is high priority imo

<0​xfffc:monero.social> I can take this. The bandwidth efficient propagation will be delayed though

<r​brunner7:monero.social> If nobody finds time near- or mid-term, we could probably just go with what I did for a first quick fix, just rising those limits. After some testing whether it really does not blow up somewhere.

<j​effro256:monero.social> Which limit type was actually hit in the stressnet case? Objects, fields, or strings?

<r​brunner7:monero.social> Strings.

<o​frnxmr:monero.social> We still have a max packet size of 100mb. If we were to play it safe, we should mimic stressnet and change bss from 20 > 5 and implement rbrunners suggestion.

<o​frnxmr:monero.social> but neither of those is a long term solution

<r​brunner7:monero.social> At least. But I did not rise the limits one-by-one.

<0​xfffc:monero.social> ( multiple limitations at play here )

<o​frnxmr:monero.social> strings was the error that 0xfffc's debugger showed

<r​brunner7:monero.social> Yes, I also saw it myself in the debugger, in some nice live scenario.

<o​frnxmr:monero.social> The problem with bss = 20 is the packet size limit

<r​ucknium:monero.social> 0xfffc: IMHO it makes sense for you to try to solve the BSS issue. The efficient tx propagation proposal has some privacy issues that the dev & researcher community may want to discuss more.

<o​frnxmr:monero.social> Simply raising serialization limits can eventually also hit the packet size limit.

<o​frnxmr:monero.social> dynamic bss is best solution to the static bss=20 imo

<r​ucknium:monero.social> And the current stressnet will last for about two months longer

<r​ucknium:monero.social> This is the efficient tx propagation issue: monero-project/monero #9334

<0​xfffc:monero.social> I am all ears. If community thinks this is more important. I will switch immediately.

<o​frnxmr:monero.social> Unrestricted rpc will fail to connect when txpool > 100mb

<o​frnxmr:monero.social> Restricted batches rpc calls into 100tx/call. We need to fix this for unrestricted rpc jberman @jberman:monero.social:

<r​brunner7:monero.social> Hmm, gut feeling tells me that this efficient tx propagation thing might take quite a while to get merge-ready, maybe really a good idea to attack that BSS issue first.

<r​brunner7:monero.social> And well, it may take a while until we have the next spam wave, or organic traffic in stressnet amounts

<0​xfffc:monero.social> Sure. Then I am switching to fixing serialization limit right now. ( will go back to bandwidth efficient propagation after that )

<o​frnxmr:monero.social> bss or serialization?

<r​brunner7:monero.social> Splendid!

<0​xfffc:monero.social> Serialization will be easier to attack at first IMHO. What do you guys think? Which one we should start with?

<o​frnxmr:monero.social> Serialization only helps up to 5mb blocks

<0​xfffc:monero.social> Keep in mind the multiple limitations 👆🏻

<o​frnxmr:monero.social> Bss can be reduced to 5 (like stressnet) to add a stop-gap measure

<0​xfffc:monero.social> My impression was we hit the serialization first.

<o​frnxmr:monero.social> But dynamic bss is a better solution (which would allow <=100mb blocks)

<0​xfffc:monero.social> So it is better to start from the bottleneck.

<r​brunner7:monero.social> In my understanding things are linked. With a good algorithm to dynamically adjust BSS to traffic and block sizes the serialization limits are not that critical, and we can stay with relatively low "sanity checks"

<o​frnxmr:monero.social> Yes. We hit serialization at 1.5mb blocks

<o​frnxmr:monero.social> after Fixing serialition, we hit packet at 5mb blocks

<o​frnxmr:monero.social> If dynamic bss, we hit serialization at 30mb blocks

<o​frnxmr:monero.social> After fixing serialization + dynamic bss, we hit packet at 100mb blocks

<r​brunner7:monero.social> Alright, 0xfffc , I think things will clear up as soon as you wrap your head around the hole story :)

<r​brunner7:monero.social> *whole story

<0​xfffc:monero.social> ( So in every case we hit serialization limitation. )

<o​frnxmr:monero.social> No

<0​xfffc:monero.social> But rbrunner7 thinks the dynamic bss is more important than serialization limit.

<o​frnxmr:monero.social> The final boss is packet

<0​xfffc:monero.social> That is the monster at the end of story :))

<j​berman:monero.social> this likely needs testing, but just changing `std::numeric_limits<size_t>::max()` to something sane like 1000 may be fine here: github.com/monero-project/monero/bl…fd/src/rpc/core_rpc_server.cpp#L660

<o​frnxmr:monero.social> right, bss gets us further (to 30mb blocks) than serialization (5mb blocks)

<j​berman:monero.social> it shouldn't break wallet2, but could break other clients that rely on it

<o​frnxmr:monero.social> This was my suggestion (1000 = 100kb(max block size) * 1000 = below the packet size limit)

<0​xfffc:monero.social> Important point: all of those limitations need to be fixed. Let me review each of them. We debugged it once.

<0​xfffc:monero.social> Start from the compromise of (simpler + more important)

<o​frnxmr:monero.social> "this" = changing the max tx pull to <1000

<k​ayabanerve:monero.social> ofrnxmr: FCMP is not 12m away. We're looking at a PR for a lot of the framework within the next few weeks. Academia is also near complete, and a variety of the libraries are about to head to auditing.

<j​effro256:monero.social> 100mb packet probably doesn't need to be touched

<o​frnxmr:monero.social> To mainnet?

<o​frnxmr:monero.social> Kaya

<k​ayabanerve:monero.social> The moment that PR is open, it's monero-dev.

<0​xfffc:monero.social> I agree. If we have good dynamic bss algorithm. 100mb should be more than important.

<0​xfffc:monero.social> s/important/enough/

<j​effro256:monero.social> IMO 0xfffc your time would be really well spent reviewing vtnerd's serialization library changes since those changes would make the limits less important since the serializer is inherently more efficient, and parsing rogue messages is less of a risk

<k​ayabanerve:monero.social> jeffro256: Happy to help with auditors :) Feel free to reach out.

<0​xfffc:monero.social> Great suggestion. I think I have missed those PRs. What was the number?

<j​berman:monero.social> I think all fcmp integration code (not including reproducible build-related) in the monero repo can be completed within 4 months

<k​ayabanerve:monero.social> Re: RPC method deprecation, given how FCMP++ will change the definition of the output distribution (it's a new pool superseding all others) and TX creation code, do we want to take advantage of the amount of changes to argue hard breaks on other methods? Deprecate prior to HF, remove entirely with the bin that HFs?

<j​effro256:monero.social> Here the PR for the overall tracking: monero-project/monero #8867. Here's the currently opened piecemeal PR: monero-project/monero #8970

<k​ayabanerve:monero.social> I'd hope for mainnet within a year, ofrnxmr.

<k​ayabanerve:monero.social> Sorry for not being present earlier and responding to what's relevant on my end now.

<j​effro256:monero.social> It's a pretty huge task, but replacing the DOM serialization, especially for large funky messages, will help DoS mitigation a lot

<o​frnxmr:monero.social> Isnt this 7999 redux?

<0​xfffc:monero.social> Great. Well before the time I joined monero community. I was not aware of these. Thanks for mentioning.

<0​xfffc:monero.social> Just the final question. I am between two tasks right now. Fixing out serialization limit, or reviewing vtnerd serialization PR.

<0​xfffc:monero.social> Which one I should tackle?

<j​effro256:monero.social> monero-project/monero #7999#issuecomment-938098462

<j​berman:monero.social> Full wallets shouldn't need an RPC route for anything like getting the output distribution at all (only light wallets should need to fetch decoy paths), but generally ya the get_output_distribution endpoint can be set to be deprecated in theory when fcmp's are required, and that is a better deprecation timeline we can aim for

<o​frnxmr:monero.social> Jbernan, thoughts on 7999 vs 8867?

<k​ayabanerve:monero.social> jberman: we still need decoy requests for paths, as you say. How does that enable deprecating getting the output distribution?

<k​ayabanerve:monero.social> My comment was how if we're already making notable changes necessary for practical operation, we can also make breaking changes and provide a single migration guide (instead of two releases with such notable changes).

<j​effro256:monero.social> I really don't see the point in removing the `get_output_distribution` RPC method (even the "broken" JSON one) since it *works* now for the custom JSON parser, and doesn't really affect other code in the codebase

<k​ayabanerve:monero.social> The broken JSON one is a sin, it should be removed ASAP.

<j​effro256:monero.social> Obviously I see the value of *also* having a JSON compliant endpoint

<j​effro256:monero.social> I disagree. Current services depend on it, and removing it for the sake of removing is just annoying to people building things in Monero

<k​ayabanerve:monero.social> We should not have an endpoint which is fundamentally broken to its definition.

<j​berman:monero.social> 8867 seems like it would be fine compared to 7999 for those reasons. If it solves the issue presented in the PR, then fine with me. Would be curious to see how it performs relative to 7999 too

<r​brunner7:monero.social> Alright. We are well past the hour. Allow me to close the meeting proper while the detailed discussions about serialization and other things go on of course. Thanks everybody for attending, read you again in 1 week, place to be decided.

<k​ayabanerve:monero.social> It claims to be JSON. It is not. It at least needs to be made hex.

<0​xfffc:monero.social> I have feeling we have opened a can of worms.

<0​xfffc:monero.social> ( 7999 vs 8867 vs fixing serialization limit )

<o​frnxmr:monero.social> 7999 vs 8867 can was opened 2+yrs ago

<k​ayabanerve:monero.social> Also, it's unclear how to parse it with a custom parser. It isn't spec compliant? Is its binary guaranteed to not to have instances of "? Are some sequences unrepresentable?

<s​needlewoods:monero.social> thank you everyone, seems there are enough topics to justify a dev-meeting

<k​ayabanerve:monero.social> If it's not spec compliant, it's not properly documented, and it's quite possibly incomplete, it needs revamping.

<0​xfffc:monero.social> I belie we can use the serialization as standalone library. Why not write a benchmark suite, and winner takes all.

<o​frnxmr:monero.social> SNeedlewoods @sneedlewoods:monero.social: i was never against a dev meeting, ftr

<j​berman:monero.social> hinto's proposal I believe to keep the code so it continues to function as is, and mentioning it's deprecated in documentation seems fine to me

<0​xfffc:monero.social> Not gonna lie. -dev meeting was more interactive :))

<h​into:monero.social> If FCMP++ breaks the endpoint semantics anyway, can't it stay until post HF, then be removed afterwards?

<j​effro256:monero.social> A benchmark shouldn't be the ONLY factor, since readability and maintainability is also important for open-source health

<j​berman:monero.social> I see, ya, merging timelines with fcmp's make sense on that front

<j​effro256:monero.social> FCMP++ doesn't inherently break `get_output_distribution` semantics though

<0​xfffc:monero.social> At least it is an objective starting point though.

<j​effro256:monero.social> I think you'll find that both of them are *significantly* faster than the core codebase, especially in the worst case

<0​xfffc:monero.social> ( just a suggestion. Not saying it is the way to move forward )

<0​xfffc:monero.social> Quick question. The interface is same, or they have completely different interface?

<h​into:monero.social> jeffro256: okay, in that case I think it makes sense for it to remain indefinitely, be clearly deprecated in documentation, and have a sane `_v2` version

<0​xfffc:monero.social> ( quick question. The release number should be 18.3.4 or 18.4.0? )

<0​xfffc:monero.social> ( apologies. Too many “quick questions” )

<s​needlewoods:monero.social> 18.3.4 afaik

<o​frnxmr:monero.social> Historically it _should_ be 18.4.0, id think

<o​frnxmr:monero.social> We usually the major.minor.patch for bugfix releases

<j​effro256:monero.social> The interfaces differ in a lot of ways

<j​effro256:monero.social> It would be really hard to lay out all the differences right here right now, but I'd be happy to DM

<0​xfffc:monero.social> Will dm you. If we want a benchmark suite to do a performance comparison. It should be a fair one. Thanks.

<k​ayabanerve:monero.social> You now need to use a new pool for a new distribution. I wouldn't be surprised if a lot of people hardcoded the pool to 0.

<v​tnerd:monero.social> 0xfffc: the interfaces are different. 7999 only supports p2p, whereas 8867 supports p2p, json, and msgpack via c++ interface (msgpack is written in LWS already but not in 8867). 7999 changes macros for existing code, whereas 8867 is compatible with existing macros with the exception of trailing semicolons that was used ina few places of the RPC code

<v​tnerd:monero.social> I'm not sure how much work it is to add different formats to 7999, Id have to look at it agajn

<j​effro256:monero.social> Why a new pool? Are you saying that because the new output definitions are not backwards compatible with CLSAG?

<v​tnerd:monero.social> I _think_ it requires unique template expansions to foreach format, whereas 8867 allows for a single base type instead, to cut down on template expansion and executable size (with a corresponding runtime hit to vtable usage). 8867 can expand to each unique format too if the runtime hit seems too big

<k​ayabanerve:monero.social> Because we're now including all transparent amount outputs?

<j​berman:monero.social> the new pool is the set of all outputs unified (includes pre-rct and post-rct)

<k​ayabanerve:monero.social> It's the superset of all prior pools?

<j​effro256:monero.social> Oh I see what's you're saying now. That fact still doesn't break the backwards behavior of `get_output_distribution`, though, even if it's less useful, so I still think it's worth keeping the old version around in some form

<k​ayabanerve:monero.social> I'm not saying get rid of it.

<h​ardenedsteel:monero.social> > The design is intended to maximize privacy of the source of a transaction by broadcasting it over an anonymity network, while relying on IPv4 for the remainder of messages to make surrounding node attacks (via sybil) more difficult.

<h​ardenedsteel:monero.social> is that true? IPv6 support isn't completed?

<k​ayabanerve:monero.social> I'm saying we're changing how it's almost certainly called, removing usage of getting output info in TX construction, and adding new routes to use during TX construction.

<h​ardenedsteel:monero.social> > The design is intended to maximize privacy of the source of a transaction by broadcasting it over an anonymity network, while relying on IPv4 for the remainder of messages to make surrounding node attacks (via sybil) more difficult.

<h​ardenedsteel:monero.social> github.com/monero-project/monero/bl…b/master/docs/ANONYMITY_NETWORKS.md

<h​ardenedsteel:monero.social> is that true? IPv6 support isn't completed?

<j​effro256:monero.social> Yes, there

<k​ayabanerve:monero.social> With so many semantic changes to practical use, why would we not also get the syntax changes out of the way?

<k​ayabanerve:monero.social> (fixing a broken, undocumented route which we still have yet to settle if it's complete or not)

<k​ayabanerve:monero.social> Else we have two nontrivial RPC updates with two migration guides. I just want to unify them into a single event.

<k​ayabanerve:monero.social> The only breaking change I've discussed so far is fixing the ones which claim to be JSON and aren't. I'm not proposing removing methods at this time.

<k​ayabanerve:monero.social> If you want to make a well-defined spec for the encoding they do, if you even can, update their documentation, and remove all claims they're JSON, you're welcome to do so to get me to drop this topic BTW.

<k​ayabanerve:monero.social> Else we can just make them explicitly binary methods or use hex.

<j​effro256:monero.social> Oh yes I understand, I wasn't trying to suggest that you were suggesting removing any instance of `get_output_distribution`, but I think trying to fix this *one* problem with the JSON encoding is NOT going to be backwards compatible (I could be wrong about this premise). Thus, I support making a *new* endpoint (or at least a new way to call it) with these new semantics and syntax,<clipped message>

<j​effro256:monero.social> while still keeping the old one to support currently deployed services

<k​ayabanerve:monero.social> It won't be. We should make the breaking change (its removal) at the same time as we make all other significant changes.

<k​ayabanerve:monero.social> I don't support endlessly supporting a broken endpoint when migration should be trivial (oh no, a call to decode hex, the overhead, the horror)

sorry for interrupting again, but why not deprecate them all and introduce /v2 and give a timeline to remove /v1 endpoints?

<k​ayabanerve:monero.social> I'm calling for the removal timeline to be the FCMP++ HF.

<k​ayabanerve:monero.social> I don't care when they're deprecated, I'd just rather make all notable changes at one moment.

<k​ayabanerve:monero.social> Making the HF the deprecation, so people change to the FCMP RPC methods AND stop using the deprecated method, then removing it however long after, would also be fine.

<v​tnerd:monero.social> A further update on 7999 - it replaced the binary RPC too, but not json

<k​ayabanerve:monero.social> We can deprecate even earlier, helping out Cuprate, but then we twice need people to update their RPC callers (once for breaking changes, once for practical, not once for both).

<k​ayabanerve:monero.social> As long as the method is deprecated *during the FCMP HF binary release*, so users can only update once at that specific point, I'm happy with timeline.

<j​berman:monero.social> "endlessly supporting a broken endpoint" in this case means just not touching the code, and is pretty trivial. breaking changes across the ecosystem I think is less trivial

<j​berman:monero.social> deprecating in documentation I think is fine

<k​ayabanerve:monero.social> jberman: You're not only proposing tech debt, you're wrong.

<j​berman:monero.social> (and intro'ing a new _v2 endpoint)

<k​ayabanerve:monero.social> Cuprate has to implement this to achieve parity

<k​ayabanerve:monero.social> Cuprate having to implement a broken method which is fundamentally undocumented is not trivial.

<k​ayabanerve:monero.social> They can just not bother. Then we have two different RPC specs.

<v​tnerd:monero.social> hardenedsteel: the daemon supports ipv6, except when using a proxy. I'm working on ipv6 support now for that

<v​tnerd:monero.social> How many people using this endpoint are going to switch to cuprate?

<k​ayabanerve:monero.social> Do we want to constantly discuss how some impls only have some routes and open that door, or do we want to remove *a broken endpoint* and have the ability to clean up our own code in that regard?

<k​ayabanerve:monero.social> That doesn't change any alt impl must support this or must maintain its own list of supported methods vtnerd

<h​ardenedsteel:monero.social> should i update the docs then? matrix.to/#/#monero-dev:monero.soci…H0jBNHKd03sNJJx2dSE8f7A5ftutn1NOcyI

<k​ayabanerve:monero.social> I don't even know who uses this method now so it's so cursed. I'd guess its only used internally to the project?

<k​ayabanerve:monero.social> Which means no one should care if the project stops using it, and later removes it.

<j​berman:monero.social> lws + openmonero use it as well

<s​yntheticbird:monero.social> Please guys deprecate binary json for cuprate sanity

<s​yntheticbird:monero.social> this is a cry for help

<k​ayabanerve:monero.social> Even if it wasn't for Cuprate I'd be up in arms over this. Broken methods shouldn't be retroactively declared valid with a lifetime promise of support.

<v​tnerd:monero.social> LWS doesn't use that endpoint, it uses zmq

<k​ayabanerve:monero.social> OpenMonero will have to make changes for FCMP++. While there, they can stop using a broken method and move to a working one. Then we can deprecate an undocumented standards and remove their custom parsers.

<j​effro256:monero.social> There are definitely other encoding schemes, but as a note on hex, using it here would make the RPC call (an already heavy call at ~5MB) about 2x heavier

<k​ayabanerve:monero.social> Then use bin

<k​ayabanerve:monero.social> Why have this as broken JSON in the first place?

<v​tnerd:monero.social> OpenMonero isnt really doing active development afaik, so if broken it will most likely just stop working until someone outside the project issues a pr

<k​ayabanerve:monero.social> They'll already break with FCMP++s.

<k​ayabanerve:monero.social> So that argument doesn't inherently hold so long as we sync their timelines, as I'm advocating, IMO.

<j​effro256:monero.social> IIRC it is used in other places outside of `get_output_distribution` too ;(

<s​yntheticbird:monero.social> get_txpool_backlog iirc

<k​ayabanerve:monero.social> Wow, we have multiple broken, undocumented methods. We should fix them...

<s​yntheticbird:monero.social> tbf it is documented

<j​berman:monero.social> @vtnerd this isn't calling the JSON endpoint github.com/vtnerd/monero-lws/blob/2…a7c267f887/src/rest_server.cpp#L533 ?

<s​yntheticbird:monero.social> and iirc txpool backlog have a boolean to toggle binary

<k​ayabanerve:monero.social> SyntheticBird: what's the rules? It isn't JSON

<k​ayabanerve:monero.social> Is the encoded binary guaranteed to not have "\"", enabling use of " \"" for termination?

<s​yntheticbird:monero.social> its literally raw binary so ig there are no guarantees

<k​ayabanerve:monero.social> How is that guarantee enforced when "\"" is a valid single byte <128? Is it using a base64 encoding and "\"" > 64 in ASCII?

<k​ayabanerve:monero.social> Wow, it's almost like it's undocumented how to properly handle it and likely incomplete (there's presumably some binary sequence it'll just error on)

<s​yntheticbird:monero.social> its epee encoding

<k​ayabanerve:monero.social> You can't have raw binary in JSON and claim it's documented/a valid encoding.

<j​berman:monero.social> this is a fine argument to me

<s​yntheticbird:monero.social> i meant documented in the common sense (we have an entry on doc website)

<s​yntheticbird:monero.social> but yes its completely ridiculous

<k​ayabanerve:monero.social> It doesn't matter how you define it. It's still its own thing with questionable parser rules. Is it hit string start, switch to epee read, read till epee exhausted, then switch back to JSON?

<s​yntheticbird:monero.social> probably yes

<k​ayabanerve:monero.social> The fact no one can immediately answer how it handles the context switch shows this isn't documented, even if the fact it's broken is documented.

<v​tnerd:monero.social> jberman @jberman:monero.social: that line is calling the zmq endpoint, which has its own unique serialization code. Merging this with the http rpc serialization is one of my nice to haves of the 8867 patch (eventually). Not all the endpoints can be merged to same code iirc

<k​ayabanerve:monero.social> The question is how exactly it works and the exact spec it isn't broken under.

<k​ayabanerve:monero.social> I'd ping jeffro256 on if you can read epee until exhausted like that, without issue. I don't recall if the outer object declares the amount of fields it contains.

<b​oog900:monero.social> It's a bit-wise copy of the type into a string and then the that sting is transformed using this:

<b​oog900:monero.social> github.com/monero-project/monero/bl…pee/src/parserse_base_utils.cpp#L42

<b​oog900:monero.social> it's not epee bin

<k​ayabanerve:monero.social> Oh, so it's a custom base 250

<s​yntheticbird:monero.social> that's even funnier (my bad for saying it was epee)

<k​ayabanerve:monero.social> ... bass 248?

<k​ayabanerve:monero.social> *base 248

<v​tnerd:monero.social> kayabanerve @kayabanerve:monero.social: epee binary has an explicit element count for arrays

<k​ayabanerve:monero.social> Or is it just escaping and it is suboptimally using all 256 characters 🤔

<s​yntheticbird:monero.social> try casting a type into a string in rust like cpp challenge.

<s​yntheticbird:monero.social> difficulty: impossible

<k​ayabanerve:monero.social> vtnerd: I am aware it's self describing :) I was just unsure for the outer most object.

<k​ayabanerve:monero.social> If the outer most object is considered an array, explicitly lengthed, ACK

<k​ayabanerve:monero.social> Anyways. Remove all this, don't claim non-JSON is JSON, simplify lives of other people. We do force people to move to a new .bin but we're already practically forcing rewriting RPC callers for the new FCMP++ semantics/TX construction.

<k​ayabanerve:monero.social> Or keep this forever as a headache to us to spare the headaches of... us, except it obviously doesn't spare us, and MyMonero.

<k​ayabanerve:monero.social> I've spoken abundantly and will drop out now :p

<s​yntheticbird:monero.social> so... are there any arguments against deprecating binary json ?

<j​berman:monero.social> get_output_distribution as it currently exists will have no value to any wallets trying to create txs with fcmp's. As it currently exists, it can be deprecated once fcmp's are live, and replaced with a sane JSON endpoint with 0 issue to live services. We can implement a _v2 endpoint today that functions today and that could be the replacement for the get_output_distribution endpoi<clipped message>

<j​berman:monero.social> nt that is dropped once fcmp's are live. The v2 endpoint could also be designed to cleanly support fetching the unified distr for fcmp's

<o​frnxmr:monero.social> Meeting done? Thanks everyone

<s​yntheticbird:monero.social> and about get_txpool_backlog?

<s​yntheticbird:monero.social> should it be deprecated too ?

<j​berman:monero.social> I'm fine with a 12 month deprecation timeline for it. the argument not to support broken endpoints I think is sound

<s​yntheticbird:monero.social> Sounds fine (another w for the crabs)

<v​tnerd:monero.social> OpenMonero is using the binary endpoint, so it looks like it won't be affected

is openmonero not dead?

<s​yntheticbird:monero.social> vthor_ this is a secret, never say it is dead again

:S

I was searching for it but didn't find a sign of life in the last 5years?

<v​tnerd:monero.social> github.com/monero-project/monero/bl…2Fsrc%2Fparserse_base_utils.cpp#L42

<v​tnerd:monero.social> That's the escape function, it's simply doing a backslash on key characters, allowing it to technically to be parsed, if still invalid json

vtnerd: autch

I planned to take whole monero source appart and try to remove all dependencies and modularize it, so when you want to use the code or parts you could do that without the nee to chew the whole source and drag it into the own source, but now I start to doubt a bit, how it seem a fast moving target. Am I wrong?

<s​yntheticbird:monero.social> good luck, see you in 12 months in mental asylum

<s​yntheticbird:monero.social> (you are right, but you'll suffer)

<s​yntheticbird:monero.social> modularizing a huge cpp codebase with technical debt (that is actively moving) is absolutely insane

It will be easier to rewrite in Rust tbh

<s​yntheticbird:monero.social> Cuprate already have it. Next step is Swift node (i'm racist of Go)

:D

sech1: rewrite in another language will be easier when you understand all, and so I thing first step would be to transform the code to better understand each piece, get it sortet out, and then reimplement in another language.

<s​yntheticbird:monero.social> that's the neat part, you don't transform the code

s​yntheticbird: well I'm insane, so I could do insane stuff, too. What you don't like on go, was really thinking with endgoal rust/zig/go

<s​yntheticbird:monero.social> oh forgot about zig

hm, I learn mostly through throwing the wrench into the gears and look where the parts fly :D

<s​yntheticbird:monero.social> crash test approach, love it

I mean I do a long time security related stuff, but I'm no cryptographer, I use crypto how it's given. But after what I read in the source code, a lot of source is bloat and makes the things only more complicated, when I see alone this epee stuff, I mean it Qt/C++ so when I can do Simply QString.toHex() and have the same result then jumping through three methods and land then in an epee lib, my head starts to spin, and then I wonder

why not in Qt/C++ or in c (is this performance plus it realy worth it?)

<v​tnerd:monero.social> There's no need to add qt dependency, especially since hex conversion is fairly simple. It's a bit complicated in our code because we convert to/from struct directly to/from hex - there's no intermediate step like copying to qstring

.merges

.merge+ 9384 9385

Added

.merge+ 9423

Added

<o​frnxmr:monero.social> Miniupnp needed?

<o​frnxmr:monero.social> monero-project/monero #9367

<k​ayabanerve:monero.social> Just use my Rust rewrite vthor_, only half /s

<k​ayabanerve:monero.social> I already modularized the ZK proofs, transaction structs, wallet code, etc.

<k​ayabanerve:monero.social> So each section should have minimal dependencies and clear API boundaries.

<o​frnxmr:monero.social> this one to lower the amount of log files created default

<o​frnxmr:monero.social> monero-project/monero #9428

k​ayabanerve: that sounds cool, this is cuprate, or? Thought it was only substitute for monerod, so I never looked inside yet

<b​oog900:monero.social> Cuprate uses parts of it, but monero-serai is separate: github.com/serai-dex/serai/tree/develop/networks/monero

Thank you boog, I never looked there inside. That looks promising :) So there is monero-serai, but there is written: "monero-serai originally included wallet functionality. That has been moved to monero-wallet.", does that mean/serai-dex/serai/tree/develop/networks/monero/wallet?

<b​oog900:monero.social> yeah, `monero-wallet` is the crate name