<r​ucknium:monero.social> MRL meeting in this room in about one hour.

<r​ucknium:monero.social> kayabanerve: ^ Remind of the meeting at 17:00 UTC today

<k​ayabanerve:matrix.org> I am aware :) Thank you

<s​yntheticbird:monero.social> also kayaba if you see this, please answer jeffro in lounge

<k​ayabanerve:matrix.org> FYI, the github issue says the 3rd. I noticed when I checked it for the time :p

<r​ucknium:monero.social> Oh. Thanks

<r​ucknium:monero.social> Fixed :)

<c​haser:monero.social> reputational harm didn't stop Veridise from rushing their work, producing questionable proofs and not noting the core problems with Eagen's work

<d​iego:cypherstack.com> Hey guys. I'm a stupid.

<d​iego:cypherstack.com> Its not 70 XMR. Its 175.

<d​iego:cypherstack.com> libera.monerologs.net/monero-research-lab/20250402#c515638

<d​iego:cypherstack.com> gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<s​yntheticbird:monero.social> 🤏 almost

<r​ucknium:monero.social> Meeting time! monero-project/meta #1217

<r​ucknium:monero.social> 1) Greetings

<s​yntheticbird:monero.social> Hi

<c​haser:monero.social> hello

<a​rticmine:monero.social> Hi

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

<r​ucknium:monero.social> We have been greeted by a larger bill :D

<v​tnerd:monero.social> Hi

<s​gp_:monero.social> hello

<0​xfffc:monero.social> hi everyone

Hello

<k​ayabanerve:matrix.org> 👋

<s​yntheticbird:monero.social> A deserved one neitherless

<v​tnerd:monero.social> Hi

<j​effro256:monero.social> Howdy

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

I could make a PR, ready for review, for the improved peer selection with less connections to spy nodes: monero-project/monero #9939

<r​ucknium:monero.social> me: Pushed draft version 0.3 of the MRL research bulletin on subnet deduplication to reduce spy node effectiveness: github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf . boog900 is reviewing it and once done, will be added as a co-author. Also working on our/my MoneroKon presentations.

<a​rticmine:monero.social> I am working on the scaling for FCMP+ The consensus part is done. The fees node relay part I expect to have next week.

<j​berman:monero.social> me: continuing on FCMP++ / Carrot tests, ran into some snags / identified things to fix in wallet behavior

<j​effro256:monero.social> Finally making some real progress on HW device stuff and hot/cold stuff now that I've gotten the major carrot_impl rework out of the way. Also been trying a bit to debug issues that people have sent in

<d​iego:cypherstack.com> Auditing my own finances apparently.

<0​xfffc:monero.social> Addressing the PR comments. Have been off for few days. Will be part time for a few days more. I have already decided and sketched out what to do about the comments. I just have to wrote the code.

<v​tnerd:monero.social> Me: looking at LWS stuff: why /get_random_outs was crashing on osx, and LWS push/truncated tx history stuff

<r​ucknium:monero.social> 0xfffc: The PR you are referring to is the more efficient tx propagation implementation, right?

<0​xfffc:monero.social> Yes

<b​randon:cypherstack.com> Fixing eagen's calculus mistakes

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

<r​ucknium:monero.social> 3) zkSecurity quote for review of Elliptic Curve Divisors for FCMP in parallel to Cypher Stack review. hackmd.io/@rotn/HyyFGZcfxl github.com/cypherstack/divisor_deep_dive

<r​ucknium:monero.social> surae: Maybe I could take a look at the calculus. Probably I would be little help, but there is a small chance.

<k​ayabanerve:matrix.org> My comment from a day ago is still my primary response to immediate questions.

<s​gp_:monero.social> Hey all, I believe that this SoW for a third reviewer of divisors is in the best interest of the Monero community. I would ideally like to get preliminary approval to pursue this contract

<r​ucknium:monero.social> This one?

<r​ucknium:monero.social> > zkSecurity is underestimating, has lower standards, see something not prior seen, or truly just have a domain expert. I'll note the divisors technique, without proofs, has been incorporated into a major paper by cryptographers who presumably believe it tracks. Obviously, the issue is the security proofs, but as zkSecurity's estimate is non-binding, payment is an acceptable flat <clipped message

