07:19:00 <mj-xmr[m]> <selsta> ".merge+ 7882 7881 7879 7878 7849..." <- +7780  ?
08:33:00 <selsta> mj-xmr[m]: it was already added
08:39:32 <mj-xmr[m]> .merges
08:39:32 -xmr-pr- 7780 7805 7821 7822 7832 7838 7845 7846 7848 7849 7878 7879 7881 7882
08:39:40 <mj-xmr[m]> ah sry
08:39:50 <selsta> np
14:36:14 <rbrunner> UkoeHB: I just tried 1/3 with the MMS. Worked flawlessly after your little MMS modification.
14:36:33 <UkoeHB> Great!
14:36:50 <rbrunner> 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.
14:37:24 <UkoeHB> Oh huh didn't think about that
14:37:48 <UkoeHB> Btw would you mind also testing if wallets made pre-update can still make tx post-update?
14:38:13 <rbrunner> 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
14:39:09 <rbrunner> Yes, I will now try to find some old wallets, or build wallets with master, and then use them on your branch.
15:08:20 <rbrunner> I found a 2/3 wallet triplet from 2019. Still transacts flawlessly on your branch.
15:09:51 <UkoeHB> woohoo 🎉
15:12:05 <rbrunner> Yeah, modifying such complex code and everything works is something.
15:14:02 <UkoeHB> Thanks :) all the tests in `unit_tests`, `core_tests`, and `functional_tests`really helped me work out the kinks.
15:15:53 <moneromooo> ^_^
15:29:41 <rbrunner> 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.
15:34:17 <moneromooo> Presumably you'd be the one to know.
15:34:44 <moneromooo> I don't remember going to change that code.
15:36:08 <moneromooo> 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".
15:39:02 <rbrunner> 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 ...
15:40:04 <rbrunner> Not very important anyway, just wondering. Too lazy right now to search through the code :)
15:45:10 <moneromooo> I don't remember that, sorry.
15:45:22 <rbrunner> No problem, thanks.
15:50:20 <mj-xmr[m]> <UkoeHB> "Thanks :) all the tests in `unit..." <- There are ways to speed up core and functional tests. Like here https://github.com/mj-xmr/monero-patches and search for `core-tests-cache.patch` or here: https://github.com/monero-project/monero/blob/master/tests/README.md#mining-test
15:51:06 <UkoeHB> mj-xmr[m]: I used filters to run all the multisig-only tests
15:51:23 <mj-xmr[m]> That's clever enough.
15:52:05 <UkoeHB> https://www.irccloud.com/pastebin/7x93oPvP/
15:54:28 <mj-xmr[m]> UkoeHB: This will make a great contribution to docs/COMPILING_DEBUGGING_TESTING.md#debugging-in-codeblocks-cb , if you don't mind.
15:54:48 <mj-xmr[m]> .... don't mind me adding it.
15:55:23 <UkoeHB> Sure :)
15:56:54 <UkoeHB> I think the `tests/README.md` needs an overhaul
16:47:47 <selsta> remaining PRs that need review before release: 7805, 7825, 7873/7874
16:56:02 <selsta> 7805 is trivial, 7825 is backport of already reviewed patches, 7873/4 is the only complicated thing
17:24:22 <rbrunner> 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)
17:27:17 <selsta> we will branch from master for the next hard fork
17:27:54 <selsta> but we also did v0.16 with dandelion++ without hard fork
17:27:55 <selsta> it depends
17:31:37 <rbrunner> Alright
17:32:15 <selsta> In general I try to include all bug fixes in release branch
17:32:20 <selsta> and feature only stuff in master
18:50:28 <sgp_[m]> 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
18:50:48 <sgp_[m]> but that that point it was not a super fitting discussion for an MRL meeting; it's a better fit for a dev meeting
18:52:09 <sgp_[m]> 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)
18:52:54 <sethsimmons> The case for a hard fork is likely even stronger with Seraphis/Lelantus Spark looking promising and likely even address-compatible.
18:53:08 <sethsimmons> Interim HF with ring-size bump, specifically.
18:54:14 <selsta> I want to get this release out then we can talk / make a meeting about HF
18:56:21 <Rucknium[m]> If I understand correctly, the mixin selection algorithm fix doesn't require a HF since it all happens at the wallet level.
18:57:02 <sethsimmons> Yeah, we're mixing things up here, I think.
18:57:16 <sethsimmons> sgp_: and I were talking about a potential HF after this release.
18:57:27 <sethsimmons> This point release is necessary for other reasons and does not need a HF.
19:05:14 <tobtoht> 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.
19:05:19 <tobtoht> We can set a date after the upcoming point release as selsta mentioned.
19:07:07 <sethsimmons> Agreed.
19:13:05 <sgp_[m]> 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
19:17:23 <sgp_[m]> 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
19:17:49 <gingeropolous> 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
19:17:53 <sgp_[m]> I lean more conservatively towards 15 personally
19:18:24 <sgp_[m]> gingeropolous: it's not about enfocring that particular change, it's about forcing ***a*** change
19:19:52 <jberman[m]> <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
19:20:09 <ArticMine> My understanding is that ring size is consensus while the selection algorithm is not
19:20:13 <gingeropolous> 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
19:20:52 <sgp_[m]> I think we're all in agreement here but saying different pros/cons of the same thing :p
19:21:11 <gingeropolous> nonsense!
19:21:31 <Rucknium[m]> I have a half-baked draft of a method to enforce proper mixin selection at the blockchain consensus level, BTW.
19:21:41 <gingeropolous> buh wut
19:21:47 <sgp_[m]> jberman: for clarity, can the second adjustment be fixed today if there was a hardfork today?
19:22:36 <Rucknium[m]> gingeropolous : Was that wut for me?
19:23:09 <Rucknium[m]> jberman and UkoeHB  have seen the method.
19:23:51 <jberman[m]> 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
19:24:42 <sgp_[m]> 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
19:26:23 <jberman[m]> 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
19:28:04 <jberman[m]> that's what you said, sorry, don't mind me haha
19:28:53 <sgp_[m]> is this the only blocker on a major release you are aware of? everything else seems ready to go afaict
19:30:24 <jberman[m]> It's not a blocker, next release can go out without fixing integer truncation
19:32:03 <jberman[m]> * caveat: except in the circumstance where divide by 0 is possible. That's what PR 7845 is for for next release
19:33:31 <Rucknium[m]> 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.
19:34:11 <sethsimmons> Rucknium[m]: I thought this wasn't possible to gather new data on as true spends are not known post-RingCT/ring-size enforcement?
19:34:35 <sethsimmons> And that's the reason that Bitcoin spend data and old Monero spend data were compared for ring selection purposes?
19:34:48 <sethsimmons> (This is likely a better discussion for another time/channel, I guess)
19:35:25 <Rucknium[m]> Spoiler alert: the real spend distribution is easily calculated by subtracting out the parametric gamma pdf that is plain in the wallet code.
19:35:50 <Rucknium[m]> ..under some assumption
19:35:50 <sethsimmons> Huh, cool!
19:36:25 <UkoeHB> The possibility to do that has been known, but never actually executed afaik (until now perhaps)
19:36:35 <sgp_[m]> yeah not cool if that actually worked - he is implying you could find the real spent output on average there
19:36:53 <jberman[m]> 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
19:37:04 <UkoeHB> Rucknium[m]: doesn't that only give you the delta between the true distribution and the gamma?
19:38:48 <Rucknium[m]> 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.
19:39:29 <Rucknium[m]> One challenge with all this is I am not sure how carefully we need to handle information about possible attacks.
19:40:44 <Rucknium[m]> 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."
19:41:33 <sgp_[m]> 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
19:41:40 <Rucknium[m]> I saw the problems within a few minutes of really concentrating on what jberman was doing in his hotfix
19:41:54 <Rucknium[m]> sgp_[m]: True
19:46:37 <sgp_[m]> 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
19:46:55 <sgp_[m]> obviously it would be nice to have the latest jberman changes though
19:50:20 <ArticMine> I agree late fall is a good time for an update
19:51:29 <sethsimmons> Same, would like to see that.
19:52:32 <luigi1112> 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)
20:11:27 <sgp_[m]> okay great, what else is needed to get this moving then - a meeting?
20:26:30 <luigi1112> doubt it but maybe
20:29:41 <selsta> PRs remaining that need a review: 7805, 7825
20:29:45 <selsta> both are easy to review
20:30:06 <luigi1111w> .merges
20:30:06 -xmr-pr- 7780 7805 7821 7822 7832 7838 7845 7846 7848 7849 7878 7879 7881 7882
20:50:22 <gingeropolous> Rucknium[m], yes :)
20:54:52 <Rucknium[m]> 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.
20:59:03 <gingeropolous> 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?
21:00:07 <gingeropolous> 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?
21:00:14 <Rucknium[m]> Seth has moved that discussion to an e2e encrypted Matrix room.
21:00:38 <gingeropolous> uh which room
21:00:57 <gingeropolous[m]> cause im on matrix like cool p33ps
21:01:25 <sgp_[m]> 😂
21:01:44 <sethsimmons> gingeropolous[m]: Invited.
21:30:16 <selsta> .merges
21:30:16 -xmr-pr- 7805 7822
22:32:49 <ArticMine> .merges
22:32:49 -xmr-pr- 7805 7822
22:56:01 <ArticMine> .merges
22:56:01 -xmr-pr- 7805 7822
23:41:50 <ArticMine> What is the status of PR 7819?