04:02:37 <gingeropolous> i think an interesting consideration when it comes to our cost benefit for ringsize / time / space
04:02:37 <gingeropolous> -
04:03:15 <gingeropolous> if we deem it necessary to increase the ringsize, then it would have been necessary regardless of the current technology providing it.
04:04:03 <gingeropolous> for instance, with that recent image, if a ringsize of 2^5 is deemed necessary, then the actual comparison point would be there MLSAG would put it
04:04:24 <gingeropolous> thus, putting the triptych numbers into anonymity set size of holy cow
04:04:33 <gingeropolous> off the carts
04:04:35 <gingeropolous> charts
04:05:04 <gingeropolous> some words in there can come and go.... but you get the idea
04:05:36 <gingeropolous> i feel like , at least for myself, one way of looking at it was "well, MLSAG currently puts us at this, so with triptych we can get this at that cost"
04:06:21 <gingeropolous> but perhaps not. because if we deemed this (the second this) necessary, then we would have done it regardless of the cost (perhaps)
04:06:44 <gingeropolous> eh i shoulda prolly gone to the lounge for this
04:06:51 <gingeropolous> bouncer!
04:09:49 <gingeropolous> which i feel like boils down to the question of how many rings is enough, which is statistics i guess, of which im not a fan.
04:10:04 <gingeropolous> well not rings, but members
14:34:55 <sarang> Reminder that the weekly research meeting is today at 17:00 UTC (about 2.5 hours from now)
14:34:57 <sarang> .time
14:34:57 <monerobux> 2020-04-22 - 14:34:57
14:34:59 <sarang> good bot
15:23:26 <TrasherDK> .time
15:23:27 <monerobux> 2020-04-22 - 15:23:27
16:49:54 <Isthmus> Do you have to start the message with .time
16:50:02 <Isthmus> .time apparently
16:50:02 <monerobux> Could not find timezone apparently.
16:50:30 * Isthmus chuckles
16:50:41 <Isthmus> Not what I was expecting
16:54:12 <sarang> Oh, I bet it can provide the time in different locations/timezones
16:54:14 <sarang> .time utc
16:54:14 <monerobux> 2020-04-22 - 16:54:14UTC
16:54:22 <sarang> .time utc+4
16:54:22 <monerobux> Could not find timezone utc+4.
16:54:29 <sarang> .time us/pacific
16:54:29 <monerobux> Could not find timezone us/pacific.
16:54:39 <sarang> .time pacific
16:54:39 <monerobux> Could not find timezone pacific.
16:55:20 <sarang> Oh well. We'll start the meeting in about 5 minutes or so
16:59:42 <sarang> OK, let's get started with the meeting!
16:59:43 <Isthmus> .time PST
16:59:43 <monerobux> Could not find timezone PST.
16:59:57 <sarang> First, GREETINGS
16:59:58 <sarang> hi
17:00:10 * sarang will wait a couple of minutes for people to arrive
17:00:26 <sgp_> Hello
17:00:48 <moneromooo> .time localtime
17:00:49 <monerobux> Could not find timezone localtime.
17:00:49 <sgp_> .time cdt
17:00:50 <monerobux> Could not find timezone cdt.
17:01:24 <Isthmus> First agenda item is trolling the monerobux bot
17:01:43 <sarang> naturally
17:01:54 <sarang> Well, let's move to ROUNDTABLE
17:01:54 <atoc> ooh
17:01:58 <ArticMine> Hi
17:02:15 <sarang> I assume Isthmus would like to share the material he posted on the agenda issue?
17:02:27 <sarang> https://github.com/monero-project/meta/issues/456
17:02:45 <sarang> Specifically: https://github.com/monero-project/meta/issues/456#issuecomment-617883059
17:02:59 <Isthmus> Sure
17:03:03 <sarang> Go ahead!
17:03:08 <UkoeHB_> hi
17:03:27 <Isthmus> Just completed a study quantifying the impact of exchange rate volatility for Monero-denominated delayed payouts.
17:03:42 <Isthmus> Normally I consider exchange rate stuff out of scope for MRL but this is relevant to all CCS-funded contributors
17:04:25 <Isthmus> Hm, I was going to cut and paste from the GitHub issue but everything is slightly too long for IRC
17:05:05 <Isthmus> Basically, I put together a sliding window statistical analysis of the XMR price timeseries to create a framework for volatility risk management
17:05:11 <Isthmus> The TL;DR is this:
17:05:14 <Isthmus> [INPUTS:] X% confidence that a Y-month payout will cover the quote (based on the last Z months of data) can be achieved with an [OUTPUT:] V% volatility buffer.
17:05:46 <Isthmus> Suppose we want to look at the last 24 months of data
17:06:04 <Isthmus> And consider a 4-month sliding window (1 month to fundraise on CCS + 3 months to execute)
17:06:21 <Isthmus> Here are the outcomes based on historical data
17:06:23 <Isthmus> https://usercontent.irccloud-cdn.com/file/tbl4tkZn/image.png
17:06:28 <Isthmus> We observe an unfortunate asymmetry over the past two years, for example: contributors to projects with a 4-month timeline were more than twice as likely to experience a 50% decrease in compensation value (red line) than a 50% increase in compensation value (green line).
17:06:47 <sarang> That's quite the asymmetry
17:06:57 <Isthmus> That's the probability distribution function, the cumulative version is helpful too:
17:07:02 <Isthmus> https://usercontent.irccloud-cdn.com/file/2UBTfPI7/image.png
17:07:07 <Isthmus> The red cross highlights that USD/XMR decreased over 65% of sliding 4-month windows (i.e. only 35% of contributors would receive payouts worth the quote price). The orange cross shows that an 80% likelihood of receiving a sufficient payout would be achieved with a +35% buffer.
17:07:31 <Isthmus> Explaining the orange cross in the framework described above: 80% confidence that a 4-month payout will cover the quote (based on the last 24 months of data) can be achieved with a 35% volatility buffer.
17:07:45 <Isthmus> Now, let's consider what happens if we double the timeframe (so that the data include a bull market as well as cryptowinter). The previous plots spanned the last 2 years (blue dots); now let's extend this to 4 years (blue & green dots).
17:07:47 <Isthmus> https://usercontent.irccloud-cdn.com/file/aCapoFx3/image.png
17:07:53 <Isthmus> oops transparent background, ssorry
17:07:56 <Isthmus> Now that our we include both the bull run leading up to the all time high and the subsequent decay, the extended data set contains new outcomes on both sides of the red breakeven line (+ a few outliers omitted on this plot that are shown in the next).
17:08:02 <Isthmus> https://usercontent.irccloud-cdn.com/file/kiCGTbDh/image.png
17:08:09 <Isthmus> Over the 4 year history, we see that about 60% of the windows receive a payout covering the quoted value (red cross). Since the data set now includes an 8x bubble in its entirety, the volatility insurance rate for 80% confidence rises to a 170% buffer (orange cross).
17:08:14 <Isthmus> https://usercontent.irccloud-cdn.com/file/le8lMFik/image.png
17:08:40 <Isthmus> I'm hoping that having a volatility risk management framework like this will increase funding accessibility for people/businesses that want to contribute but cannot afford speculate on income.
17:08:44 * Isthmus ends ramble
17:09:10 <sarang> This is great data
17:09:19 <sarang> Any questions for Isthmus?
17:10:54 <sgp_> Volatility is expensive
17:11:11 <sgp_> No questions, but thanks for doing this
17:11:16 <Isthmus> ty :)
17:11:31 <sarang> I can share next, if there are no other questions for Isthmus
17:11:37 <ArticMine> More of a comment.
17:11:57 <ArticMine> Thanks for the work
17:12:30 <atoc> Yeah thanks, just for more clarity: what are Monero-denominated delayed payouts?
17:12:41 <ArticMine> What we are dealing with is more like a two bear market as opposed to volatility
17:13:32 <UkoeHB_> It seems like long delays in payouts are not worthwhile. Either donators or donation recipients will lose on fiat-equivalent purchasing power with a good probability
17:13:39 <ArticMine> With the bear trend longer than the term of the typical CCS
17:14:02 <atoc> ah I see what this is now
17:14:17 <atoc> I actually wondered about this previously too. This is definitely good info
17:15:14 <moneromooo> Donators can't lose. They get exactly what they intend in terms of exchange rate. Recipients can lose or win. Other market participants (which could also be the donators or recipients if they choose to play the markets in the meantime) will win or lose.
17:15:49 <UkoeHB_> Donators can lose if recipients justifiably ask for premiums in the name of volatility, so donators are paying for the volatility
17:16:23 <sarang> At any rate, it provides useful information for proposers and potential donors to assess the impacts of volatility
17:16:57 <sarang> Isthmus: did you want to also discuss TheCharlatan's possible work on timelocks?
17:17:02 <sarang> (you just posted to the agenda on it)
17:17:06 <ArticMine> I think volatility is the wrong term here
17:17:42 <Isthmus> @ArticMine yeah, there may be a more precise way to phrase it. Let me know if you have ideas
17:17:47 <Isthmus> @sarang sure
17:17:54 <Isthmus> We discovered a few months ago that Monero's plaintext unlock time leaks information and presents a transaction linkability risk
17:18:08 <Isthmus> An encrypted unlock time is possible and would solve privacy issues, however the design and performance characteristics must be carefully considered.
17:18:13 <sarang> Right
17:18:14 <ArticMine> The issue is a systematic downward trend during the term of the particular CCS
17:18:21 <sarang> We investigated this with the DLSAG preprint
17:18:26 <Isthmus> Insight has put together a proposal for Isthmus & TheCharlatan to research solutions over the summer. Looking for feedback on the plan here: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time
17:19:05 <Isthmus> Our goals are:
17:19:06 <sarang> The method from the DLSAG preprint works even without the dual-key output structure, and I have some code demonstrating both the general method and how various LRS constructions could be used for this
17:19:06 <Isthmus> Detailed system design decisions (e.g. unlock_time per output or per transaction?)
17:19:14 <Isthmus> Prototype code to quickly test different approaches , including simulating transaction construction, signing and verification
17:19:16 <Isthmus> Report of quantified space/time/privacy tradeoffs with each mitigation strategy
17:19:19 <Isthmus> Implementation code for Monero source tree, for at least one of the chosen approaches
17:19:23 <Isthmus> Comprehensive research analysis writeup , cross-referenced with code and documentation
17:19:35 <Isthmus> Oh sorry Sarang, go ahead
17:19:45 <sarang> Oh no, just providing some background; please continue
17:20:24 <Isthmus> Oh, that was the end of the list :- )
17:20:30 <sarang> Ha got it!
17:20:38 <sarang> Yeah, so there was already some work on this
17:20:47 <sarang> and I've been discussing it with TheCharlatan
17:21:07 <sarang> Basically you can follow an approach similar to that in DLSAG using any d-LRS construction
17:21:14 <sarang> Meaning MLSAG, CLSAG, Triptych can be used
17:21:28 <sarang> Obviously the scaling will be different in size/time
17:21:54 <sarang> But essentially you increase from a 2-LRS (signing key, amount key) to a 3-LRS (signing key, amount key, timelock key)
17:22:10 <sgp_> Does unlock time per transaction mean all outputs have the same unlock time?
17:22:10 <sarang> You also need to change how range proofs are structured, in a nontrivial way
17:22:15 <sarang> In theory, yes
17:22:29 <sarang> But it would depend on how it's designed
17:22:30 <Isthmus> Yep @sgp_ that's how it works currently
17:23:09 <sarang> Anyway, there's a marginal increase in transaction size to include the necessary auxiliary commitment data
17:23:20 <sarang> But more notably, there's a time cost that scales linearly with the ring size
17:23:21 <sgp_> Maybe market research some come first to see if there's a demand for per-output. Has this been done at all?
17:23:32 <sgp_> *should come
17:23:35 <sarang> This time cost exists regardless of whether the locks are per-output or per-transaction
17:24:03 <sarang> I have C++ timing data for CLSAG to show this, and could modify the new Triptych code similarly
17:24:13 <sarang> (no point doing it for MLSAG)
17:25:03 <sarang> Before there's too much time/effort invested in this, I think it'd be useful to determine what costs people think are acceptable to introduce this
17:25:40 <sarang> The signature stuff is pretty straightforward (from 2-LRS to 3-LRS), but there's additional engineering work for a much different handling of range proofs, which would also need to change the fee structure due to Bulletproofs DoS scaling
17:25:50 <sgp_> Does this impact transactions that use the locks only or all of them?
17:25:53 <sarang> and, of course, the timing hit needs to be considered
17:26:08 <sarang> Well, for maximum uniformity all outputs would need locks
17:26:16 <sarang> The lock could be set to 0
17:26:24 <sarang> but the time cost is the same
17:26:39 <sarang> Since for every ring member, you need to process its lock data
17:26:52 <sarang> and the verifier can't tell which locks are 0 due to the commitment structure
17:26:56 <UkoeHB_> I feel like knaccc since I can't imagine what utility timelocks have
17:27:09 <Isthmus> Crossing borders
17:27:18 <moneromooo> Would encrypting lock times prevent it from being used as a second layer building block ?
17:27:27 <sarang> Constructions involving cross-chain and off-chain channels would need them
17:27:37 <sgp_> Isthmus: how many transactions use these locks again? I lean towards not pursuing this unless there's a known demand
17:27:47 <sarang> moneromooo: encrypting timelocks were originally designed for 2nd layer stuff in DLSAG
17:27:51 <gingeropolous> i thought the second chain requires the kind of time locks that we don';t have yet
17:27:56 <sarang> They aren't required for DLSAG, but they are useful to avoid spend heuristics
17:27:57 <gingeropolous> second layer, sorry
17:28:20 <sarang> e.g. ring members whose locks have just expired may be more likely to be true signers, etc.
17:28:24 <gingeropolous> but i guess both types would need encryption
17:30:00 <sarang> Anyway, if the decision is to support timelocks, requiring the commitment structure is good for mitigating heuristics, but it comes at a definite cost
17:30:29 <sarang> and this cost scales with the ring size
17:31:29 <moneromooo> I'd be ok with a fair cost if it is instrumental having a good second layer, but not really otherwise.
17:31:32 <gingeropolous> it seems pretty integral if we want monero to be programmatic money
17:31:53 <sarang> To be clear, a solution like DLSAG requires timelocks, but does not require encrypted timelocks
17:32:07 <sarang> It is highly beneficial for uniformity if the timelocks are encrypted, however
17:32:08 <UkoeHB_> Isthmus it might help the proposal if there were some basic estimates of costs related to timelocks (storage requirements, additional EC ops), for both CLSAG and then for Triptych.
17:32:29 <sarang> UkoeHB_: I already have this data for CLSAG, and presented it quite a while ago
17:32:40 <sarang> For Triptych there are estimates (the C++ code didn't exist at the time)
17:32:44 <UkoeHB_> ah, in which case a link would be nice
17:32:50 <sarang> I can dig it up after the meeting
17:33:09 <TheCharlatan> That's only the costs for the signature and commitments though, right sarang?
17:33:21 <sarang> FWIW the branch is here for 3-CLSAG: https://github.com/SarangNoether/monero/tree/3-clsag
17:33:37 <sarang> TheCharlatan: the range proof wouldn't necessarily incur any extra costs
17:33:43 <sarang> Depending on if/how the limits are changed
17:34:46 <sarang> If desired, I can update the new Triptych C++ code to support timelocks, for data on performance differences
17:34:53 <sarang> it'd be pretty straightforward to do
17:35:44 <sgp_> I only really support the research if we know there's a solution on the table that Monero will use for second layer stuff. The "how to encrypt" question will be answered faster than the audit process. Maybe I'm not understanding the application, but I perceive this bug hurdle as needing to come first
17:35:45 <sarang> Anyway, I support the idea if it's based on a solid understanding of the costs, and has general consensus
17:35:57 <sarang> sgp_: we know exactly _how_ to do it
17:36:05 <sarang> (in terms of signature handling)
17:36:11 <sgp_> I meant selecting which is best
17:36:19 <sarang> What's not known are specifics related to range proofs, fee structure, etc.
17:37:09 <UkoeHB_> fee would be pretty simple to update afaik
17:37:43 <sarang> Perhaps. What changes is that the aggregated range proof now needs to account for newly-generated outputs, as well as a proof for each timelock input
17:38:02 <sarang> But it's still something that would need to be considered and completed in the design/deployment process
17:38:10 <UkoeHB_> right
17:38:18 <sarang> and it also complicates things since there are currently no specific input limits
17:38:39 <sarang> whereas Bulletproofs have a ceiling-power-of-2 verification cost, which is why we limit the output count
17:38:55 <sarang> Having a separate bulletproof makes little sense from a size perspective
17:39:05 <UkoeHB_> ah hm
17:39:46 <UkoeHB_> per-input timelocks may be expensive, but I defer to the estimates /o\
17:40:08 <Isthmus> Could we have 1 time per transaction, and an encrypted bit with each output
17:40:15 <Isthmus> 1 = use encrypted timelock
17:40:21 <Isthmus> 0 = default (10 blocks)
17:40:37 <sarang> Isthmus: you still need the signature and range components
17:40:51 <sarang> How you assign timelock commitments to outputs isn't really relevant there
17:41:31 <Isthmus> Mmkay, was just trying to think of a way to bee able to lock 1+ outputs without locking your change (without having an encrypted timelock for each output)
17:41:46 <sarang> That's a pretty minimal size cost
17:41:56 <sarang> The real kicker is verification
17:42:12 <sarang> and the specifics on range proof structure
17:42:26 <Isthmus> Yep, those are key things to nail down first
17:42:51 <sarang> Well, we have CLSAG code to give real numbers on that cost
17:43:01 <sarang> and it's easy to modify Triptych to give its costs
17:43:18 <sarang> What is not known is what time hit is considered reasonable
17:43:30 <sarang> "as low as possible" isn't a design decision
17:43:53 <sgp_> Can I step in since I really need to make sure I understand the big picture here
17:43:59 <sarang> sure
17:44:02 <sarang> of course
17:44:17 <sgp_> In order to add a feature, there should be at least some stated use for it, especially if there are costs
17:44:38 <UkoeHB_> nvm per-output timelocks would be cheap at 8 bytes per additional output, most cost is on input proving side
17:45:01 <sgp_> So the main benefit is the ability to add things like DLSAG and other related protocols that could allow second-layer right? That time locks are necessary for second-layer solutions we know about?
17:45:38 <sarang> Well, and we allow timelocks right now; but they have multiple accepted specifications, and likely introduce spend heuristics
17:45:51 <Isthmus> s/likely/do/
17:46:07 <sarang> So their presence and optionality introduce fingerprinting
17:46:10 <sgp_> right but they aren't used as far as we know for anything in particular?
17:46:13 <sarang> ^^ good point
17:46:25 <Isthmus> Not only are timelocks used
17:46:30 <Isthmus> 5 different formats are used
17:46:33 <Isthmus> See the documentation linked above
17:46:33 <sarang> that's what I meant
17:46:36 <Isthmus> So SOMEBODY is using them
17:46:48 <Isthmus> They're anonymous, unfortunately, so I don't know their use case
17:46:54 <sarang> Requiring a uniform format is an obvious first step
17:46:57 <UkoeHB_> what fraction of all tx have non-zero timelocks?
17:46:57 <TheCharlatan> sgp_ they are also useful for atomic swap purposes, if you are looking for specific features.
17:47:12 <jwinterm> was about to ask same UkoeHB_
17:47:53 <sgp_> https://usercontent.irccloud-cdn.com/file/xIfs2dFC/table
17:47:55 <jwinterm> TheCharlatan, but not in the state that they currently exist, right? I thought atomic swaps require the kind of time locks that bitcoin has - i.e., this tx can't be mined until certain time
17:48:13 <gingeropolous> yeah right now its payment channels (lightning network) and atomic swaps, for the most relevant application of timelocks (i think)
17:48:28 <Isthmus> They're not super widely used, on the order of 10k nonzero locktimes
17:48:33 <Isthmus> Of course, neither are subaddresses ;- )
17:48:46 <jwinterm> total number of txs is 10M order of magnitude?
17:48:52 <Isthmus> 6M
17:48:56 <Isthmus> Almos 7M
17:49:01 <Isthmus> *almost
17:49:09 <jwinterm> .c 1e4/7e6
17:49:09 <monerobux> jwinterm: 0.001428571429
17:49:11 <sgp_> dumb idea: why not threaten to remove this feature entirely unless someone justifies the need?
17:49:18 <jwinterm> 0.1% more than I would've guessed
17:49:56 <TheCharlatan> since we are spitballing a bit, Istmus and I also discussed introducing a more compact format. So if encrypting them is deemed undesirable, I believe we should still change their current behaviour to something more sane and less dangerous.
17:49:57 <sgp_> if these are caused by someone fucking around for no purpose, then why bother having them
17:50:19 <UkoeHB_> compact format?
17:50:34 <sarang> Do you mean supporting only a single uniform format?
17:50:43 <sarang> Because this seems like a natural first step
17:50:46 <UkoeHB_> iirc they are varints atm, so at most 9 bytes
17:50:52 <sarang> At least removing the fingerprinting possible within the use of timelocks
17:51:09 <sgp_> in order for the *cool* time-lock applications to come around, we need to agree to implement something else which would come with a large advance notice. This hasn't happened obviously
17:51:34 <sarang> Well, and there is no DLSAG-type payment channel use currently available
17:51:51 <Isthmus> @UkoeHB_ I thought it was uint64. I got a few outputs locked until 18446744073709551614 (about 500 billion years) over the weekend :- P
17:52:06 <sarang> Isthmus: something something store of value
17:52:15 <ArticMine> Using a single format for timelocks seems a sensible first step to me
17:52:18 <UkoeHB_> varints have up to 63 bits of information from what I understand
17:52:30 <Isthmus> oh yea
17:52:46 <sarang> OK, so in the interest of time, what's a good next step in this design process?
17:53:01 <UkoeHB_> cost estimates
17:53:18 <sarang> Isthmus TheCharlatan: let's discuss that after the meeting
17:53:18 <TheCharlatan> Exactly, but a varint for a timelock is completely overblown. There have been a lot of discussions on this in Bitcoin as well, for example to restrict the size to a 1 byte value that is then interpreted as a power of time.
17:53:26 <ArticMine> single format
17:53:27 <sgp_> I say the cost estimate of only the cheapest option to begin with to see if that action is warranted
17:53:28 <TheCharlatan> Personally I would get rid of time based lock times entirely.
17:53:46 <Isthmus> That introduces a correction term when blocktime changes
17:54:04 <Isthmus> But that's easy enough to do
17:54:30 <sgp_> TheCharlatan: haha exactly, or at least aggressively ask for justification from people who use them
17:54:40 <sarang> OK, so beyond investigating optimal single-format cleartext use and updated cost estimates, anything else on this topic for right now?
17:54:48 <sarang> (otherwise we could discuss it for hours...)
17:55:09 <sarang> going once
17:55:20 <sarang> going twice
17:55:27 <sarang> sold
17:55:28 <sgp_> nope, I just want to stress that we need to know why they are used before slowing down transactions
17:55:41 <sarang> I can briefly share a couple things in the time we have left
17:55:50 <sarang> I overhauled Triptych verification to support common-key batching
17:55:53 <TheCharlatan> and s/time/two - deleted the wrong word :(
17:56:20 <sarang> New timing data: https://usercontent.irccloud-cdn.com/file/TWAkCeJJ/timing.png
17:56:42 <sarang> This data represents the input-amortized verification cost for a 2-input set of signatures
17:56:52 <sarang> Assuming the same ring is used across both inputs for Triptych
17:56:58 <sarang> (for MLSAG/CLSAG it doesn't matter)
17:57:21 <sarang> I also overhauled the MLSAG tests for better consistency with the other series
17:57:24 <UkoeHB_> wait isnt that way faster?
17:57:29 <sarang> It should be
17:57:30 <selsta> What are amortized inputs?
17:57:41 <sarang> If you have a 2-input transaction, you need to compute 2 signatures
17:57:50 <sarang> For MLSAG/CLSAG, this takes twice the time as one signature
17:58:02 <sarang> For Triptych, if you use the same ring, you get huge batching benefits
17:58:32 <sarang> So this is the per-input cost for a 2-input transaction
17:58:45 <sarang> For higher-input-count txs that would share rings, the benefits get even better
17:58:59 <UkoeHB_> 🥳
17:59:12 <sarang> The gray crossed lines are centered at the current N=11 MLSAG point
17:59:33 <sarang> This implies that Triptych becomes slower than right now (for 2-input txs) between N=64 and N=128
17:59:46 <sarang> (but you can't split the difference... you need to pick a power of 2)
18:00:03 <sarang> Anyway, hopefully this gives more realistic timing data, at least across 2-input txs
18:00:26 <sgp_> is 128 about the same time as DLSAG 12? 13?
18:00:28 <sarang> You can use my `triptych` branch and `clsag-device` branch to construct this data for yourself
18:00:40 <sarang> I don't have C++ data for DLSAG
18:00:48 <sgp_> soory I meant MLSAG
18:01:09 <sarang> I'd have to run some quick MLSAG tests on those intermediate numbers
18:01:18 <sarang> I can have that shortly after the meeting (need to do a new build)
18:01:24 <sgp_> it's fine, not that important
18:01:31 <sarang> It's easy, just takes a few minutes
18:01:55 <sarang> Anyway, that's what I wanted to share
18:02:04 <sgp_> cool stuff
18:02:08 <sarang> Does anyone else have research to share (we're running a little long, but that's ok)
18:02:08 <UkoeHB_> very cool
18:02:23 <UkoeHB_> hi yes, this proposal went up this week https://github.com/monero-project/monero/issues/6456
18:02:35 <UkoeHB_> it's a synthesis of discussion and research from IRC over the past months
18:03:10 <sarang> It's very comprehensive :)
18:03:20 <sarang> I admit that I haven't had a chance to sit down and devote time to it :/
18:03:34 <sarang> However, do you have any concrete suggestions at this point UkoeHB_?
18:04:41 <UkoeHB_> there needs some debate about whether to pursue Janus, and which solution to adopt, but otherwise tx structure recommendations, sorted tlv, and view tag all seem concrete to me
18:04:57 <sarang> Neat
18:05:12 <sarang> I'll devote time to it before the next meeting for sure
18:05:14 <UkoeHB_> also moving to mandating 1 tx pub key for 2-out tx, and 1 key per output for >2 out tx
18:05:21 <sarang> Many thanks for continuing work on that
18:05:53 <sarang> OK, let's briefly review ACTION ITEMS before we adjourn
18:06:04 <Isthmus> "1 tx pub key for 2-out tx" < is that assuming that every 2-output txn has a change output?
18:06:29 <Isthmus> *change or dummy
18:06:32 <UkoeHB_> we only have to make that assumption if Janus is implemented
18:07:11 <Isthmus> Ok, so then if there's a txn being split between 2 (non-change) recipients, it must be constructed as a 3-output txn with a dummy output, right?
18:07:20 <UkoeHB_> right
18:07:48 <Isthmus> Eh that seems harmless. Is a corner case anyways.
18:07:54 <Isthmus> Sorry @sarang go ahead
18:07:57 <sarang> Someone volunteered to do a review of the CLSAG code, which was very helpful... they also recommended adding Poly1305 authentication to wallet encryption, which is a good idea to prevent chosen-ciphertext adversaries
18:08:24 <sarang> Aside from that, I'll pull up some 3-CLSAG and 3-Triptych data to help the timelock discussion, as well as some stuff on Arcturus
18:08:28 <sarang> that's all for me :)
18:08:29 <sarang> Anyone else?
18:09:32 <Isthmus> I'll expand the timelock proposal with some more references/data/use cases
18:10:17 <Isthmus> And I'll probably finish another quantum-resistance proposal today or tomorrow, currently incorporating feedback into the first draft
18:10:22 <sarang> great
18:11:09 <sarang> Any other final action items before we adjourn?
18:11:10 <Isthmus> Oh yea, and I'll read UkoeHB_ 's epic github issue :- )
18:12:07 <sarang> Righto, we are now adjourned! Thanks to everyone for a great meeting
18:12:14 <sarang> Logs posted shortly; discussion can of course continue
18:12:36 <sarang> sgp_: 2-input amortized Triptych corresponds to 13-MLSAG
18:12:48 <sgp_> thanks
18:13:06 <sarang> also Isthmus and TheCharlatan: what would be most helpful from me regarding 3-CLSAG and 3-Triptych timing data?
18:13:16 <sarang> I don't want you to do unnecessary coding work that's already been completed
18:15:43 * Isthmus is in a video call now, will circle back after lunch. 
18:15:45 <Isthmus> Definitely want to take advantage of your extant work. :- )
18:16:39 <TheCharlatan> Yeah, I won't re-implement anything you have already built ^^
18:16:42 <sarang> no prob
18:17:04 <sarang> The 3-CLSAG repo would need to be updated to reflect some new verification optimizations
18:17:23 <sarang> the 3-Triptych stuff is straightforward but not complete yet
18:19:50 <sarang> For initial timing purposes, ignoring range proofs is probably quite reasonable, since those scale much better (if they need to scale at all)
19:20:42 <dEBRUYNE> sgp_: Has any progress been made on the 'official' audit of CLSAG?
20:54:17 <derpy_bridge> <[keybase] seddd>: apologies for missing the meeting (network issues)
21:01:07 <sarang> No prob
21:01:11 <sarang> Agenda issue has logs
21:02:01 <sarang> Anything you'd like to share now?
21:15:17 <derpy_bridge> <[keybase] unseddd>: ah, better :) (consistencyinnames)
21:15:36 <derpy_bridge> <[keybase] unseddd>: this week I'll be fuzzing
21:16:16 <derpy_bridge> <[keybase] unseddd>: have a fuzz test written, and will do a PR (against clsag-device?) when all the kinks are worked out
21:21:22 <derpy_bridge> <[keybase] unseddd>: will also be reviewing monero/6456, brainstorming, etc
21:21:39 <sarang> Neat! Yes, please make any PRs against the `clsag-device` branch of `SarangNoether/monero` repo
21:21:56 <sarang> (for CLSAG)
21:22:08 <derpy_bridge> <[keybase] unseddd>: will do :)
22:58:27 <sarang> Test code for 3-Triptych, relevant to earlier timelock discussion: https://github.com/SarangNoether/monero/tree/3-triptych
22:58:42 <sarang> And corresponding timing data: https://usercontent.irccloud-cdn.com/file/usvO8BF4/timing.png
22:59:06 <sarang> Note that _only_ the yellow series represents timelock-compatible signatures
22:59:16 <sarang> All other data is identical to that shown earlier today in the meeting