<r​ucknium:monero.social> rate, and the seemingly worst case is we get another set of security proofs CS still doesn't find up to standards, I'm in favor.

<b​randon:cypherstack.com> Pretty sure we landed on the correct verification equations but more review is better

<r​ucknium:monero.social> Cypher Stack staff should feel free to comment on this issue

<s​gp_:monero.social> This project will aim to remove blockers preventing Monero from using the more efficient divisors technique. As stated in the SoW, it is fixed rate and requires sufficient proof to be delivered. I will work out the final payment details and any other suggested SoW modifications based on the feedback provided during this meeting and prior to this meeting

<r​ucknium:monero.social> Where would the funds come from for the zkSecurity work?

<s​gp_:monero.social> I am asking for a donation from the research CCS

<b​randon:cypherstack.com> More review is better. I am not familiar with the current proposal for review on the table so I can't speak about it. If the reviewers at zksecurity are trustworthy and competent then great. It would be a shame to spend money on people who regurgitate substandard previous work though.

<k​ayabanerve:matrix.org> Yes, Rucknium

<r​ucknium:monero.social> Here's a list of what has to be funded with the remaining FCMP research CCS funds: cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed

<s​gp_:monero.social> the reviewers are Mathias Hall-Andersen and Diego Aranha

<k​ayabanerve:matrix.org> MHA is a coauthor of curve trees.

<r​ucknium:monero.social> AFAIK, the FCMP research CCS has 897 XMR remaining.

<r​ucknium:monero.social> These items have a combined cost of 75,000 USD: Gadgets formal verification, Gadgets impl audit, Circuit impl audit

<s​gp_:monero.social> I also confirm 897

<s​gp_:monero.social> after CS is paid the 175

<c​haser:monero.social> By my calculations, 897 XMR (currently valued at ~$294 000). cryptpad.fr/sheet/#/2/sheet/view/7a…hx2cvkPH8nMbJcHilMoz3vKf+Q+oQ/embed

<j​berman:monero.social> Note that remaining funds tally currently doesn't include the 175xmr to CS. Expected balance is 897.13 including that

<r​ucknium:monero.social> These don't have an estimated cost yet, AFAIK: GSP impl audit, EC Divisors impl audit, Towering curve cycle audit

<r​ucknium:monero.social> ^ AFAIK, those are code audits, not mathematical reviews of the cryptographic soundness of the protocol.

<s​gp_:monero.social> according to my notes, EC divisors is the same as towering curve cycle

<j​berman:monero.social> Presumably we may also have non-divisors reviewed academically (?) and audited

<s​gp_:monero.social> Veridise gadgets/circuits should be shared this week (if not today)

<r​ucknium:monero.social> The zkSecurity quote is 50,000 USD for one week of work by two researchers. Previously, proposed work by zkSecurity to formalize Seraphis was 10,000 USD per week of work (presumably by one person): libera.monerologs.net/monero-research-lab/20230927#c284121

<k​ayabanerve:matrix.org> We have the gadgets verification, impl audit, and circuit audit under our last quote with Veridise.

<k​ayabanerve:matrix.org> cc SGP_ if MAGIC has drawn those XMR yet.

<s​gp_:monero.social> MAGIC has received that donation already

<d​iego:cypherstack.com> fwiw guys, our divisors work is going pretty smoothly. It's a lot of work, but we're making good time.

<s​pirobel:kernal.eu> is it possible to get them to agree to a partial payment upfront sgp_ ? so they have an incentive to put in the extra mile?

<k​ayabanerve:matrix.org> EC divisors lib audit and towering curve cycle lib audit are two items, but both had optimized impls scoped into the contest with audits scheduled for those optimized impls

<b​randon:cypherstack.com> I wanted to be done today but alas

<s​gp_:monero.social> I will specifically propose 50-50 payment for zkSecurity

<k​ayabanerve:matrix.org> In that case, Rucknium, those items had a combined cost.

<s​yntheticbird:monero.social> surae blink twice if you are held hostage

This is what does somehow not square for me, as already ranted yesterady: How zkSecurity can propose 2 person weeks for something Cypher Stack already spent many weeks on, and is not yet finished

