13:24:42 <sgp_> I am running the MRL meeting today at 17 UTC
16:04:24 <Inge-> what time is it now?
16:04:37 <fluffypony> 3am
16:04:40 <fluffypony> somewhere in the world
16:04:54 <fluffypony> (it's 4:04pm UTC)
16:05:21 <sarang> .time
16:05:21 <monerobux> 2020-07-29 - 16:05:21
16:46:45 <sgp_> 15 minutes
16:46:52 <sgp_> .time
16:46:53 <monerobux> 2020-07-29 - 16:46:53
17:01:44 <sgp_> MRL meeting time
17:01:59 <sgp_> https://github.com/monero-project/meta/issues/491
17:02:07 <sgp_> 1. Greetings
17:02:35 <hyc> hey
17:02:53 * selsta lurking
17:03:10 <ArticMine> Hi
17:03:33 <sethsimmons> hi all
17:04:11 <sgp_> hello everyone
17:04:14 <sgp_> 2. Roundtable
17:04:36 * Isthmus waves
17:04:45 <sgp_> Sarang is not present for this meeting today, but he has been working on coordinating the CLSAG audit for final release
17:04:58 <sgp_> Does anyone else have an update to share?
17:07:23 <hyc> anyone following quantum computing,
17:07:25 <hyc> https://www.nist.gov/news-events/news/2020/07/nists-post-quantum-cryptography-program-enters-selection-round
17:07:48 <hyc> "Following this roughly 18-month period, NIST will plan to release the initial standard for quantum-resistant cryptography in 2022."
17:08:08 <Isthmus> Ooh interesting. We’re now digging through a vast pq-crypto landscape to find Monero compatible solutions leveraging Lattice Based Cryptography, Multivariate cryptography, Hash-Based Cryptography, Supersingular elliptic curve isogeny cryptography, or Quantum Key Cryptography. Will examine the NIST work as well.
17:08:21 <Isthmus> Lattice-based SALRS and the MatRiCT are of particular interest so far, but we’re still executing a broad search.
17:09:00 <Isthmus> There's a ton of pq-hard problems, though the vast majority are too unwieldy for implementation at the moment.
17:10:09 <hyc> 5 of the 7 candidates are lattice-based
17:11:22 <hyc> decent overview https://medium.com/asecuritysite-when-bob-met-alice/crypto-bake-off-the-final-and-its-a-lattice-bake-in-the-lead-dafc23ecde20
17:11:50 * Isthmus bookmarks to read during next tea break
17:12:24 <Isthmus> Thanks for sharing these great resources hyc
17:13:57 <sgp_> I just skimmed that overview, nice stuff
17:15:01 <sgp_> any other roundtable updates?
17:16:10 <sgp_> we can then move on to 3. Questions
17:17:16 <sgp_> I got a question from Reddit: when is Monero going to change its ringsize? It will be going on two quick years with ringsize 11
17:17:39 <sgp_> I'm not aware of a significant reason to increase before something like Triptych
17:18:19 <hyc> yeah, haven't seen any reason to rush
17:19:59 <selsta> faster chain verification > marginal privacy improvement IMO
17:20:39 <hyc> agree
17:20:47 <sgp_> selsta hyc: separating coinbase and dropping the ringsize to 1 or 3 for those tx will speed up a bit :p
17:20:58 <fluffypony> only from that point on, though
17:20:58 <selsta> can’t comment on that
17:21:00 <fluffypony> not historically
17:21:17 <hyc> and, it's like key sizes - sure, bigger keys are stronger, but there's no reason to use a bigger key than necessary
17:22:21 <sgp_> what is the general sentiment about whether to implement bulletproofs+?
17:22:32 <ArticMine> My question with coinbase is why not just mix coinbase with coinbase. Then there is no hard fork required
17:22:50 <sgp_> ArticMine: requires hard fork to enforce
17:23:09 <ArticMine> and non coinbase with non coinbase
17:23:25 <fluffypony> sgp_: it would be a soft fork
17:23:31 <fluffypony> you're tightening the existing rules
17:23:52 <hyc> my impression of BP+ is it's probably a good idea, but I'd like to see some formal peer review finished first
17:23:54 <sgp_> wallets can do that now, but it would be relatively simple to identify which wallets are using that and which aren't
17:24:07 <sgp_> sure, soft fork could be possible but I guess why bother
17:24:44 <sgp_> also we need the hardfork if we want to shrink coinbase ringsize
17:25:06 <moneromooo> I'm for BP+. If sarang gets a python implementation, I could do the C++, if he doesn't do it directly.
17:25:20 <ArticMine> Why shrink coinbase ringsize?
17:25:23 <hyc> if you mix coinbase only with coinbase is there any reason to shrink the ringsize?
17:25:25 <moneromooo> I'm assuming it's not a huge change from our current code. If it is, I might change my mind.
17:25:51 <sgp_> hyc: coinbase outputs are quite toxic with all the public pool data
17:26:04 <hyc> from my convs with sarang, sounds like BP+ should not be a big change
17:26:57 <hyc> sgp_: which sounds like all the more reason to leave them the same ringsize as others.
17:27:00 <ArticMine> <sgp_> hyc: coinbase outputs are quite toxic with all the public pool data <--- So why shrink the ring size then ?
17:27:35 <sgp_> did you both read my github issue about it?
17:28:02 <ArticMine> link
17:28:36 <sgp_> last time I looked, 90% of coinbase outputs were attributable to specific pools. ringsize 11 can't handle a 90% scenario
17:29:26 <ArticMine> I know but what I am saying is mix only with other ringsize outputs
17:29:33 <sgp_> https://github.com/monero-project/monero/issues/6688
17:29:37 <hyc> coinbase*
17:29:54 <sgp_> ArticMine: I agree and support the idea of separating the two
17:30:07 <sgp_> We however have the option to configure the ringsizes separately if we want
17:30:22 <sgp_> luigi1111 voices support for doing this
17:30:25 <sgp_> *voiced
17:30:36 <ArticMine> I  will comment on the issue
17:30:48 <sgp_> ty
17:30:52 <hyc> so if coinbase only mixes with coinbase, and ringsize 11 is inadequate, why drop down to size 3 or 1?
17:31:44 <sgp_> Options are:
17:31:44 <sgp_> 1. Drop the coinbase ringsize to 1 or 3 for efficiency. Mostly write off coinbase outputs as a lost cause.
17:31:44 <sgp_> 2. Keep it the same
17:31:44 <sgp_> 3. Increase it knowing that coinbase outputs are a deducible bloodbath if we really feel that we need to protect coinbase outputs. It will cost us.
17:31:50 <luigi1111w> because it's a waste of blockchain space
17:31:51 <sgp_> hyc: from the issue linked above
17:31:59 <ArticMine> I see a fair amount of consensus on segregating the coinbase outputs
17:32:29 <ArticMine> How we then treat them can be the subject for further discussion
17:33:27 <ArticMine> I will move with mixing coinbase with coinbase and non coinbase  with non coinbase ASAP
17:33:40 <hyc> not sure what the significance is. so 90% of coinbase outs can be attributed to specific pools. Then pools must split them to payout to miners
17:33:50 <sgp_> to get an idea of cost, in a 90% compromised scenario, and to protect 99% of rings with at least 1 non-compromised output, we need ringsize 45
17:34:46 <ArticMine> sgp_ 's point is very valid
17:35:15 <sgp_> you can see why I don't want normal transactions to use these toxic decoys as non-convincing inputs
17:35:27 <ArticMine> Yes
17:35:51 <luigi1111w> that's more a question of how many outputs are miner vs normal usage
17:36:43 <sgp_> what is that, about 72 transactions/day spending coinbase outputs?
17:36:49 <sgp_> *720
17:36:56 <ArticMine> My proposal addresses the main issue of contamination normal outputs
17:37:05 <luigi1111w> but it seems clear to me that if you are splitting miner txs into their own pool, then they should just not mix at all
17:37:32 <ArticMine> That depends on the ring size
17:38:07 <sgp_> greater efficiency for ~720 rings a day (on average) seems non-trivial
17:38:35 <sgp_> not huge either
17:38:36 <luigi1111w> shouldn't be that hard to quantify if you have some daily tx stats
17:39:05 <hyc> gets to be insignificant as adoption increases
17:39:30 <sgp_> hyc: yeah, it's pretty constant regardless of adoption
17:40:30 <ArticMine> If we can reach consensus on the treatment of the separated coinbase transactions before the next HF great
17:40:53 <sgp_> I hope so (not the Oct one obviously)
17:41:40 <ArticMine> Otherwise I say go with ring 11 for the coinbase outputs
17:42:04 <ArticMine> WHat I do not support is keeping the contamination of regular outputs while we decide
17:42:24 <sgp_> ArticMine: wallet change?
17:42:43 <ArticMine> That is by far the simplest
17:43:00 <sgp_> hmm, that scares me a bit. wallets do weird stuff
17:43:03 <ArticMine> but the specification has to be widely known
17:43:25 <ArticMine> It is the same issue with fees
17:43:57 <luigi1111w> I mostly disagree and think status quo is status quo until there is a coherent plan for change
17:44:16 <ArticMine> Making the specification widely know can address the bulk of the issue
17:44:26 <luigi1111w> we are wasting some space here, not dealing with something catastrophic
17:44:57 <ArticMine> If there is consensus on part of the change, but not the rest, why hold up the part that has consensus?
17:44:59 <sgp_> you know I want to separate the rings more than anybody (save space and protect users), yet this non-consensus change scares me
17:46:02 <ArticMine> One can enforce the coinbase with coinbase mix as consensus
17:46:35 <ArticMine> but keep the mixing at 11 if there is not agreement on the correct mixing
17:47:26 <sgp_> all: please comment on that Github issue if you haven't already
17:47:49 <sgp_> anything else on this topic or any other questions?
17:50:12 <sgp_> 4. Action items
17:50:44 <sgp_> sarang and I will put out the CLSAG audit report, hopefully in the next few days. It needs to go out
17:51:00 <sgp_> just waiting on OSTIF
17:51:21 <sgp_> everyone else?
17:53:19 <sgp_> as a part of the Monero Community Workgroup resources, I will start pushing a kanban board to keep track of tasks more. MRL is welcome to use it or not, but keep an eye out for that
17:53:33 <sgp_> if there is nothing else, we can conclude the meeting
17:53:54 <sgp_> Next meeting a week from now. Same bat time, same bat channel
17:54:08 <sgp_> Thanks for attending!
17:54:55 <ArticMine> Thanks
17:55:33 <Isthmus> Sorry, got pulled into a different meeting briefly.
17:55:33 <Isthmus> Hmm, if we implement coinbase stuff in core wallet but not consensus, that does create a nice window for Noncesense to leverage those fingerprints to study use of core vs non-core software :smiling_imp:
17:55:36 <Isthmus> Maybe better topic for -lounge, but I heard of an interesting token economic scheme used by Harmony One
17:55:36 <Isthmus> 441M tokens = emission + fees
17:55:36 <Isthmus> If fees are low, emission is high to sustain security. Once fees become significant enough to secure the chain, emission decreases.
17:55:36 <Isthmus> *It is not perfect!!* I'm always skeptical of constants that are hardcoded long in advance (like 441M ONE/yr or 0.6 XMR/block) and the miners could be incentivized to pull some shenanigans with high-fee txns to suppress emissions.
17:55:36 <Isthmus> But, the angle is interesting, and gave me something to think about.
17:56:27 <Isthmus> s/441M tokens/441M tokens per year
17:56:27 <monerobux> Isthmus meant to say: 441M tokens per year = emission + fees
20:01:07 <gingeropolous> honestly the coinbase selection thing *feels* good and it makes sense at an immediate level, which makes me suspicious of it
20:01:43 <gingeropolous> i don't know what I'd need to quell that suspicion. i mean, at the end of the day, it could be done in wallets, so any 3rd party wallet out there could go ahead and make these improvements
20:02:59 <gingeropolous> there are various kick the can options... one is bumping from 11 to 14, so offset these useless ring members
20:03:40 <gingeropolous> the other is to flag the coinbase ring members when the CLI shows you the .... datagram? timeline of ring members being used in your tx
20:04:04 <gingeropolous> so if you were so compelled you could craft your transaction with no coinbase ringmembers
20:04:32 <gingeropolous> but if we even think that some users would do that to increase the efficacy of their ring sig construction, then it probably should be default
20:05:53 <gingeropolous> then again, we've had these situations before... we *knew* for a long time that non uniform mixin levels was flawed, yet that sorta got punted down the lane for whatever reason
20:06:32 <gingeropolous> we also knew that allowing 0 mixin level txs was flawed, and yet that stuck around for a good while
20:07:05 <gingeropolous> so my point is that perhaps these gut feeling solutions that seem to good to be true are just fine.
20:07:35 <gingeropolous> don't mind me, just talking in circles over here
20:27:42 <needmoney90> Sgp_ I don't think the benefits of dropping the coinbase ring size are worth it. Even if inefficient, there's something nice about consistency
20:28:42 <needmoney90> I can see a 'false sense of security' perspective, and low ring sizes being a prompt for the users to recognize that
20:28:45 <gingeropolous> i dunno. it kinda makes sense to treat them differently. they are indeed different.
20:28:59 <needmoney90> Sure, I'm for coinbase/coinbase
20:29:19 <needmoney90> They're treated differently, but the consistent ring size is nice. Less gotchas
20:29:39 <needmoney90> 'our ring sizes are 11 except for coinbase txes which are 3' is unwieldy
20:30:16 <needmoney90> And we gain nothing other than a public signal that the txes are insecure (and a negligible bit of space)
20:30:57 <gingeropolous> well not making it public is just hoping to pull the wool over the eyes or whatever
20:31:10 <needmoney90> We can be vocal about the drawbacks
20:31:23 <needmoney90> Making a visible signal on chain has no precedent
20:32:47 <moneromooo> How much space is gained by moving from 11 to 3 ?
20:53:29 <sgp_> We would have to test. Not huge
20:53:55 <sgp_> I'm guessing "noticeable but still quite small"
20:54:51 <sgp_> I'm surprised Snipa isn't here pushing for smaller coinbase ringsizes to save on pool tx fees :p
20:58:12 <moneromooo> Because this is not #monero-lobbying.
23:11:52 <jwinterm> you guys all seen this? https://eprint.iacr.org/2020/688.pdf
23:12:18 <jwinterm> just saw it in last paragraph of this post https://bitcointalk.org/index.php?topic=5090272.msg54897029#msg54897029
23:12:18 <monerobux> [ [ANN][ZANO] New Sources|1st ProgPowZ|PoW/PoS Hybrid|Scalable|Private|Contracting ] - bitcointalk.org
23:12:30 <jwinterm> This means that we can set mixins at a level from up to 1000, keeping the reasonable size and processing speed of transactions.