15:03:29 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in 2 hours.
16:59:32 <weechat2> kkkj
17:01:44 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/925
17:01:59 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:02:01 <vtnerd> hi
17:02:04 <rbrunner> hello
17:03:55 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:05:18 <m-relay> <r​ucknium:monero.social> me: I have a draft of comments and statistical simulations on jeffro256's PR 9023 to slightly change the decoy selection algorithm: https://gist.github.com/Rucknium/5562ac14e75e34ee04ed5093c660e083
17:05:41 <m-relay> <j​effro256:monero.social> Thank you for doing that Rucknium
17:06:47 <vtnerd> completed subaddresses in lws, did some bugs and other odds and ends in lws. now working on whether p2p-ssl tests are possible in monerod
17:06:51 <m-relay> <r​ucknium:monero.social> And I think I have a way to find candidate consolidation transactions from PocketChange-like transactions using the Hungarian algorithm. I may share some draft code and results later.
17:07:33 <rbrunner> Is this before OSPEAD, or later alongside OSPEAD?
17:08:07 <hyc> what's up with sorting out the licensing for OSPEAD?
17:08:16 <m-relay> <r​ucknium:monero.social> PR 9023? It can be implemented before OSPEAD. It is a small change that is probably not statistically detectable at current tx volume and ring size.
17:09:01 <rbrunner> Ok. And later OSPEAD will supersede this all anyway, right?
17:09:41 <m-relay> <r​ucknium:monero.social> hyc: The author of the library has said by email that he is OK with open source licensing (instead of no license), but hasn't push the change publicly.
17:10:32 <hyc> we won't begin work on it until that's done
17:10:54 <hyc> I had a summer intern lined up for it but we've lost him now that summer's over
17:11:04 <m-relay> <r​ucknium:monero.social> rbrunner: No. PR 9023 reduces a distortion in the decoy selection algorithm that would have been there regardless of what the original probability distribution was supposed to be.
17:11:25 <rbrunner> I see
17:15:18 <m-relay> <r​ucknium:monero.social> 3) Discussion. What do we want to discuss?
17:17:52 <m-relay> <j​effro256:monero.social> Speaking of decoy selection, is anyone against allowing duplicate membership proof members in Seraphis?
17:18:30 <m-relay> <r​ucknium:monero.social> In a single ring?
17:18:36 <m-relay> <j​effro256:monero.social> Yes
17:19:24 <m-relay> <r​ucknium:monero.social> Would that be done to eliminate the distortion that PR 9023 reduces?
17:20:13 <m-relay> <j​effro256:monero.social> Yeah it would
17:21:49 <m-relay> <r​ucknium:monero.social> I don't think the distortion would become large enough to outweigh "sacrificing" ring member slot by having duplicates. We could try to quantify that.
17:22:55 <rbrunner> Is this for some edge cases where we had a "lull", very few transactions over the last few hours, say?
17:23:01 <m-relay> <r​ucknium:monero.social> If that's the only reason to allow duplicates.
17:24:01 <m-relay> <r​ucknium:monero.social> rbrunner: The way that the current code works, the lull would have to last about a year. I think.
17:25:23 <m-relay> <j​effro256:monero.social> I guess so, but people can always mis-use input slots or otherwise signal that a certain input is the true spend
17:27:09 <m-relay> <r​ucknium:monero.social> Even in the standard wallet2 case you would sometimes have duplicates. That would waste a slot since you  cannot spend an output twice.
17:27:43 <rbrunner> I am afraid I don't fully understand the issue at hand, but duplicating ring members as part of the normal algorithm, even if only rarely, sounds very strange.
17:28:55 <m-relay> <j​effro256:monero.social> Fair enough
17:32:12 <m-relay> <r​ucknium:monero.social> My simulations with realistic data directly from monerod's `get_output_distribution` call suggests that the distortion is minor. The KS statistic is below 0.01 in the 4 scenarios I ran.
17:33:03 <rbrunner> In any case, it's pretty counter-intuitive to claim that a ring with a duplicate would be better somehow than a ring where just any random decoy gets picked to get rid of the duplicate ...
17:34:28 <rbrunner> But well, maybe intuition is not a good approach here :)
17:35:11 <m-relay> <j​effro256:monero.social> Yeah in either case the difference would be tiny
17:35:14 <m-relay> <r​ucknium:monero.social> rbrunner: I have not done a rigorous analysis of that, but at this moment I agree.
17:35:32 <m-relay> <j​effro256:monero.social> Yeah intuition might be correct here
17:37:54 <m-relay> <r​ucknium:monero.social> The problem that PR 9023 fixes involves the large set of candidate decoys that are chosen to make sure there are enough spendable outputs once the outputs with custom unlock time and the longer (60 block) coinbase lock are removed from the candidate set.
17:38:42 <m-relay> <r​ucknium:monero.social> More things to discuss? Anything about the CCS theft?
17:39:57 <m-relay> <j​effro256:monero.social> My initial idea for a solution was to have an RPC request which collects all unusable outputs *before* picking, then it would work 100% of the time without having to pick extras, but it would be like 15x more work lol
17:40:41 <m-relay> <j​effro256:monero.social> rbrunner7, tangentially related to the CCS theft, do you know how many people use MMS?
17:41:08 <m-relay> <j​effro256:monero.social> Like are you aware of any groups or forums etc
17:41:29 <rbrunner> Not many, I am pretty sure. It does not work with the latest version of PyBitmessage, and only a few days ago somebody told me that.
17:41:55 <m-relay> <j​effro256:monero.social> Oh did they change the API?
17:42:03 <rbrunner> I made a small PR to get it working again. With that, people can at least easily play with multisig, to get an impression
17:42:17 <rbrunner> No, two more strange error messages to ignore
17:43:00 <m-relay> <j​effro256:monero.social> I tried finding other BitMessage implementations besides PyBitMessage, do you know of any?
17:43:28 <rbrunner> And well, there is no way to deny that PyBitmessage is still on Python 2, and that's end of life. Not a good starting point if you want to get more secure
17:43:32 <m-relay> <j​effro256:monero.social> I ask b/c I tried setting up the MMS but Ubuntu 23 doesn't support pyqt4 so I can only use it as a daemon
17:43:44 <m-relay> <j​effro256:monero.social> MMS -> PyBitMessage
17:43:57 <rbrunner> I am pretty sure that PyBitmessage is the only implementation that has an API, which is crucial
17:44:50 <rbrunner> The latest version is available as an appimage which solves those problems quite nicely
17:45:33 <m-relay> <j​effro256:monero.social> Okay I'll take a look thanks
17:45:56 <rbrunner> https://appimage.bitmessage.org/releases/20230116/
17:46:18 <rbrunner> And the PR needed to make it work: https://github.com/monero-project/monero/pull/9059
17:47:07 <rbrunner> Hopefully, as I still have a quite mysterious problem with somebody how tried that. For me it works, for them receiving messages by the MMS fails, no idea yet why
17:47:32 <rbrunner> Would be interesting if you tried as well, jeffro256
17:47:34 <m-relay> <j​effro256:monero.social> I want to see if the BitMessage PoW is prohibitively expensive for UX purposes for large setup ceremonies
17:48:05 <rbrunner> Don't think so, but the messages to exchange explode into the hundreds
17:48:38 <rbrunner> And well, "large" starts at 6 or 7. If you are thinking about 20 or so, don't think that's feasible at all.
17:49:07 <rbrunner> But do play with it, to see firsthand, if it works for you
17:51:59 <m-relay> <r​ucknium:monero.social> Could we explore what it would take to bring Monero's multisig theory and implementation from experimental to "known secure"?
17:53:32 <m-relay> <r​ucknium:monero.social> Do we know what the failure modes could be with the current multisig implementation? Would a failure mode be that a single signer could pay themselves the funds? Or even someone who does not have any of the multisig keys?
17:55:01 <rbrunner> Well, no idea. I think some proofs would be needed, at least in principle.
17:55:11 <rbrunner> Security proofs? Does that sound right?
17:55:23 <rbrunner> And about failure modes, maybe UkoeHB would know more.
17:55:31 <m-relay> <r​ucknium:monero.social> Sounds correct to me.
17:57:36 <m-relay> <r​ucknium:monero.social> I could place multisig as an agenda item next week. Could invite kayabaNerve and koe if they want to come.
17:58:10 <rbrunner> Not a bad idea
17:59:32 <m-relay> <r​ucknium:monero.social> I will put multisig on the agenda. We can end the meeting here.
18:04:02 <plowsof> thanks Rucknium!
18:06:10 <m-relay> <j​effro256:monero.social> Thanks Ruck