<s​gp_:monero.social> I know when valued at a weekly rate, $50k is a lot. But so long as the understanding is that they truly will ensure that we will get a fully finished deliverable that meets our requirements, then $50k is worth it imo

<r​ucknium:monero.social> surae: Diego Salazar Maybe you don't want to say quite yet, but is the divisors work going in the direction of "it is sound", or in the direction of "it is unsound"?

<j​effro256:monero.social> sgp: Towering curve cycle refers to the Helios/Selene pair of curves that we use, plus the technique which allows our curve, ed25519, to plug into that cycle. EC divisiors is a technique under review for FCMPs which is more-or-less "internal" to the membership proof. Even if we don't use divisors, we will always need a curve cycle for FCMPs

<d​iego:cypherstack.com> Sound.

<j​berman:monero.social> Hm, if CS is close to producing another divisors deliverable, perhaps it makes sense to hold on zkSecurity until that deliverable

<b​randon:cypherstack.com> Yeah

<d​iego:cypherstack.com> If things take a terrible turn for the worse, you all would be the first to know pretty quick.

<b​randon:cypherstack.com> Except

<b​randon:cypherstack.com> There are mistakes

<f​reeman:cypherstack.com> Hello yes I would like 50k for one week of work, thank you

<b​randon:cypherstack.com> The correct verification equations we have derived already

<r​ucknium:monero.social> So you will write new proofs and those proofs have to be reviewed by yet another firm, probably

<k​ayabanerve:matrix.org> I did check with surae regarding proximity and they did not recommend delaying the zkSecurity quote, and here encouraged more review.

<b​randon:cypherstack.com> Okay so let me explain a little bit more in detail

<o​frnxmr:monero.social> @rbrunner some people underestimate their time so they can claim that their rates are high. So "1 week = 50k = our rate, even if its really 4 weeks. At best, we make 50k in a week. at worst, we can tell people that our going rate is 50k/week"

<r​ucknium:monero.social> Does the protocol need to be altered, a little, to make it sound?

<k​ayabanerve:matrix.org> Freeman: please email hello⊙cc and I'm sure they'll sort you out :)

<j​effro256:monero.social> Sorry if you've already answered this question, sgp, but is there anything specific to your knowledge that ZKSecurity will do differently (or specific expertise) that will result in a different outcome as CS?

<f​reeman:cypherstack.com> matrix.monero.social/_matrix/media/…rstack.com/EOuiawmkasyiwspvsykDwbOb

<b​randon:cypherstack.com> 1. The Eagan paper had some calculus mistakes which we have corrected.

<b​randon:cypherstack.com> 2. Due to those mistakes the verification equations implemented by kayaba are not correct

<r​ucknium:monero.social> IIRC, at time MRL has had multiple mathematical reviews and/or code audits done by different firms, for the same protocol.

<b​randon:cypherstack.com> 3. Modifying the code to be correct will require further later review. And as kayaba says checking my proofs will also require further review

<s​gp_:monero.social> It is primarily their different way of approaching the problem based on their different experiences

<r​ucknium:monero.social> Does this mean that the FCMP competition coders are coding for the wrong target? I wonder how much of an effect that would have. getmonero.org/2025/04/05/fcmp++-contest.html

<k​ayabanerve:matrix.org> Allegedly, until you demonstrate a full proof forgery on a 180 MHz pentium with 8 MB of RAM to prove it's practical /s

<r​ucknium:monero.social> Answered by surae. Thanks.

<b​randon:cypherstack.com> With this in mind, it seems to me like paying for ZK security to review. The current implementation is not necessarily a good usage of funds. I am biased because I work for cypher stack obviously. if the community wants to pay for this, then...

<k​ayabanerve:matrix.org> (obviously, I joke, and the version of the equations proven secure will be the ones moved forward with)

<k​ayabanerve:matrix.org> Rucknium: No impact if we keep divisors.

<b​randon:cypherstack.com> If this money is going to be spent anyway, and if I had a perfect world, then I would recommend that these researchers start reviewing what I've been writing

<s​yntheticbird:monero.social> Ig we can rejoice that there are no contester that manage to achieve the contest goal. Otherwise the ethical "should we pay them despite being insecure" question would have arrived

<b​randon:cypherstack.com> This would land us on a correct protocol faster rather than recreating wheels over and over again with reviews

