<selsta> ".merge+ 7882 7881 7879 7878 7849..." <- +7780 ?

mj-xmr[m]: it was already added

.merges

ah sry

np

UkoeHB: I just tried 1/3 with the MMS. Worked flawlessly after your little MMS modification.

Great!

I worried a little whether the MMS would "understand" that with 1/3 a generated tx is immediately spendable, but that worked as well, somehow.

Oh huh didn't think about that

Btw would you mind also testing if wallets made pre-update can still make tx post-update?

Of course building 1/3 wallets is a crazy amount of work compared with someone simply creating a wallet and then sending files or seed to 2 other people, but edge-cases supported is nice nevertheless

Yes, I will now try to find some old wallets, or build wallets with master, and then use them on your branch.

I found a 2/3 wallet triplet from 2019. Still transacts flawlessly on your branch.

woohoo 🎉

Yeah, modifying such complex code and everything works is something.

Thanks :) all the tests in `unit_tests`, `core_tests`, and `functional_tests`really helped me work out the kinks.

^_^

moneromooo: Do you know on the top of your head whether the option to read "old" serialized files is still there, e.g. to read .mms files from 2019? I could not find the corresponding CLI wallet option in the "--help" info.

Presumably you'd be the one to know.

I don't remember going to change that code.

Ah, might have changed when I switch wallet serialization code. If it changed mms files, then the answer is "probably works, but likely not really tested much".

I dimmly remember that at least at the beginning there indeed was an option to read "old" files on request, but I don't remember the details myself, and was wondering whether you had declared the "transition period" to be over and cancel the option ...

Not very important anyway, just wondering. Too lazy right now to search through the code :)

I don't remember that, sorry.

No problem, thanks.

<UkoeHB> "Thanks :) all the tests in `unit..." <- There are ways to speed up core and functional tests. Like here github.com/mj-xmr/monero-patches and search for `core-tests-cache.patch` or here: github.com/monero-project/monero/bl…/master/tests/README.md#mining-test

mj-xmr[m]: I used filters to run all the multisig-only tests

That's clever enough.

UkoeHB: This will make a great contribution to docs/COMPILING_DEBUGGING_TESTING.md#debugging-in-codeblocks-cb , if you don't mind.

.... don't mind me adding it.

Sure :)

I think the `tests/README.md` needs an overhaul

remaining PRs that need review before release: 7805, 7825, 7873/7874

7805 is trivial, 7825 is backport of already reviewed patches, 7873/4 is the only complicated thing

Do I understand correctly that currently it's almost fully open when something added to master only will find its way into a release? (if it's not important enough to get backported)

we will branch from master for the next hard fork

but we also did v0.16 with dandelion++ without hard fork

it depends

Alright

In general I try to include all bug fixes in release branch

and feature only stuff in master

Has there been any recent thought about the release schedule? During the last MRL meeting, there was some discussion about possibly doing a late November hardfork since Triptych and surrounding research was still circling with months to go

but that that point it was not a super fitting discussion for an MRL meeting; it's a better fit for a dev meeting

would be good to include the fee fix, the selection fix, BP+, and other misc stuff (possibly also a ringsize bump, but I know some people are touchy about that)

The case for a hard fork is likely even stronger with Seraphis/Lelantus Spark looking promising and likely even address-compatible.

Interim HF with ring-size bump, specifically.

I want to get this release out then we can talk / make a meeting about HF

If I understand correctly, the mixin selection algorithm fix doesn't require a HF since it all happens at the wallet level.

Yeah, we're mixing things up here, I think.

sgp_: and I were talking about a potential HF after this release.

This point release is necessary for other reasons and does not need a HF.

I also support an interim HF (sooner rather than later) with the changes mentioned above, including a small ringsize bump if we can reach consensus about it.

We can set a date after the upcoming point release as selsta mentioned.

Agreed.

while the selection adjustment does NOT require a hardfork, it's still preferable to release with one so that we enforce wallet updates to the new selection algo

I really think ringsize 15 will do us nicely, with some people pushing for more. knaccc recommends 16, many others support 17-19, and articmine recommends 19-25

well.... it doesn't really enforce that, unless the HF includes other things. any wallet developer could fiddle with their code to bump the ringsize without modding this rounding error thing

I lean more conservatively towards 15 personally

gingeropolous: it's not about enfocring that particular change, it's about forcing ***a*** change

