00:39:10 <QuickBASIC> Zero to Monero 2.0 most recent edition?
00:47:27 <UkoeHB> yes
00:52:58 <QuickBASIC> ty UkoeHB
13:41:12 <Rucknium[m]> So I just found this:
13:41:12 <Rucknium[m]> https://www.cyphermarket.com/monero-research-lab/
13:41:52 <Rucknium[m]> I especially enjoy the MRL Molotov. Tossing truth bombs all over the place 😆
14:47:25 <sethsimmons> Updated pre-print with security proofs is available now for Lelantus Spark: https://eprint.iacr.org/2021/1173.pdf
14:47:25 <sethsimmons> Also available on Github, but IACR should be viewed as canonical.
15:24:27 <sgp_[m]> amazing news
15:55:41 <isthmus> @Halver[m] Got it from the monero database that @neptune maintains
16:01:02 <Halver[m]> <isthmus> "@Halver[m] Got it from the..." <- Thanks isthmus . 
16:01:02 <Halver[m]> I profit for a silly question : how is it possible for a tx to have more than 11 outputs ?
16:01:02 <Halver[m]> Are such txs done with unofficial wallets ?
16:01:46 <isthmus> The current protocol allows up to 16 outputs (correspondingly, I think the core wallet would let you send to 15 recipients + change)
16:02:15 <isthmus> So the peak at 16 makes sense, people maxing out the allowed number of recipients
16:03:00 <isthmus> The prevalence of 11 outputs is odd. It could be an unofficial wallet, OR it could be a script/wrapper/whatever around the core wallet that simply batches by 10+change and doesn't take advantage of the full 16 allowed by the protocol
16:03:28 <nioc> outputs |= ring members
16:05:52 <Halver[m]> nioc: Indeed, I was making this mistake.
16:05:52 <Halver[m]> If I'm correct the number of ring members is fixed, at 11 atm, 
16:05:52 <Halver[m]> and it is also mandatory to be accepted in the blockchain ?
16:06:24 <UkoeHB> correct
16:08:24 <Halver[m]> <isthmus> "The prevalence of 11 outputs..." <- I guess only a mining pool (old) script could generate such a volume ?
16:08:53 <midipoet> if every transaction returned change split into 15 seperate outputs would that have a net positive for privacy?
16:12:52 <isthmus> If the source of the 11 output txns switched to making 16 output txns it would be a very good thing to reduce how much their transactions stand out
16:13:08 <isthmus> (if we can figure out who/what is behind it, I would politely contact them with a note about updating their max outputs value)
16:13:53 <isthmus> The plot above is a log y-scale, so that peak at 11 is way bigger than it looks (essentially an order of magnitude over the surrounding output count values)
16:15:28 <isthmus> There will always be a bunch of transactions with 2 outputs from day-to-day users, and a bunch of transactions that max out the output count of the protocol (currently 16) for things like batched payouts. So if transactions can pick one or the other and blend into there would be best
16:15:44 <isthmus> I've pondered the notion of requiring #outputs to be a power of 2 
16:16:05 <isthmus> So if you have a 6 output transaction (including change) you would just add 2 dummy outputs so that you're at 2^3=8
16:16:19 <Halver[m]> Rucknium:   Isn't there a meeting programmed at 17:00 UTC today ?
16:18:16 <Halver[m]> isthmus: What would be the benefits ?
16:18:31 <UkoeHB> yes 40mins
16:19:38 <isthmus> It would prevent goofy stuff like some pool generating thousands upon thousands of N=11 outputs that can be traced to each other and ruled out as decoys from other rings :- P
16:19:52 <Halver[m]> UkoeHB: ah, so my UTC shown time must be wrong
16:22:29 <UkoeHB> unless I am crazy, it is 16:20 UTC right now
16:23:23 <Halver[m]> No. You're right, and I was wrong.
16:28:20 <carrington[m]> <midipoet> "if every transaction returned..." <- Net privacy win, but a block chain bloating problem
16:28:53 <carrington[m]> Or maybe not
16:30:08 <UkoeHB> bigger problem is scanning times to find owned outputs
16:35:33 <jberman[m]> I don't think it's necessarily a net win for privacy if every tx created 16 outputs. I think you'd likely end up having more tx's that have >1 ring with members from the same tx that way (unless all wallets actively prevent this), which makes it easier to identify those outputs as real
16:38:21 <sgp_[m]> jberman: if that's the norm though, wouldn't it make it basically a wash? Why should anyone send more than 1 output to themselves or another person in normal use?
16:38:31 <sgp_[m]> minko comes to mind, but that's the only legitimate example I've seen
16:38:55 <sgp_[m]> I see 16 out as a net privacy win, but at relatively significant cost
16:39:18 <sgp_[m]> there was an idea earlier for allowing either 2 out or 16 out only, but that's probably not flexible enough
16:44:09 <jberman[m]> If you have 2 rings in your tx, and both rings reference distinct outputs from the same tx, it's pretty clear that those are the outputs being spent, regardless of whatever else is happening
16:45:14 <isthmus> True, though that's a non-issue since dummy outputs would have 0 value and would not be consumed by subsequent transactions from the same wallet
16:45:32 <jberman[m]> If you're dividing up amounts into 16 outputs always, you also have smaller outputs with which to make tx's, so it seems you would also need to use more inputs to send the amount you'd want
16:45:42 <isthmus> No I'm definitely not proposing that
16:45:45 <isthmus> Would be a privacy disaster
16:47:06 <moneromooo> We could change fake out selection to slightly favour using outputs in different rings that come from the same tx. Never did it though.
16:48:23 <sgp_[m]> oh wow nooooooo, no one is proposing using anything other than dummy outputs here :p
16:48:36 <sgp_[m]> splitting into tiny amounts just for the lulz is baaad
16:49:28 <jberman[m]> <midipoet> "if every transaction returned..." <- was answering this q
16:50:24 <sgp_[m]> ah sorry I missed that
16:50:30 <sgp_[m]> midipoet: no :)
16:54:43 <jberman[m]> <moneromooo> "We could change fake out..." <- I think this would be effective though, at the cost of fewer decoys from across the chain (it's sorta like the naive binning approach I was planning to propose)
16:56:10 <sgp_[m]> what use case are we better protecting where the use case involves spending several outputs from the same transaction
16:56:50 <sgp_[m]> if anything, a wallet should probably warn if they receive several outputs in a single transaction as a higher risk of receiving poisoned outputs
16:58:44 <jberman[m]> ya agree I don't see what privacy gains you get from always constructing 16 output tx's. I think the main benefit is likely less time spent waiting to spend cuz of the unlock time (you have more outputs sitting around ready to go)
16:59:42 <carrington[m]> sgp_[m]: Some wallets are working on features which generate extra change outputs to avoid the 10 block lock
16:59:43 <UkoeHB> Rucknium[m]: do you want to run the meeting?
17:00:24 <Rucknium[m]> I could. Usually people with agenda items shouldn't run meetings, though.
17:00:49 <UkoeHB> ok I will do it
17:01:00 <sgp_[m]> Want me to run?
17:01:05 <UkoeHB> let the meeting commence. Logs will be posted on the issue: https://github.com/monero-project/meta/issues/610
17:01:18 <UkoeHB> 1. greetings
17:01:22 <UkoeHB> hello everyone
17:01:26 <Rucknium[m]> Isn't carrington  running one of the Monero Community meetings soon? carrington  , could you run this one too? I don't know if you are busy though carringtonn
17:01:30 <ArticMine> Hi
17:01:40 <neptune> Hello
17:01:41 <sgp_[m]> hello
17:01:41 <rbrunner> Hoi zäme
17:01:47 <coinstudent2048[> Hello
17:01:49 <Rucknium[m]> Hi.
17:01:50 <one-horse-wagon[> hello
17:01:52 <sgp_[m]> I'm cool with koe running for now
17:01:54 <crypto_grampy[m]> Hi all
17:01:56 <d3neon[m]> hi
17:02:01 <jberman[m]> Hello!
17:02:07 <sgp_[m]> sarang and brandon ran most of the previous ones and they always had agenda items
17:02:13 <carrington[m]> Hello. A researcher should run the MRL meetings, not me
17:02:14 <janowitz> Hi
17:02:33 <wfaressuissia> Hello
17:02:34 <UkoeHB> 2. updates. People working on stuff, a brief summary of what you have been up to.
17:02:42 <ErCiccione> hi
17:02:49 <woodser[m]> hello
17:03:40 <Halver[m]> hi
17:05:16 <Rucknium[m]> My main thing is working on a roadmap to improve the mixin selection algorithm. Within 12 hours I will submit the roadmap to the Vulnerability Response Process in part so that moneromooo and luigi1111w can redact any sensitive parts before release. jberman and isthmus  have seen a draft of it.
17:05:33 <Rucknium[m]> The I sill submit a CCS proposal to execute it
17:05:44 <Rucknium[m]> * will submit
17:06:08 <UkoeHB> Lots of people here :). My summary: The past couple weeks I have been working on PoC for Seraphis. Right now I have working performance mock-ups of RingCT with CLSAG and Triptych on my branch (https://github.com/UkoeHB/monero/tree/seraphis_perf), and have a good plan for building out the Seraphis PoC. There are a lot of variations to perf test, so it is taking me a while to design things properly.
17:06:26 <coinstudent2048[> So Lelantus Spark is out with security proofs. I am working on Seraphis's security proofs. Need verification of security properties I wrote here: https://github.com/UkoeHB/Seraphis/issues/2#issuecomment-918639450
17:07:30 <UkoeHB> Lelantus Spark: https://eprint.iacr.org/2021/1173
17:08:25 <coinstudent2048[> But since Lelantus Spark is "somewhat" of an instance of Seraphis, I guess I'll just "align" my security analysis...
17:08:43 <UkoeHB> I will give about 3-5mins more for summaries then we can move to discussion :)
17:08:46 <sgp_[m]> Here's a good casual discussion on Lelantus Spark https://www.youtube.com/watch?v=vEZC1fTYRZk
17:09:04 <UkoeHB> jberman[m]: would you like to update us?
17:09:24 <jberman> My summary: recommended patching integer truncation in the wallet & reducing the "recent spend window" (https://github.com/monero-project/monero/pull/7798#issuecomment-917495021), did a bit more research into the decoy selection algorithm adding the effect of MyMonero+Monero-LWS & openmonero to the mix in response to some of vtnerd's feedback and
17:09:25 <jberman> criticisms (https://github.com/monero-project/research-lab/issues/86#issuecomment-915806414), worked on other non-research related tasks, and hoping to talk about binning in today's meeting
17:11:18 <UkoeHB> Re: binning, my binning proposal was updated a while back (final draft kind of form) https://github.com/monero-project/research-lab/issues/84
17:12:17 <UkoeHB> Also research related:
17:12:17 <UkoeHB> - fee updates have been PRd and I have comments: https://github.com/monero-project/monero/pull/7819
17:12:17 <UkoeHB> - multisig address generation fixes have been PRd: https://github.com/monero-project/monero/pull/7877
17:12:34 <UkoeHB> Anyone else?
17:13:22 <sgp_[m]> ty for reviewing the fee changes
17:13:49 <UkoeHB> 3. discussion. Ok I think we can move on. The remainder of the meeting is open ended.
17:14:03 <sgp_[m]> are we accepting ArticMine's growth parameters then? am I the only one who is concerned with them?
17:14:29 <UkoeHB> I don't have a strong opinion
17:14:34 <moneromooo> Ping me when you comment on PRs, I seldom check the repo nowadays.
17:14:44 <Rucknium[m]> sgp_:  I suppose I could look at them.
17:14:44 <UkoeHB> ah gotcha
17:15:28 <gingeropolous> sgp_[m], can u briefly summarize ure concerns?
17:15:36 <Rucknium[m]> I am an economist after all. Maybe I have something to say about fees.
17:15:51 <ArticMine> I responded to the growth parameters in MRL issue 70 and the pr
17:16:06 <gingeropolous> ok
17:16:42 <sgp_[m]> gingeropolous: it's just a generous growth rate allowed
17:16:58 <sgp_[m]> we don't need to talk about this here among all the other important stuff, but I am worried it is too generous
17:17:08 <UkoeHB> sgp_[m]: It may be good to circle back to that issue after the fee PR is ready to merge.
17:17:49 <sgp_[m]> ok
17:17:55 <gingeropolous> i think Rucknium[m]'s input will be valuable, because it is effectively monetary policy
17:18:01 <ArticMine> Just a note if you change the grwoth parameters on has to change the whole fee calulation
17:18:28 <ArticMine> So I would suggest this not be left to the last minute
17:19:15 <gingeropolous> so whats all the other important stuff? :)
17:19:35 <Rucknium[m]> Triptych vs. alternatives... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ae5111e8ad7cef1dddd03a40c2a19fde0eed447c)
17:19:38 <UkoeHB> It sounds like there isn't anything new to add in this meeting, just a call to action: please take a look if you can (MRL issue 70 and PR 7819).
17:20:19 <gingeropolous> for those that can't do links
17:20:21 <gingeropolous> Triptych vs. alternatives
17:20:21 <gingeropolous> Improvements to the mixin selection algorithm (
17:20:21 <gingeropolous> Decoy Selection Algorithm - Areas to Improve research-lab#86 ) @j-berman @Rucknium
17:20:21 <gingeropolous> Removing/fixing/encrypting unlock time (
17:20:22 <gingeropolous> Removing/Fixing/Encrypting monero's timelocks research-lab#78) (it also affects binning)
17:20:23 <gingeropolous> Analysis of July-Aug 2021 tx volume anomaly (?) ( isthmus? { @Mitchellpkt } )
17:20:24 <gingeropolous> Active recruitment of technical talent @Rucknium & others
17:20:26 <gingeropolous> MRL structure (why aren't things getting done?).
17:20:38 <gingeropolous> (from Rucknium[m] 's matrix post)
17:21:24 <Rucknium[m]> Oh, long Matrix posts don't come through nicely on IRC?
17:21:49 <UkoeHB> These are the items from https://github.com/monero-project/meta/issues/610
17:21:59 <UkoeHB> - does anyone have comments/questions about Triptych vs alternatives?
17:22:44 <ArticMine> Do we have some concise figures on verification time / tx size for comparison?
17:22:47 <sgp_[m]> I have one question because we haven't really discussed this during a meeting specifically as far as I understand, but it has been discussed elsewhere:
17:22:57 <wfaressuissia> questions: Triptych isn't competitive even with ideal multisig or multisig is the only blocker ?
17:23:00 <UkoeHB> ArticMine: I am working on perf tests for that.
17:23:07 <one-horse-wagon[> Has anyone looked at RingCT 3.0 as an alternative to Triptych?
17:23:10 <sethsimmons> UkoeHB: My continued preference is explore Seraphis/Lelantus Spark and move to a hard-fork with ring-size change in the meantime.
17:23:14 <ArticMine> Thanks
17:23:21 <sethsimmons> Due to improved view keys and multi-sig simplicity, mainly.
17:23:24 <rbrunner> Well, I have the comment that I can't comment because I am not able to read Sarang's paper and decide how the UX and UI for multisig would change.
17:23:37 <sgp_[m]> Which of the following is more important: 1) easy transition with compatible address format, or 2) easy multisig
17:23:46 <rbrunner> I.e. how much more complicated to transact?
17:23:48 <sgp_[m]> I vote 2
17:23:49 <sethsimmons> wfaressuissia[m]: Multisig is the main blocker, but there are other advantages to Seraphis/Lelantus Spark.
17:25:00 <ArticMine> I have to agree with sethsimmons after speaking with sarang at DefCon after his talk. The Multisig simplicity is very significant in my view
17:25:17 <ErCiccione> I would prioritise whatever gives us a good and usable multisig.
17:25:27 <rbrunner> Quite some unknown how we would fare with an address format change I guess
17:25:34 <rbrunner> Sounds quite radical
17:25:36 <ct[m]> sgp_[m]: I assume the new sofware would prevent users from using old addresses?
17:25:44 <UkoeHB> wfaressuissia: Seraphis in general has several other benefits over Triptych.
17:25:44 <UkoeHB> 1. possibly more efficient (TBD)
17:25:44 <UkoeHB> 2. new features: membership proof delegation (allows tx chaining, offloading membership proofs to third parties, reduces timing analysis of slow tx like multisig), collaborative funding (multiple funders for a tx without big crypto design effort), better address schemes (several variations)
17:25:45 <ct[m]> s/sofware/software/
17:25:58 <Rucknium[m]> BCH more or less did an address format change. Could query them on how to do it right
17:26:24 <rbrunner> Interesting
17:26:28 <x3nu[m]> Could address size decrease?
17:26:51 <ErCiccione> The new format address not be backward compatible?
17:26:55 <gingeropolous> i imagine with a hardfork, it would be easy to protect users re: address change. 
17:27:00 <UkoeHB> x3nu[m]: there are two sets of address scheme variations, one set is larger
17:27:09 <sgp_[m]> proper view keys that show the whole balance (while also allowing view keys as we know them today) is a large win
17:27:13 <UkoeHB> ErCiccione: backward compatible?
17:27:19 <Rucknium[m]> UkoeHB: "collaborative funding (multiple funders for a tx without big crypto design effort)"  Does that mean that a BCH Flipstarter-like crowdfunding system would be easy to put together?
17:27:30 <sgp_[m]> exporting key images is frankly terrible
17:27:35 <UkoeHB> hypothetically - depends on various design decisions
17:27:45 <rbrunner> This new feature list looks so fantastic, somewhat hard to believe for laypeople
17:28:04 <gingeropolous> sgp_[m], smooth would have disagreed, or at least they expressed pause in the past. for reasons i don't fully remember or understand
17:28:25 <sgp_[m]> ErCiccione: people would get new Lelantus Spark/Seraphis addresses
17:28:44 <gingeropolous> re: proper view keys that show whole balance.
17:28:52 <rbrunner> I mean, if we really get all that for an address change, well then ...
17:28:53 <sethsimmons> The biggest issue with the address format change is static addresses used in the past would not be valid/usable.
17:29:06 <sethsimmons> i.e. static donations, saved addresses for friends in address book, etc.
17:29:11 <rbrunner> static = widely published?
17:29:20 <sgp_[m]> haha yeah exactly rbrunner , MANY benefits as I see it
17:29:24 <sethsimmons> As new wallet software after HF would only use the new format, new address generation wouldn't be an issue.
17:29:34 <UkoeHB> gingeropolous: there is an address scheme variant where view-only identifies owned and spent outputs, but can't read amounts. I like this one personally.
17:29:35 <ErCiccione> sgp_: my question was if the precedent format will be still accepted, otherwise would impact ux quite a lot
17:29:41 <sethsimmons> As it's coupled with a HF I don't think it's a huge deal, but it's certainly a bit more headache.
17:29:41 <wfaressuissia> if the base point of comparison is the best non-reviewed and unproven DAP designs, then Triptych isn't competitive even with multisig. If the base point of comparison is current ring signatures with 10 decoys then even Triptych with a bit more complex multisig is an improvement which was expected to deployed soon.
17:29:51 <sgp_[m]> Seth: critically funds sent to those addresses would not be unspendable however
17:29:55 <Rucknium[m]> Zcash is trying to merge t- and z-address formats, I believe. Just another example of another coin doing it.
17:30:00 <sethsimmons> It would not lead to lost funds with a HF, FWIW, just pain for users when merchants/donation acceptance does not update static addresses.
17:30:12 <UkoeHB> ErCiccione: the existing format would have to be rejected
17:30:13 <sgp_[m]> but I assume LS/S funds couldn't be sent to old addresses
17:30:24 <sethsimmons> sgp_[m]: No, wallet software should just reject the address as invalid and prompt that it's old format
17:30:45 <sethsimmons> UkoeHB: Woah, thats cool
17:30:52 <UkoeHB> wfaressuissia: 'soon' is only 'soon' if you find someone to implement that complex multisig
17:31:14 <sethsimmons> Rucknium[m]: This is different, they all still exist and are usable they just basically use a new URI format that can choose among multiple options.
17:31:20 <rbrunner> If I see something as good-looking as this I unvolentarily start to look for the catch :)
17:31:21 <sethsimmons> They aren't phasing out any address format or changing it.
17:31:22 <gingeropolous> i don't think the change in address format is a cause for concern
17:31:29 <sethsimmons> It's just a wallet SDK change.
17:31:42 <d3neon[m]> Would it be possible to convert an old address to a seraphis address?
17:32:07 <sgp_[m]> Triptych is a year + out even if we were fully on board with running with it, which I think is inadvisable at this point
17:32:13 <UkoeHB> d3neon[m]: your private keys would stay the same (or at least your base entropy/mnemonic, depending on design choices)
17:32:20 <ArticMine> One can allow a transition phase afte which sending funds to legacy addresses would not be allowed 6 months would be reasonable
17:32:22 <wfaressuissia> UkoeHB: 2 people were agree to help with implementation: hyc and vtnerd, but that's for the case when design is ready
17:32:25 <sethsimmons> d3neon[m]: New wallet software would just provide new addresses, no conversion needed etc.
17:32:41 <wfaressuissia> Regarding fees. These fees are being used as protection against unlimited blockchain growth (problem with cheap storage and network), unlimited number of malicious txs (problem due to small number of decoys for ring signature) and reward for miners (not very important, since ther is fixed tail emission).  How is it possible to justify decrease or increase of fees without any knowledege of hardware available to miners ?
17:32:45 <d3neon[m]> If you could convert it, that would solve the static address issue
17:33:18 <sethsimmons> d3neon[m]: You just post a new one, don't need to convert.
17:33:27 <sethsimmons> The sender couldn't convert it, FWIW.
17:33:34 <d3neon[m]> alright
17:33:51 <rbrunner> Yeah, a fully automatic conversion tool, based only on the info in the address, would be surprising
17:33:51 <sethsimmons> ArticMine: Yes, that is an option to implement both address formats, but obviously added complexity and code.
17:34:02 <UkoeHB> rbrunner: "I unvolentarily start to look for the catch" The protocol is still experimental and not implemented anywhere - of course there might be a catch no one has seen yet. The more eyes the better.
17:34:04 <gingeropolous> <sgp_[m]> Triptych is a year + out >>> how far out will seraphis / lelantus / superdooper be?
17:34:25 <sgp_[m]> Also Year +
17:34:33 <gingeropolous> or is it 3 +
17:34:45 <x3nu[m]> So a ring decoy increase should be reconsidered then?
17:35:01 <x3nu[m]> As a holdover
17:35:12 <gingeropolous> imo its theater
17:35:12 <UkoeHB> ArticMine: I also think a big transition period would be good.
17:35:26 <sgp_[m]> Firo is planning on Q3 2022 for adoption of Lelantus Spark
17:35:29 <sgp_[m]> just to give a rough idea
17:35:42 <sethsimmons> x3nu[m]: Yes, IMO.
17:35:53 <sgp_[m]> sorry, Q2 2022
17:35:59 <sethsimmons> I think there is pretty broad consensus for a ring-size + BP+ HF with ring-size of 15-17.
17:36:23 <sgp_[m]> Seth: yup
17:36:41 <sethsimmons> But the larger improvements to privacy are likely coming via the decoy selection/binning work being done, TBH.
17:36:53 <merope> wfaressuissia[m]  Fees increase/decrease based on number of transactions being sent. They have nothing to do with mining hardware
17:36:59 <sethsimmons> But ring size bump does help with those in theory, but that's more jbermanRucknium territory
17:37:21 <coinstudent2048[> Hi! I made an attempt to elucidate Seraphis here. Highly incomplete hahaha. UkoeHB please correct mistakes: https://raw.githubusercontent.com/coinstudent2048/writeups/main/seraphis.pdf
17:37:43 <UkoeHB> wfaressuissia: "How is it possible to justify decrease or increase of fees without any knowledege of hardware available to miners ?" The fee PR has two parts. 1) improve the algorithm design to avoid problematic edge cases. 2) increase the minimum fee. Parameter choice is very difficult and somewhat arbitrary, so yes 'how is it possible' is kind of engineering voodoo (which is seen in other engineering fields too).
17:37:58 <gingeropolous> ok, so lelantus spark will be ready Q3 2022 ?
17:38:06 <UkoeHB> coinstudent2048[: cool! I will take a look :)
17:38:08 <rbrunner> We could turn things on the head and ask whether currently anything still speaks *pro* Triptych
17:38:21 <rbrunner> Except an existing but non-multisig implementation
17:38:50 <sethsimmons> gingeropolous: That's their plan, yes, but that's for Firo -- would require implementation for Monero specifically on top of that, but not sure on complexity.
17:39:20 <sgp_[m]> nice coinstudent2048 !
17:40:25 <sethsimmons> There is also a PoC implementation of Lelantus Spark: https://github.com/cypherstack/spark
17:40:26 <ErCiccione> sethsimmons: I'm not sure it worth to make a hard fork now if there are more consensus changes being worked on (assuming they are consensus-related)
17:40:41 <gingeropolous> so i guess, as mentioned before, a key piece of data is compare and contrast lelantus spark / seraphis / triptych re: size and speed etc
17:40:42 <UkoeHB> rbrunner: If Seraphis/etc. turn out to be flops, Triptych is the best known protocol.
17:41:01 <sethsimmons> ErCiccione: Ah, forgot to include fee changes, which should also be included.
17:41:12 <sethsimmons> Past that there are no other consensus changes near-ready that I know of.
17:41:15 <rbrunner> I see, yes
17:41:27 <ErCiccione> I think we should prepare a list of what consensus changes would be included in the next hard fork and then have a dedicated meeting about it
17:41:29 <sethsimmons> And as mentioned a new protocol is still 1y+ out.
17:41:32 <UkoeHB> That being said, Seraphis/etc. don't introduce any crazy new crypto, so it is unlikely.
17:41:54 <coinstudent2048[> UkoeHB: I second this.
17:42:00 <jberman> Agreee with ErCiccione on dedicated meeting about HF
17:42:02 <sethsimmons> ErCiccione: Agreed.
17:42:03 <ErCiccione> UkoeHB: but we need it to support multisig in case
17:42:20 <ErCiccione> meeting again in two weeks then?
17:42:31 <UkoeHB> yes seems appropriate
17:42:38 <ErCiccione> there is enough stuff to talk about in any case i would say, beside the hard fork
17:42:42 <rbrunner> Does Lelantus Spark support multisig then in a reasonable form? Does Firo aim to support multisig?
17:43:01 <sgp_[m]> HF process falls outside of MRL scope mostly and is more of a -dev thing, but yes very important
17:43:22 <sethsimmons> rbrunner: Yes, very simple AFAICT.
17:43:23 <UkoeHB> rbrunner: afaik yes, the Chaum-Pedersen proofs they use can be multisig-d
17:43:30 <sgp_[m]> rbrunner: yes, Lelantus Spark multisig is a dream compared to Triptych
17:43:44 <ErCiccione> meeting in monero-dev sunday 3th 17:00 UTC?
17:43:49 <rbrunner> Nice, one more arrow in the back of Triptych ... ?
17:43:50 <sethsimmons> Pre-print: https://eprint.iacr.org/2021/1173.pdf
17:43:50 <sethsimmons> Github: https://github.com/firoorg/spark-paper
17:43:50 <sethsimmons> PoC: https://github.com/cypherstack/spark
17:44:25 <sgp_[m]> ErCiccione: I'm not aware of any meeting but there should definitely be one imo
17:44:27 <jberman> sounds good to me ErCiccione
17:44:31 <UkoeHB> we should move to another topic, this one took a surprising amount of time
17:44:31 <UkoeHB> - Improvements to the mixin selection algorithm 
17:44:47 <sgp_[m]> rbrunner: that's the main reason not to use Triptych
17:44:50 <jberman> 4 areas to improve decoy selection algo:
17:44:51 <jberman> 1. Integer truncation in the wallet (e.g.: `3 / 2 = 1`)
17:44:51 <jberman> 2. Binning
17:44:52 <jberman> 3. Modifying the distribution estimator (@Rucknium spearheading this)
17:44:52 <ErCiccione> sgp_: yeah, will post in -dev about it if there is consensus here
17:44:52 <jberman> 4. Validating correct algo used at consenus
17:45:11 <sgp_[m]> ErCiccione: yes please do
17:45:45 <jberman> 1. Patching integer truncation
17:45:46 <jberman> Refresher: the decoy selection algo selects *older* outputs than it otherwise would because it truncates an integer (e.g. 3 / 2 = 1, instead of 1.5)
17:45:46 <jberman> I recommended patching integer truncation in the official wallet: https://github.com/monero-project/monero/pull/7798#issuecomment-917495021 (and downsizing the "recent spend window" where the wallet re-selects a young output if the algo suggests a locked output).
17:45:47 <jberman> Summary: patching truncation seems safe on grounds of tx uniformity to me, and I think it's reasonable to assume it would correctly select a decoys that more closely mirror spending patterns.
17:45:58 <jberman> don't think there is much to talk about on that^
17:46:01 <coinstudent2048[> rbrunner: I try to post about Sarang's Triptych multisig paper in MRL/Lounge, but not now.
17:46:15 <rbrunner> TIA!
17:47:17 <UkoeHB> jberman: +1
17:47:43 <jberman> Will give 30 more seconds then moving on to binning
17:47:47 <sgp_[m]> yeah safe to patch
17:48:01 <rbrunner> Lol, bug killed in 30 seconds :)
17:48:23 <jberman> :] 
17:48:34 <jberman> I think binning is blocked by the decision on what to do with unlock times
17:48:35 <jberman> Unlock times have privacy issues (they break tx uniformity & can enable unknowing links), and make binning implementations more vulnerable to particular attacks. So bringing the topic of unlock times back up to try and move toward a decision on what to do with them.
17:48:58 <jberman> Encrypting unlock times is possible at cost of doubling verification time and increasing tx size. Which seems overkill for a feature barely anyone uses today
17:49:10 <jberman> Thoughts on how to reach consensus? Seems no one really loves the feature, so no one cares much about it to go one way or another. Is there precedence for deprecating a feature like this?
17:49:20 <gingeropolous> imo, they seem a novelty 
17:49:40 <sgp_[m]> tbh I'm happy to simply write off binning right now
17:49:41 <selsta> yea, I don't think they are much used
17:49:53 <ErCiccione> maybe a dedicated issue could help? So we can see points in favor and points agains? unless there is already one
17:50:10 <selsta> I don't know any important use cases for them
17:50:28 <merope> wait, I thought atomic swaps relied on lock times?
17:50:31 <gingeropolous> precedence? perhaps axing of the clear format tx id or whatever it was.
17:50:32 <sgp_[m]> ErCiccione: binning has been suggested countless times over many years
17:50:39 <UkoeHB> merope: no on the Monero side
17:50:51 <jberman> ErCiccione dedicated issue for handling the unlock time: https://github.com/monero-project/research-lab/issues/78#issue-726924520
17:50:52 <sgp_[m]> in practice, ringsizes are too small, and it involves many complexities
17:50:57 <merope> (or at least, one of the proposed implementations? comit maybe?)
17:50:57 <Halver[m]> shouldn't a feature like unlock time be treated elsewhere as in the official wallets ?
17:51:00 <rbrunner> Would existing locks honored if we decide to ax them e.g. in our next-gen protocol?
17:51:05 <ErCiccione> jberman: nice. Thanks
17:51:12 <gingeropolous> paymentID. that was deprecated because it didn't do many useful things, but it was replaced with something better.
17:51:21 <gingeropolous> well it did useful things, but poorly
17:51:48 <gingeropolous> perhaps thats something to throw into the lelantus / seraphis thing - can these new protocols do some kind of timelock thinger?
17:51:56 <gingeropolous> in a better way
17:52:19 <isthmus> @rbrunner interesting question, I would lean towards yes
17:52:28 <isthmus> (should honor previous timelocks)
17:52:35 <UkoeHB> rbrunner: yes, since old outputs would be spent using CLSAG
17:52:40 <UkoeHB> so there is no issue
17:52:49 <rbrunner> Ok then, good to know
17:53:13 <sgp_[m]> yup  no issue with past compatibility there :)
17:53:28 <UkoeHB> gingeropolous: not that I know of
17:53:55 <jberman> Will confirm no swap protocol has plans to use the feature
17:54:10 <carrington[m]> A consideration for the next gen transaction protocol should also be whether payment channels are possible
17:54:11 <jberman> Are there any proponents of keeping the lock time assuming not?
17:55:12 <UkoeHB> carrington[m]: I think someone would need to study that specifically.
17:55:17 <sgp_[m]> Well, I'm for keeping the lock time as-is for this hardfork, and I'm cautiously for removing it for the next hardfork (but there's a lot of TBD there)
17:55:31 <gingeropolous> i would vote to deprecate them due to their privacy breaking nature and lack of utility
17:55:59 <rbrunner> I would vote for retiring them with the HF to the next-gen protocol, for a clean cut
17:56:09 <sgp_[m]> gingeropolous: are you suggesting that for this immediate update? way too soon imo
17:56:09 <gingeropolous> i mean they are really only used for 1 purpose currently - im not gonna spend my monero until 2099 ... right?
17:56:19 <isthmus> hahah
17:56:32 <gingeropolous> well no we're not talking what goes into the next hf. thats for the dev discussion :)
17:57:25 <jberman> I figure as soon as someone presents a fleshed out compelling use case that actually needs to use lock times, like payment channels, then there would be no resistance to bringing them back
17:57:32 <UkoeHB> It seems 1hr was not long enough for this meeting, there are still 3 items on the agenda. How about we schedule another meeting for 1wk from now at the same time (1700 UTC), so all agenda items get proper attention?
17:57:41 <sgp_[m]> okay, just good to attack rough timelines to these discussions I think
17:57:41 <Rucknium[m]> Ok I will talk about (3). (Let me know if this doesn't go through to IRC correctly.) I will repost my "update" from above:
17:58:15 <Rucknium[m]> My main thing is working on a roadmap to improve the mixin selection algorithm. Within 12 hours I will submit the roadmap to the Vulnerability Response Process in part so that moneromooo and luigi1111w can redact any sensitive parts before release. jberman and isthmus have seen a draft of it.
17:58:15 <Rucknium[m]> Then I will submit a CCS proposal to execute it
17:58:23 <wfaressuissia> why not to finish right now ? there are a lot of important things and 1 hr / 2 weeks is too small quota to discuss something
17:58:32 <wfaressuissia> s/finish/continue/
17:58:34 <UkoeHB> I am gone in 2mins
17:58:40 <UkoeHB> but the meeting can continue without me if you want
17:59:10 <rbrunner> Seems good to me to adjourn. We are not in such a hurry to do everything today, seems to me
17:59:11 <Rucknium[m]> It's a two-stage execution plan. First, what I have termed Optimal Static Parametric Estimation of Arbitrary Distributions (OSPEAD). It's a medium-term solution to stop the bleeding.
17:59:12 <ArticMine> We can have a meeting in 1 week
17:59:22 <isthmus> I also have to head out
17:59:27 <isthmus> +1 ArticMine
17:59:35 <isthmus> Would be good to reconvene next week
17:59:38 <gingeropolous> weekly ftw
17:59:48 <rbrunner> Older people are also a bit exhousted after one such hour :)
17:59:59 <jberman> In for meeting next week
18:00:01 <Rucknium[m]> I would be OK with weekly. 
18:00:19 <rbrunner> The Return Of The MRL Meetings.
18:00:28 <ArticMine> I am fine with weekly
18:00:43 <carrington[m]> Can someone change the channel description to have the next weeks meeting agenda? Once one is created
18:00:50 <rbrunner> Yeah, at least until the backlog is cleared.
18:01:19 <isthmus> For next week I'll have a postmortem of the transaction volume anomaly from a few weeks ago
18:01:36 <rbrunner> Ah, a cliffhanger
18:01:46 <rbrunner> Clever
18:01:49 <isthmus> ;- )
18:01:50 <isthmus> Tune in next week
18:01:54 <isthmus> Same bat time, same bat channel
18:02:34 <UkoeHB> Can someone grab logs?
18:02:51 <carrington[m]> rucknium[m]: Do you have a write up that can be linked here for people to find in the meeting logs?
18:03:10 <wfaressuissia> "https://libera.monerologs.net/monero-research-lab/20210915/raw" grab or grab&post ?
18:03:39 <Rucknium[m]> carrington: Yes I have a write-up. No, I cannot share it until it has been sanitized by the Vulnerability Response Process.
18:04:39 <sethsimmons> carrington[m]: I can change topic, just ping me once created
18:07:23 <carrington[m]> Logs posted
18:08:54 <Rucknium[m]> carrington: It looks like something is wrong with the logs. Not everyone's username shows up
18:09:07 <carrington[m]> Gah, IRC usernames seem missing
18:09:36 <carrington[m]> It's because of the <> formatting
18:10:02 <rbrunner> Yeah, saw it, maybe the Libera log would be better
18:10:18 <rbrunner> Or did GitHub eat the usernames?
18:10:33 <carrington[m]> Github did it lol
18:10:52 <rbrunner> Quote somehow the whole log? ```` or so?
18:11:00 <hyc> time to :%s/</&lt;/g
18:11:11 <rbrunner> Not sure about MarkDown
18:11:27 <carrington[m]> I'll have to manually reformat unless someone has another source without the formatting issue
18:11:53 <rbrunner> The Libera log that wfaressuissia posted above, have a look
18:11:55 <hyc> ^ just search and replace all the < with &lt;
18:12:09 <rbrunner> https://libera.monerologs.net/monero-research-lab/20210915/raw"
18:12:31 <rbrunner> Arg ... without the double quote at the end of course
18:15:55 <gingeropolous> did u get a good log? i pulled up my logfile
18:15:58 <hyc> http://highlandsun.com/hyc/raw
18:15:58 <carrington[m]> Fixed
18:16:11 <rbrunner> Thanks, looks better now :)
19:31:03 <Rucknium[m]> Did we know about this paper? 
19:31:03 <Rucknium[m]> https://petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf
19:31:28 <Rucknium[m]> Someone posted in r/Monero about it
19:31:28 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/polatq/partitioning_samplers_a_better_approach_for_ring/
19:31:38 <Rucknium[m]> "This can be seen as a theoretical con-
19:31:38 <Rucknium[m]> firmation of the approach used in Monero, albeit condi-
19:31:38 <Rucknium[m]> tioned on the strong assumption that Monero chose a
19:31:38 <Rucknium[m]> good ˆS."
19:32:22 <Rucknium[m]> ^ "S" is the distribution for the mixin selection algorithm. Hmm, yes it is a "strong" assumption that a good S was chosen.
19:43:02 <carrington[m]> Seth  agenda posted
19:43:02 <carrington[m]> https://github.com/monero-project/meta/issues/611
19:45:18 <sethsimmons> How's that?
19:45:43 <Rucknium[m]> "We emphasize that although Theorem 6.2 shows... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a7cd47bd9997008a41985651c089065f9fe1b7a7)
19:57:42 <Rucknium[m]> Can someone help me decode this notation? coinstudent2048   ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9f3ebf1ad983a2ab0a4cac3566a86bdbc200208a)
19:57:55 <Rucknium[m]> Top of page 4 of the PDF
19:59:29 <Rucknium[m]> Oh, wait, "Logarithms are either with base 2,
19:59:29 <Rucknium[m]> denoted by lg..."
19:59:29 <Rucknium[m]> Who denotes log()  as lg()? Whaaaat?
20:21:31 <midipoet> sgp_[m]: what's the privacy loss by forcing 16 outputs for every transaction? 
20:21:39 <sgp_[m]> my first impression is that this is yet another paper recommending binning
20:23:29 <sgp_[m]> midipoet: it would be a similar effect described in this fuk piece ironically, lol: https://medium.com/@crypto_ryo/on-chain-tracking-of-monero-and-other-cryptonotes-e0afc6752527
20:23:34 <midipoet> UkoeHB: is the scanning/validation increase linear (or worse) if a wallet forced 16 outputs for every transaction? (Or some other number)
20:24:31 <sgp_[m]> having extraneous outputs is significantly worse
20:27:26 <midipoet> Because there is more chance that you have to combine outputs in the subsequent transaction that have come from the same previous transaction?
20:28:35 <sgp_[m]> basically yes, combining outputs where unnecessary is bad in general
20:29:11 <sgp_[m]> it also comes with the cost of additional rings
20:30:14 <midipoet> yeah, I think I get it. Though, I wonder could you compensate with output selection algorithm - which is why I asked about it being a net privacy gain. Having said that, I was just thinking out aloud. 
20:30:46 <sgp_[m]> the big privacy gain is the indistinguishability of every transaction having 16 outputs
20:31:08 <midipoet> yes. I definitely get that bit.
20:31:12 <sgp_[m]> but it's far better to use blank outputs rather than splitting the value for the same recipient among several outputs
20:34:14 <midipoet> But the big loss is that subsequent transactions will need to combine outputs, and those combinations can be identified within rings
20:34:47 <midipoet> Which is why the 0 value outputs would be better, as you could (in theory) bin them, so they don't get used in rings
20:37:53 <coinstudent2048[> Rucknium: what PDF? Btw, I sometimes see lg() when base is 2... oh it's indicated hahaha
20:38:47 <Rucknium[m]> coinstudent2048:  https://petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf
20:43:36 <moneromooo> UkoeHB: I have a few comments, the rest of the changes is running tests now.
20:45:09 <coinstudent2048[> Rucknium: That lg() is very confusing. I saw some websites use lg() to mean base 10.
20:47:37 <Rucknium[m]> coinstudent2048: I have about had it up to here with computer scientists! 😜
20:48:07 <sech1> lg() meaning log2 is pretty standard in computer science
20:51:27 <gingeropolous> computer science meats statistics
20:51:52 <gingeropolous> hrm, the all have 16 output idea might be neat
20:52:03 <Rucknium[m]> gingeropolous:  meats? #monero-beef:monero.social 
20:52:10 <gingeropolous> if the other 15 are 0, they won't get clumped together
20:52:15 <gingeropolous> lulz
20:52:30 * moneromooo looks at the channel with suspicion
20:52:33 <gingeropolous> so you get a funnel in and then a fan out
20:53:02 <sech1> did you forget that 16 output transactions are much heavier?
20:53:05 <Rucknium[m]> coinstudent2048: My question is this: which is better: Optimal "mimicking" or "partitioning". I can't figure it out from a quick look.
20:53:06 <gingeropolous> and we can finally use the term fake output and mean the product of a transaction that is fake
20:53:09 <gingeropolous> bah, who cares
20:53:43 <gingeropolous> magnetic fields on tiny bits of metal were meant for storing data, so lets store some data
20:55:29 <gingeropolous> i feel like this idea of having fake outputs has been kicked around a while
20:55:41 <gingeropolous> perhaps the reason its often left alone is the weight
20:56:27 <gingeropolous> BUT if variable number of outputs is breaking privacy / fungibility, then.... 
20:58:14 <sech1> forcing all transactions to 16 outputs will slow down wallet scanning, what... 5-8 times?
20:58:20 <sech1> Really not well-thought idea
20:58:48 <gingeropolous> i wonder if there's a way to make the important part of a transaction output somehow stored across multiple piece of data ... no...
20:58:58 <gingeropolous> thats just optimization sech1 
20:59:36 * moneromooo wonders why gingeropolous' R stuff takes hours or days to run then
21:00:31 <Rucknium[m]> moneromooo: Lol. It is easy to write really slow R code. Check out "The R Inferno"
21:01:28 <Rucknium[m]> On the other hand, if you keep in mind some key issues, then it is easy to write fairly fast code.
21:02:42 <Rucknium[m]> And if you really need speed, there is Rcpp , a package to do in-line (or imported) C++ calculations to feed into R.
21:03:04 <gingeropolous> well, perhaps there's a magic number of forced outputs that is a middle ground between privacy gains of uniformity and the cost of heavy txs
21:04:16 <coinstudent2048[> Rucknium: I don't know... I assume that "mimicking" is like the current monero setup, while "partitioning" is classifying tx's into classes.
21:06:33 <Rucknium[m]> Mimicking is what Monero currently tries to do, but it does it poorly. My project is to improve the mimicry.
21:35:22 <coinstudent2048[> Hmm... I downloaded the paper. I'll say "I'll read", but most likely this will take too long for me to understand, but at least the notation *seems* understandable.
21:36:55 <Rucknium[m]> coinstudent2048:  Yeah it's fairly complicated, although at the end of the day it may be saying a whole lot of nothing. Tough to say at this point.
22:13:57 <UkoeHB> midipoet: worse than linear, because right now 2-out tx can abuse change outputs for 50% speed up on scanning (even if only subaddresses are supported)
22:15:40 <UkoeHB> * not speed up over current scanning, but relative to 16outputs with subaddresses
22:15:57 <UkoeHB> * assuming view tags are implemented
22:48:05 <jberman[m]> forcing 16-output tx's would probably end up shifting a higher degree of tx deformity to the input side of tx's too
22:51:22 <jberman[m]> instead of mostly 1- and 2-input tx's that we see today, you'd see a wider range, potentially clusters that reveal information
23:25:21 <atomfried[m]> can i read some kind of summary of the meeting?
23:46:54 <Rucknium[m]> atomfried:  Not a summary. This is the whole log:
23:46:55 <Rucknium[m]> https://github.com/monero-project/meta/issues/610#issuecomment-920263858