<j​effro256:monero.social> Helios/Selene will almost certainly remain the same to my knowledge. Divisors won't, however, if we don't go with divisors..

<k​ayabanerve:matrix.org> and the divisors lib included doesn't include the verification equations, hence why "no impact if we keep divisors"

<b​randon:cypherstack.com> But that library is constructing proofs for the old verification equations

<b​randon:cypherstack.com> Those proofs won't pass the correct verification equations

<b​randon:cypherstack.com> So that code will still need to be modified?

<b​randon:cypherstack.com> So that code will still need to be modified.

<b​randon:cypherstack.com> Sorry voice to text is killing me today

<k​ayabanerve:matrix.org> No, that lib is solely calculating divisors.

<r​ucknium:monero.social> SyntheticBird: `Otherwise the ethical "should we pay them despite being insecure" question would have arrived`: IMHO, there is no question. Of course they should be paid because MRL/Core made that promise. The mistake is MRL's fault on going forward without 100% certainty.

<k​ayabanerve:matrix.org> Does your modified verification statements still require I calculate a polynomial which I refer to as a divisor?

<k​ayabanerve:matrix.org> If yes, then that lib is drop-in regardless.

<s​yntheticbird:monero.social> That was my opinion as well

<k​ayabanerve:matrix.org> The formatting for use in a ZK proof, and verification statements, is a separate lib entirely

<a​ntilt:we2.ee> so compo may not be altered ?

<b​randon:cypherstack.com> Yes and that interpolation code will not require modification

<k​ayabanerve:matrix.org> Right, so this divisors lib in contest scope won't so long as that statement holds true

<b​randon:cypherstack.com> I didn't realize the extra comps were separated, that's good. That means kayabas witness construction code is fine

<j​effro256:monero.social> The _competition_ won't be altered regardless b/c MRL made a promise. Whether or not the results will turn out useful depends on divisor's academic journey

<k​ayabanerve:matrix.org> Yep, one finds the polys, one does the gadget within a ZK proof with the polys.

<s​gp_:monero.social> Fwiw, I solicited this zkSecurity quote because I believed that CS's divisors work was potentially months away from being finished. If this work is expected in the near future, and is compatible with Monero's intended use-case, then I would suggest waiting a week and down-scoping zkSecurity's work to a review of CS's work. But if it keeps getting delayed (it's been delayed many ti<clipped message>

<s​gp_:monero.social> mes, research is hard), I'd rather have a concurrent research effort on this critical blocker (divisors)

<d​iego:cypherstack.com> it has indeed been delayed many many times as we always thought we were close to completion and then hit bear trap after bear trap

<j​effro256:monero.social> Good foresight

<d​iego:cypherstack.com> so I can see how our "things are going well and we might be done soon" is....tenuous

<r​ucknium:monero.social> As I understand, Cypher Stack is close to "some" result. What more would need to be done to prove divisors secure? What about the commentary that the security depends on choosing specific parameters? How can those be chosen and evaluated?

<r​ucknium:monero.social> s/secure/sound

<b​randon:cypherstack.com> I mean, that's part of the process, once we have all of our proofs written, we can assess practical security for concrete implementations

<b​randon:cypherstack.com> But I don't want to say much more about that at the moment

<s​gp_:monero.social> I can hold off on the zkSecurity quote until next meeting. But I definitely don't want to delay such a critical component unnecessarily, indefinitely. Worst case we waste some money to make sure this critical component (which is already a blocker!) is addressed more quickly

<d​iego:cypherstack.com> I think one week's wait is reasonable.

Is cryptography related work really so different from dev work? Imagine I work many weeks to implement something, my boss gets impatient, gives the same work to some other guy who claims to do it in 2 weeks. Does that sound credible?

<s​gp_:monero.social> you have 168 hours 🕐️

<s​gp_:monero.social> :)

<s​yntheticbird:monero.social> pizzas won't be enough...

<d​iego:cypherstack.com> This is kind of what we're saying though. What ZKSecurity would be reviewing would be incorrect (since we've already found incorrect things that we've since rectified or been working on rectifying)

<r​ucknium:monero.social> I also think waiting a week is reasonable. In the meantime, sgp_ , do you think it would be a good idea to ask zkSecurity, informally, about switching the task to reviewing Cypher Stacks's work?