<sgp_[m]> "while the selection adjustment d" <- Clarifying, there are 2 known adjustments to the selection algo we need to make, 1: fixing the earliest spent issue, 2: fixing integer truncation. Number 1 is going out with next release. Number 2 is on hold for now, likely until a hard fork, unless it can be proven that it is safe to make beforehand which I'm still working on

My understanding is that ring size is consensus while the selection algorithm is not

yeah, but it doesn't really do that, but this is semantics. with the current protocol there's no way to enforce proper mixin selection. so yeah, core client users will upgrade, but 3rd party is uncontrollable

I think we're all in agreement here but saying different pros/cons of the same thing :p

nonsense!

I have a half-baked draft of a method to enforce proper mixin selection at the blockchain consensus level, BTW.

buh wut

jberman: for clarity, can the second adjustment be fixed today if there was a hardfork today?

gingeropolous : Was that wut for me?

jberman and UkoeHB have seen the method.

sgp_[m]: I'm not certain it's safe to do today. It would cause the algo to select more recent outputs across the entire distribution, and I want to be absolutely sure that is safe to do, and not leaving behind older outputs

okay, so it's not specifically tied to whether the update is part of a hardfork or not, that's what I was getting at

Correct, it's actually possible it could roll out before a hardfork too, since its impact on tx uniformity may not be THAT significant, which will take time to assess some more as well

that's what you said, sorry, don't mind me haha

is this the only blocker on a major release you are aware of? everything else seems ready to go afaict

It's not a blocker, next release can go out without fixing integer truncation

* caveat: except in the circumstance where divide by 0 is possible. That's what PR 7845 is for for next release

A tentative proposal: Assuming a integer truncation fix isn't included in the next release, instead what should happen is re-estimate a gamma distribution (or generalized gamma distribution) on the more recent tx data available than the pre-2018 Moser et al. one. Then including this parametric mixin selection algorithm into a release after this upcoming one, while still working on a more general nonparametric solution.

Rucknium[m]: I thought this wasn't possible to gather new data on as true spends are not known post-RingCT/ring-size enforcement?

And that's the reason that Bitcoin spend data and old Monero spend data were compared for ring selection purposes?

(This is likely a better discussion for another time/channel, I guess)

Spoiler alert: the real spend distribution is easily calculated by subtracting out the parametric gamma pdf that is plain in the wallet code.

..under some assumption

Huh, cool!

The possibility to do that has been known, but never actually executed afaik (until now perhaps)

yeah not cool if that actually worked - he is implying you could find the real spent output on average there

I'm in the process of writing up an issue that will highlight all this/show what it means when you're looking at a chart

Rucknium[m]: doesn't that only give you the delta between the true distribution and the gamma?

When 10 (or any specified number) of mixins is enforced, it's plain as day. The main assumption that you need is that there isn't some other wallet software out there that has been deliberately modified so as to choose mixins from a different distribution.

One challenge with all this is I am not sure how carefully we need to handle information about possible attacks.

I showed the Moser et al 2018 paper to another applied statistician and he saw the same weaknesses in the "countermeasure" that we are using. I didn't ask leading questions, either. I just said, "Read this and tell me what weaknesses you see."

anyway, I think it would be good to get back to the main topic of the release since now this is diving into MRL research :p

I saw the problems within a few minutes of really concentrating on what jberman was doing in his hotfix

sgp_[m]: True

Can we have a dev meeting to discuss this? I think this late fall is a good time for an update since triptych and other research won't be added for a while now, so there isn't much we're waiting for

obviously it would be nice to have the latest jberman changes though

I agree late fall is a good time for an update

Same, would like to see that.

yes. Caveat that fork time be set as close (I'm not 100% sure what lead time yet) to release as possible (like, last pr)

okay great, what else is needed to get this moving then - a meeting?

doubt it but maybe

PRs remaining that need a review: 7805, 7825

both are easy to review

.merges

Rucknium[m], yes :)

gingeropolous : The basic idea is to simply use a hypothesis test of whether the age of the mixins selected by a wallet is consistent with a gamma distribution (or whatever distribution that would be enforced). Done and done.

gotcha. im still tryin to wrap my head around subtracting the pdf to find the real spend. how is it possible to have 11 things on a timeline, then map a particular distribution / pdf to it, and say that 10 of them are what?

because every element has a probability, and those that map closer to the gamma are more likely mixins? wouldn't that be true of any distribution?

Seth has moved that discussion to an e2e encrypted Matrix room.

uh which room

cause im on matrix like cool p33ps

😂

gingeropolous[m]: Invited.

.merges

.merges

.merges

What is the status of PR 7819?