<j​berman:monero.social> I second waiting on a week for divisors review. Additional proposal: what if we request zkSecurity do a holistic review on all already completed proofs? Essentially we get another independent party involved reviewing the academia, and that independent party happens to include a co-author of curve trees

<d​iego:cypherstack.com> So to use your analogy rbrunner, the dev work that takes many weeks to implement is because there was an issue with architecture. The extra time is because the architecture is being tweaked and touched up. The boss gets impatient and gets someone else to do an implementation with the original, flawed architecture.

<s​gp_:monero.social> since their earliest start date is late this month, I'll bring that up next week if applicable

<s​yntheticbird:monero.social> What does holistic review means?

<s​gp_:monero.social> Personally I think this is premature without divisors

<r​ucknium:monero.social> Well, maybe it would be best to bring it up with them ASAP because that specific time "slot" won't necessarily be reserved for FCMP work indefinitely

The zkSecurity proposal contains the following point: "Proving any/all potential holes/inaccuracies left by Bassa"

They will probably move all that out of the way on the first or the second day :)

<j​berman:monero.social> "holistic review" would include a review of all prior proofs, which right now is GBP and FCMP+SA+L composition

<f​reeman:cypherstack.com> Rather optimistic to claim they'll patch ANY/ALL holes, with potentially unbounded pro bono hours, with a timeline of 1 week. Just my two cents.

<b​randon:cypherstack.com> I find it credible that one of the authors of the curve trees paper can knock the crypto part of this out of the park. I am skeptical someone who didn't teach calculus for 10 years would catch the mistakes we caught. Having said that...

<s​yntheticbird:monero.social> optimistic or they are taking adrenaline shot

<b​randon:cypherstack.com> More review is better, it's just better to not reinvent wheels

<s​gp_:monero.social> Personally I think we can move on to the next topic; we'll check in next week

<b​randon:cypherstack.com> Great

<r​ucknium:monero.social> More comments or questions on this agenda item?

<d​iego:cypherstack.com> kthx

<s​gp_:monero.social> jberman: DM me later with what that holistic review would look like, including divisors ideally (if those are done, we can package alltogether)

<j​berman:monero.social> Reason I bring it up now is because I wouldn't want that author to get assigned / work on some other work and then be unavailable. Even if we decide to delay them on reviewing divisors, I think it's worth bringing up that we do want to engage them

<s​gp_:monero.social> I'll stress to them that we're very interested in keeping the time slot with some work

<j​berman:monero.social> I got nothing except thank you Cypher Stack <3

<j​berman:monero.social> I got nothing more on this topic*

<r​ucknium:monero.social> 4) Subnet deduplication in peer selection algorithm to avoid spy nodes. Draft research bulletin, implementation PR: github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf monero-project/monero #9939

<r​ucknium:monero.social> Now we have an implementation ready for review by rbrunner ^

<r​ucknium:monero.social> This triggers two possible events: someone can now review it. And previously we discussed that if such a countermeasure has an implementation, then the method for distinguishing spy nodes, discovered by boog900 , maybe can be published.

<o​frnxmr:monero.social> Without testing etc, i assume this respects --add-priority/exclusive node and --max-connections-per-ip flags? Rbrunner7

Yes.

<r​ucknium:monero.social> Anyone interested in volunteering to review this?

<o​frnxmr:monero.social> add-priority/exclusive dont effect incoming. Does this only deal with outgoing connections?

<o​frnxmr:monero.social> Or does it also effect peer evictions

Yes. It is in fact a very narrow, fully drop-in replacement

Just choosing new peers to connect to differently.

<o​frnxmr:monero.social> Ok thanks

It's a single method that changed

<r​ucknium:monero.social> rbrunner: Does this fix the "futile connection attempt" issue you found, or would that be separate?

Yes, it does fix that. That's a small change in a second method.

<r​ucknium:monero.social> tobtoht, selsta: Any idea yet when the next Monero release version may be? Just wondering about when may be the timeline for needing to get this and other PRs reviewed in time for next release.

<o​frnxmr:monero.social> Anytime, master should be stable, just need to iron out the versioning (v19 instead of v0.18)

<r​ucknium:monero.social> Like I said in updates, I pushed version 0.3 of my draft MRL research bulletin: "Subnet Deduplication for Monero Node Peer Selection" github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<r​ucknium:monero.social> Besides content updates, it now has the MRL research bulletin header and formatting.

<o​frnxmr:monero.social> There havebt been many big recently. Socks5, dynamic bss, some fixes. Txrelay is a bigger one

<o​frnxmr:monero.social> many big prs*

<r​ucknium:monero.social> I don't know if anyone cares about this, but previous MRL bulletin used the [1] citation format. In this draft I use the [Author, Year] format. I prefer the latter format, but if someone prefers MRL keep the old format, I would be willing to change.

<o​frnxmr:monero.social> And guix stuff, since master gets rid of gitian

<r​ucknium:monero.social> I don't know if previous research bulletins had any formal review process. I doubt it. If there was a process, someone let me know. But, anyway, anyone can give feedback on the current draft, of course.

<r​ucknium:monero.social> Anyone have comments on this? IIRC, jeffro256 had some views

<r​ucknium:monero.social> > And previously we discussed that if such a countermeasure has an implementation, then the method for distinguishing spy nodes, discovered by boog900 , maybe can be published.

<a​ntilt:we2.ee> no hurry.

<r​ucknium:monero.social> Let's move to the final item:

<r​ucknium:monero.social> 5) Web-of-Trust for node peer selection.

<j​effro256:monero.social> Since I was blocking the publicization of the technique, it makes sense for me to have to review rbrunner's PR

That's one way to see it :)

<r​ucknium:monero.social> I wonder if it would be a good idea to implement WoT in cuprate first, to see how it would perform on mainnet

<a​ntilt:we2.ee> next step may be to agree on data structures and how the old scoring is actually used today

<r​ucknium:monero.social> jeffro256: I would support that :)

<s​yntheticbird:monero.social> Cuprate was meant to be testing ground for new features

<s​yntheticbird:monero.social> At least cuprate the code, not sure about the Cuprate/cuprate repository

<r​ucknium:monero.social> Of course, a shrewd adversary would no try its attacks on cuprate alone, probably. It would wait until most nodes adopt it.

<r​ucknium:monero.social> would not try*

<s​yntheticbird:monero.social> So are there any values at implementing WoT early into a subset of the network ?

<s​yntheticbird:monero.social> I've no doubt it would be easier to implement on Cuprate than monerod

<s​yntheticbird:monero.social> but does it return valuable data

<r​ucknium:monero.social> IMHO, it would return some valuable data, but probably not complete or sufficient data, alone, to advise on deployment in `monerod`.

<a​ntilt:we2.ee> ... and pr 9933 does introduce quite big changes already - I think these are a good starting point for testing, although releasing these (peer dropping) would need simulation IMHO

<s​yntheticbird:monero.social> We really need that Shadow thingy for simulating thousands of nodes on a machine don't we...

<r​ucknium:monero.social> Shadow could be useful here, yes.

<s​yntheticbird:monero.social> Sure, WoT could be pushed into a specific branch for testing if still deemed worthy from a design standpoint.

<s​yntheticbird:monero.social> boog900 thoughts?

<r​ucknium:monero.social> Any more discussion on this item?

<r​ucknium:monero.social> We can end the meeting here. Thank you everyone.

<a​rticmine:monero.social> Thank you

<a​ntilt:we2.ee> looking foreward to 0xFFFC's report. We have subtile scoring in place, very effective imo -- thanks

<b​oog900:monero.social> I have more of a fundamental question of what WoT is trying to solve?

<b​oog900:monero.social> the spy nodes? or just general misbehavior?

<a​ntilt:we2.ee> plus ddos security

<a​ntilt:we2.ee> but WoT is misleading (thats Zimmermann's term for pgp) - I prefer scoring of quality of service

<a​ntilt:we2.ee> ...like we do already with the "anchor node" code: thats a score of previous success ("good behavior")

rucknium: it depends on if the next release is v0.18.4.1 or v0.19.0.0 branched from master

plan was for v0.19 but it seems a lot of smaller bug fixes are accumulating

so a smaller release before might make sense

<r​ucknium:monero.social> Thanks, selsta