4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-04 23:51:11 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

posts: Add MRL meeting logs

Browse Source 
Add MRL meeting logs from 2019-10-28 to 2020-06-03.
This commit is contained in:
Matthew Smith 2020-06-09 16:46:12 +01:00
parent 18fe5151ab
commit dced4ef16e
29 changed files with 4735 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
_posts/2019-10-28-mrl-meeting.md Normal file
View File

@ -0,0 +1,63 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-10-28
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<sgp\_\>** hello!
**\<sarang\>** I'll give a few moments for others who wish to join
**\<sarang\>** OK then
**\<sarang\>** Since suraeNoether is unavailable for this meeting due to an appointment, I'll share my recent work
**\<sarang\>** I've been working on algorithms and proofs for Triptych, a new transaction protocol
**\<sarang\>** The goal is to use a single proof to represent multiple inputs at the same time, including balance proving and linking tags
**\<sarang\>** Everything works great with completeness, zero knowledge, and soundness except for one proof component (the linking tags)
**\<sarang\>** There's a less efficient version that operates on single inputs, but can be combined for general transactions
**\<sarang\>** For this single-input version, modified proofs of security seem to work just fine
**\<sarang\>** For this reason, I'll finalize work on the single-input proving system while considering alternate approaches to finalizing the soundness proof for the multi-input version
**\<sarang\>** Separately from this, I have a small pull request (PR 6049) for a minor speedup and simplification to the Bulletproofs prover
**\<sarang\>** Also separately from this, Derek at OSTIF informs me that an audit group is willing to complete the CLSAG review
**\<sarang\>** JP Aumasson has offered to complete a review of the math and proofs for $7200 (USD), and his new company Teserakt has offered to then complete a code review for as little as $4800
**\<sarang\>** He says that including dependencies would increase the time (and therefore the cost), possibly significantly
**\<sarang\>** But the timeline could be before the end of this year, if there are no changes required to the algorithms after the math review
**\<moneromooo\>** Dependencies, like the src/crypto code ?
**\<sarang\>** Presumably. I do not have specific details on what his scope is (but will get this information)
**\<sarang\>** One approach might be to review all the changes \_from MLSAG_, to show that CLSAG is no less secure as a whole than MLSAG
**\<sarang\>** These changes are fairly minor in the grand scope of the codebase
**\<sarang\>** I see there being efficiency advantages to having JP (and colleagues) doing both types of review, but this also reduces the total number of eyes on the combined math+code
**\<sarang\>** That being said, JP knows his stuff
**\<sarang\>** (he was formerly with Kudelski)
**\<moneromooo\>** Adding eyes by having Alice do the math and Bob do the code does not provide anything of value over Alice doing both IMHO.
**\<moneromooo\>** Assuming Alice and Bob have similar eyes and brains and proficiency in the relevant fields etc etc etc.
**\<sarang\>** So that's my report
**\<moneromooo\>** Is any of the new protocols being considered still compatible with multisig ?
**\<sarang\>** Aside from CLSAG, you mean?
**\<sarang\>** None of them specifically consider it in either algorithms or security model
**\<sarang\>** but it's on my list for analysis on RCT3 and (eventually) Triptych, since there are some modifications to RCT3 that I wish to consider (more on this later)
**\<moneromooo\>** I mean tryptich, rct3 and... and.......... the other the name of which escapes me.
**\<moneromooo\>** lelantus
**\<sarang\>** Omniring?
**\<moneromooo\>** Also :)
**\<sarang\>** Omniring and Lelantus both suffer from some drawbacks at present... Omniring does not support batching, and Lelantus still has a tracing issue unless you remove stealth addressing
**\<sarang\>** Looking into batch-compatible Omniring-style constructions with other proving systems is a topic for more investigation down the road that is nontrivial
**\<sarang\>** Is there other research that anyone wishes to present, or other questions?
**\<moneromooo\>** Also, rather selfishly, would any of them avoid the public-a issue we had for multi user txes ?
**\<moneromooo\>** (if known offhand)
**\<sarang\>** public-a?
**\<moneromooo\>** The problem where users would have to make their a values known to other signers.
**\<sarang\>** Ah, that's very unclear to me
**\<sarang\>** FWIW: RCT3, Omniring, and Triptych are agnostic to how output keys are generated (though their security models address particular constructions)
**\<sarang\>** So my ACTION ITEMS for this week are a bit in flux, mainly because I'll be at World Crypto Conference giving a talk on transaction protocols
**\<sarang\>** But aside from that, I want to finish the proof modifications (completeness, SHVZK, special soundness) for the single-input version of Triptych (which can be used in a larger protocol to support multi-input transactions), as well as a more efficient linking tag construction that matches what RCT3 and Omniring propose
**\<sarang\>** I also want to backport some of the ideas from the latest RCT3 update to their older version to compare efficiency
**\<sarang\>** It's unclear if this could easily be proven secure, or what the efficiency gains would be
**\<sarang\>** Their update did essentially two things: fix an exploitable flaw due to a particular discrete log relation, and allow for aggregated proofs of multiple inputs
**\<sarang\>** Unfortunately, the latter means potentially large padding requirements that would also incur computational cost to the verifier
**\<sarang\>** I want to see how easily the exploit fix could be included in the non-aggregated version... which would avoid this potential verification bloat at the cost of proof size
**\<sarang\>** I probably won't have time to do so this week, but it's on my list
**\<sarang\>** Anything else of note to cover before we formally adjourn?
**\<sarang\>** All right! Thanks to everyone for attending
**\<sarang\>** Logs will be posted shortly to the GitHub agenda issue

115
_posts/2019-11-04-mrl-meeting.md Normal file
View File

@ -0,0 +1,115 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-11-04
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<suraeNoether\>** GREETINGS!
**\<suraeNoether\>** I'm surae, I'm a taurus maybe, and i like long walks on the beach with high probability
**\<sarang\>** Hi
**\<suraeNoether\>** anyone else here?
**\<suraeNoether\>** well, public logs will be posted of this meeting either way, so anyone who missed it can find the logs online
**\<suraeNoether\>** okay, well, sarang, would you like to start?
**\<sarang\>** Sure
**\<sarang\>** I've been working on a few things...
**\<sarang\>** More Triptych work, on math/proof for single inputs, which are fine
**\<sarang\>** This includes some CLSAG-style key aggregation and more efficient key images
**\<sarang\>** (more on multi-input in a sec)
**\<sarang\>** Also gave a talk on transaction protocols
**\<sarang\>** And looked at using the existing transaction proofs to mitigate the Janus subaddress attack
**\<sarang\>** As to multi-input Triptych, this link is to the Overleaf paper: https://www.overleaf.com/read/ncqsdsydxvjv
**\<sarang\>** (multi.tex)
**\<sarang\>** The problem with witness extraction is the last equation on page 7
**\<suraeNoether\>** you and arthur are planning on submitting for peer review, yes?
**\<sarang\>** We could, once/if the proofs work out for multi-input
**\<sarang\>** We want to show that for every spent input M, H(M) = r\*J
**\<sarang\>** where J is the key image
**\<sarang\>** and M = rG
**\<sarang\>** What we instead show is that a sum of the form \sum\_u (\mu\_u \* H(M\_u)) = \sum\_u (witness\_u J\_u)
**\<suraeNoether\>** do you have your talk powerpoint up on your github?
**\<suraeNoether\>** by chance
**\<sarang\>** yes
**\<sarang\>** It's also the case that the sum of all witness\_u is equal to the witness found for the signing key check
**\<sarang\>** Two equations above that one
**\<suraeNoether\>** found it: https://github.com/SarangNoether/talks :P
**\<sarang\>** I don't see a good line of reasoning to show why such a witness extraction would be equivalent to the honest generation of those key image
**\<suraeNoether\>** i'm taking a look now.
**\<suraeNoether\>** that shouldn't discourage anyone else from looking tho
**\<sarang\>** (you have to swap the two sums in the last equation to get something of the form that's two equations above, but that's fine)
**\<suraeNoether\>** janus mitigation right now is extra schnorr signatures, right?
**\<sarang\>** Yes, but you can use the existing transaction proof method, provided you check against a complete subaddress
**\<sarang\>** It's still off-chain, but functionality that exists now
**\<suraeNoether\>** very nice. iirc sgp\_ wrote something on the janus vulnerability and made a blog post about it, or has a draft prepared. is that out or does it need updating or anything like that?
**\<sarang\>** Probably, but I'd like someone else to confirm that tx proof verification does in fact require external input of the suspected subaddress
**\<sarang\>** and that it's not pulled from the proof string in any way, or otherwise influenced directly by the prover
**\<sarang\>** (since the prover could simply use the Janus-modified subaddress)
**\<sarang\>** For this witness extraction, I suspect that it may possible to show that each u-summand in the X-check is in fact equal to a particular r\_u term
**\<sarang\>** If that's the case, then we could easily show that the u-summand scalars in the Y-check are those \_same\_ r terms
**\<suraeNoether\>** great, does anyone else have any other questions for sarang about his work on triptych, or his work on janus, or questions about his talk?
**\<suraeNoether\>** well, my work this week has been on the matching code ( https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching ) which has some peculiar failings right now
**\<suraeNoether\>** my basic unit tests for graphtheory.py, which handles all the graph theoretic stuff, are passing. nodes and edges are added and deleted correctly, weighted correctly, matches are found, etc.
**\<suraeNoether\>** but when i simulate a ledger with my simulator.py tool, the result misses some nodes and/or edges
**\<suraeNoether\>** these aren't being caught lower down, but are being caught higher up
**\<sarang\>** hmm
**\<suraeNoether\>** so anyone with interest in python, graph theory, traceability, etc, can contribute by trying to figure out why my code isn't adding edges/nodes appropriately all the time. it's very bizarre behavior, and i'm sure it comes down to something ridiculous like my previous buffer problem
**\<suraeNoether\>** but, i want to put it down for a few days since other folks in theory could help, and i have other things to do like help review triptych's proofs
**\<sarang\>** That seems reasonable
**\<sarang\>** Is it clear in the code (or errors) where the specific problems are?
**\<sarang\>** i.e. if someone wishes to play around with it
**\<suraeNoether\>** running sh tests.sh from the tools folder will auto detect all the tests and execute them; i've skipped all the tests i know are currently passing, so it'll go right into the brick wall immediately
**\<sarang\>** got it
**\<sarang\>** suraeNoether: if you're going to be on IRC this afternoon, we could dive into that witness extraction and see if we can't solve it
**\<sarang\>** I have some ideas
**\<suraeNoether\>** beyond that, i have a few papers i have begun reading, such as this one https://eprint.iacr.org/2019/1177.pdf on aggregation approaches, and a few others on interactive versions of concensus mechanisms like this one https://eprint.iacr.org/2019/1172.pdf
**\<suraeNoether\>** sarang: i'm catching up on the triptych paper now and whiteboarding it
**\<suraeNoether\>** if i go all pepe sylvia on the thing i may take a crazed picture for posterity
**\<sarang\>** excellent reference
**\<sarang\>** I'll add a few more lines to page 7 to show how the X and Y witnesses are related
**\<sarang\>** since that should come into play in the Y-soundness
**\<suraeNoether\>** https://www.youtube.com/watch?v=InbaU387Wl8
**\<suraeNoether\>** so my action items today are: triptych whiteboarding, janus tx proof validation check (the external input issue you just mentioned)
**\<sarang\>** great
**\<suraeNoether\>** my action items immediately are to post my work report for last month and request funding for my next quarter, but i hate that and i much prefer coding and math so i'm finding myself v avoidant
**\<sarang\>** For this week, I'd (ideally) like to figure out this soundness issue... if it's possible to do so, it provides a very interesting extension to this Groth proof scheme
**\<suraeNoether\>** does anyone have any other research to advertise, or other questions for sarang or i?
**\<sarang\>** and would make Triptych a competitive option for tx protocol
**\<suraeNoether\>** it's such a great name
**\<sarang\>** suraeNoether: here are some general notes on the witness structure for ya
**\<suraeNoether\>** afk for about 10 minutes
**\<suraeNoether\>** sarang ^ yes pls!
**\<sarang\>** The prover wants to show that it knows the discrete logs (r-terms, in notation) for each of the signing pubkeys (M terms)
**\<sarang\>** so it knows a set of r (indexed by u different spends, no index here for clarity) such that M = rG for each one
**\<sarang\>** it also wants to show that H(M) = rJ for each one, where each J is a key image provided by the prover
**\<sarang\>** When done honestly, each J is defined such that J = (r^-1)\*H(M)
**\<sarang\>** In the soundness proof, the "X check" is for signing keys, and the "Y check" is for linking tags
**\<sarang\>** X-soundness allows us to extract a witness (which involves certain Vandermonde-related coefficients) r1 such that r1\*G = mu\_1\*M\_1 + mu\_2\*M\_2 + ...
**\<sarang\>** and we claim (MuSig/CLSAG-style) that knowing this witness r1 implies knowledge of each of the r terms going into the right-hand sum
**\<sarang\>** Ideally, for the Y-soundness, we want to extract a related witness that implies knowledge of the same r-terms that go into the linking tag identities
**\<sarang\>** If you stare at the rightmost terms of the bottom equation and third-from-bottom equations on page 7, you can see the u-summands match up
**\<sarang\>** If we can show (using the form of the Vandermonde coefficients, etc.) that each u-summand in the X-soundness corresponds properly to an r-value, we may be able to make a solid argument about using those same u-summands in the Y-soundness equation (since we need the \_same\_ r-values there)
**\<sarang\>** The construction of the Vandermonde-related coefficients \theta\_e is also discussed on page 7 (and can be found in the original Bootle paper's proof)
**\<suraeNoether\>** back
**\<sarang\>** This might get complicated, since rows of the Vandermonde matrix correspond to different F-S challenges :/
**\<sarang\>** sarang is done talking now
**\<sgp\_\>** suraeNoether: yes, the blog post should be updated to include the mitigation
**\<suraeNoether\>** hmmmm
**\<suraeNoether\>** sgp\_: can you link the post for the meeting logs pls?
**\<sarang\>** sgp\_: once it's been confirmed that the verifier externally provides the expected subaddress
**\<suraeNoether\>** showing the correspondence like that has always been a sticking point :\
**\<sgp\_\>** https://getmonero.org/2019/10/18/subaddress-janus.html
**\<sarang\>** suraeNoether: unless you can think of a good argument that having the same summand terms in both the X- and Y-witnesses is sufficient already
**\<suraeNoether\>** well, i'll catch up and then i'll see what you mean by that. :P
**\<sarang\>** e.g. we already claim that knowledge of that sum-witness in the X-portion is equivalent to knowledge of each discrete log
**\<sarang\>** sure
**\<suraeNoether\>** \*nod\*
**\<sarang\>** Just remember that the key to the linking is that we show that the \_same\_ r-terms are used to construct the signing keys \_and\_ the corresponding linking keys
**\<sarang\>** so having the same witnesses should come into play
**\<sarang\>** It gets tricky because we don't directly show knowledge of each r-term, just the mu-weighted CLSAG-style combination
**\<sarang\>** So I wonder if we in fact already have all the information we need to show this
**\<sarang\>** and perhaps don't need to mess with those Vandermonde coefficients (which would be a huge pain to do)
**\<suraeNoether\>** okay, does anyone else have any research to talk about, or questions for MRL, or requests/points to bring up/etc?
**\<suraeNoether\>** otherwise we can adjourn the meeting and continue chatting about triptych outside of that context
**\<sarang\>** roger

83
_posts/2019-11-12-mrl-meeting.md Normal file
View File

@ -0,0 +1,83 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-11-12
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Hello all
**\<sarang\>** Meeting begins presently
**\<sgp\_\>** hello
**\<sarang\>** First, GREETINGS
**\<sgp\_\>** darn, beat you to it :)
**\<sarang\>** Next up, ROUNDTABLE
**\<suraeNoether\>** howdy :D
**\<suraeNoether\>** sarang how about you go first
**\<sarang\>** I backported the RCT3 exploit fix from the multi-input aggregated proving system to the single-input prover, updated code to reflect this, and checked the relevant security proofs for this construction
**\<sarang\>** Also went through some math on ways to support multisignatures securely on the sublinear protocols under consideration, with no good answers
**\<sarang\>** As of now, the constructions for RCT3, Omniring, and Triptych all require an output secret key inversion, which is incompatible with the linear-combination method used for doing multisignatures
**\<sarang\>** This only comes up for RCT3 and Triptych in the key image generation step, but it's still unfortunate
**\<suraeNoether\>** i was reading about some signature schemes that don't use hash functions and do use key inversion the other day... when i review your stuff on triptych soundness later today, i'll see if there is anythingt obvious that jumps out at me
**\<sarang\>** Thanks
**\<suraeNoether\>** i would assume it's not obvious because you and randomrun are both v diligent
**\<sarang\>** A few things are still in progress too
**\<sarang\>** Regardless of multisignature support, I'm working up a preprint on Triptych for IACR eprint
**\<sarang\>** It'll either be the provably-secure single-signer version, or the multi-signer version if the soundness argument works out
**\<sarang\>** It'll include the same PRF-based key image construction as found in RCT3 and Omniring, since that's much more efficient than one based on hashing public keys
**\<sarang\>** Now passing the baton to suraeNoether
**\<suraeNoether\>** cool, so for our traceability analysis, i'm collecting data now. i presented some preliminary results from a \*single\* simulation yesterday that were rather promising, but can't be generalized yet
**\<sarang\>** Is the code for those results currently pushed to your repo?
**\<suraeNoether\>** indeed, all you do is run playerchallenger.py with python3 and simulation results will be spit out
**\<sarang\>** Can you provide the branch and commit for that version, to be sure we're running the same code?
**\<suraeNoether\>** of course, the results will vary from simulation to simulation so the precise numbers i provided yesterday will change from simulation to simulation
**\<sarang\>** right
**\<suraeNoether\>** https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching is the present up to date everything
**\<sarang\>** Got it, thanks
**\<suraeNoether\>** the code isn't complete in a lot of ways (there are always ways to make the weighting scheme selected by Eve to be better and to take into account more data), but it's complete enough to start doing some data analysis to get some hard numbers on churn
**\<sgp\_\>** How can I configure it to test with different churn parameters?
**\<suraeNoether\>** i am currently modifying the code to specifically investigate churn, which requires some changes to the very front end of my simulations; i don't expect it to be done today
**\<suraeNoether\>** ^ heh
**\<sgp\_\>** ok, so stay tuned
**\<sarang\>** I'm seeing commit d5076 as most recent
**\<suraeNoether\>** indeedindeed, d5076 is most common
**\<sarang\>** roger, thanks
**\<suraeNoether\>** i think MRL-churn-numbers will have some more satisfying answers later this week
**\<suraeNoether\>** other than that: catching up on the RCT, omni, and triptych work that sarang has been doing
**\<suraeNoether\>** that's all i have. OH my work report and stuff like that :P
**\<scoobybejesus\>** fingers crossed my question makes sense
\< could the logistics be made to work such that signing a tx still happens via linear-combination but key image is derivable independently by multisig members?
**\<sarang\>** We'd need a secure MPC for the function J(x) = (1/x)\*U
**\<sarang\>** If there is such a thing, it's all ok
**\<sarang\>** (here U is a globally fixed curve group generator)
**\<sarang\>** I'm trying to find the paper where that particular PRF was first introduced
**\<sarang\>** Cited from Omniring (reference 20): https://www.iacr.org/cryptodb/archive/2005/PKC/3320/3320.pdf
**\<sarang\>** Anything else to share or discuss from anybody?
**\<sarang\>** Besides me both liking and disliking that particular pseudorandom function =p
**\<suraeNoether\>** Just compute the logarithm then add ;)
**\<sarang\>** But for real, an MPC for that function based on linear combinations would solve the multisig problem AFAICT
**\<sarang\>** It may not be possible while retaining its nice PRF properties
**\<sarang\>** (perhaps there's a formal argument that such an MPC couldn't exist)
**\<suraeNoether\>** Slightly more seriously: why not compute the inverse of the product of the private keys and instead of a partial sum on the basepoint being passed around, a partial product on the basepoint is passed around...
**\<suraeNoether\>** If I have x and you have y, let the combined key be 1/(xy) U
**\<sarang\>** If you take away the affine nature of the composite key, I don't see a way to make that work cleanly with the rest of the proof
**\<sarang\>** nor do I immediately see what partial key image data would be passed around to construct the full image
**\<suraeNoether\>** I send you (1/x)U. You multiply by 1/y...
**\<suraeNoether\>** So it's not just an mpc you need but specifically a linear function of the input keys...
**\<sarang\>** Perhaps. I was thinking in the context of linear key combinations initially (since the rest of the proofs play nicely with that)
**\<sarang\>** The current multisig works nicely because everything plays nicely with linear combinations
**\<sarang\>** But point taken that if it were possible to relax that restriction, it could be quite compelling
**\<sarang\>** The only point in Triptych and RCT3 that requires the use of a full private key (outside of key image construction) is at the end of the proofs, to construct a particular masked scalar
**\<suraeNoether\>** Hmm
**\<suraeNoether\>** Ok well I am going to continue reading on triptych and I will try to make a push later today to mess with churn number in my simulations for sgp\_
**\<sarang\>** Righto
**\<sarang\>** Let me know if you have any additional thoughts on multisig/MPC constructions too
**\<sarang\>** Oh, and here's a neat paper that came out recently for doing composable zk proofs in a Python library: https://arxiv.org/abs/1911.02459
**\<sgp\_\>** thanks suraeNoether. I'm interested in testing your model out
**\<sarang\>** So perhaps on to ACTION ITEMS now?
**\<sarang\>** Mine are to wrap up the Triptych formalization to a preprint as much as possible, while considering options for secure MPC
**\<sarang\>** and then I want to do a deeper review of suraeNoether's recent work on his simulation code
**\<sarang\>** (and clear a backlog of lit review)
**\<suraeNoether\>** My big backlog for matching at this point is commenting it and documenting how it works for anyone who wants to pick it up
**\<suraeNoether\>** But other than that, I am reading today and doing my work reoorts

79
_posts/2019-11-18-mrl-meeting.md Normal file
View File

@ -0,0 +1,79 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-11-18
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** First, GREETINGS
**\<sarang\>** Hello
**\<hyc\>** heylo
**\<mikerah\>** hello
**\<sarang\>** For today's ROUNDTABLE, I have a few things of interest to share
**\<sarang\>** Updates to the RingCT 3.0 analysis and code reflect its two provably-sound versions: https://github.com/SarangNoether/skunkworks/blob/sublinear/rct3.md
**\<sarang\>** One version is the authors' padded-input version that implies some restrictions on the signer count
**\<sarang\>** The other version is a backport I did of the exploit fix from their newer version to the original one, with corresponding changes to security proofs
**\<sarang\>** Triptych analysis now reflects an optimized multi-signer version: https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
**\<sarang\>** as does its code and the draft writeup
**\<sarang\>** I have shared the writeup with a few additional researchers as well, in the hope of getting extra eyes on the soundness proof
**\<sarang\>** The CLSAG paper was unfortunately rejected for the Financial Cryptography 2020 conference (which only had a 22% acceptance rate, according to the committee)
**\<sarang\>** Here are the reviewer comments: https://gist.github.com/SarangNoether/e39db743c3260448c1d67c3622b43f4b
**\<sarang\>** Reviewer A, who recommended rejection, made some detailed points about the security model: particularly how ambiguity and linkability are treated relative to some other papers
**\<sarang\>** Once suraeNoether returns, I want to discuss the particulars of this
**\<sarang\>** I'm not convinced that the more complete linkability treatment (which ties in ambiguity as well) is needed, given the use case
**\<sarang\>** However, the recommendation for a more robust treatment of signer ambiguity is fair
**\<sarang\>** The notes about the k-OMDL assumption being less common are also fair, but that's the best hardness assumption that was found for the proofs in question
**\<sarang\>** Related to CLSAG: Derek at OSTIF tells me that JP Aumasson, who quoted $7200 to review the paper, is available presently to do so, and it's not clear at the moment when he would be unavailable again
**\<sarang\>** I didn't sense a lot of broad support for this earlier
**\<sarang\>** Given that the FC2020 review comments just came back, the paper should be updated to reflect the notes before being sent off to anyone for additional review
**\<sarang\>** So the timeline on this seems unclear right now
**\<sarang\>** Does anyone else wish to share interesting news or research?
**\<sarang\>** Righto
**\<sarang\>** My ACTION items are to address CLSAG reviewer comments to update the preprint, finalize single-signer Triptych analysis and the associated preprint, continue working with others on whether multi-signer soundness is provable using known assumptions, and examine the current state of suraeNoether's graph-matching work
**\<sarang\>** What a quiet meeting =p
**\<MalMen\>** normaly this meetings are you talking with suraeNoether :P (at least the lasts I watch)
**\<MalMen\>** I am reading the links you posted, thank you for the heads up
**\<sarang\>** selsta also posted this link elsewhere, which I found very interesting: https://medium.com/dragonfly-research/breaking-mimblewimble-privacy-model-84bcd67bfe52
**\<sarang\>** Looking at a practical attack on Grin using network observation
**\<MalMen\>** I did start to understud better how MW work with that research
**\<MalMen\>** there is not much they can do about this kinda of attack unless users kinda of "coinjoin" the transactions with know peers before releasing them to the all network
**\<MalMen\>** for what I did understund about it
**\<sarang\>** It definitely highlights the importance of the network and propagation layer in transactions
**\<kico\>** seems like using 8 peers only by default is kinda dangerous
**\<sarang\>** vtnerd has been looking into the tricky interactions involved with integrating Dandelion++, I2P, Tor, and the like
**\<kico\>** I mean for dandelion to work "properly"
**\<MalMen\>** It should be possible to get some farly good level of privacy with MW, but the way the transactions are propagated would need to became more complex in order to ofuscate the way they are made
**\<sarang\>** How so? Dandelion++ provides restrictions on stem neighbor selection for a given time epoch
**\<MalMen\>** kinda of what Bitcoin think they can do on layer2 to obuscate the linkability on layer1
**\<kico\>** I guess if one connects to more peers it increases the chance that it aggregates transactions before they're peered to the network for what I understood from that paper
**\<sarang\>** A good lesson on how it's tricky to assume things about transactions before they reach the chain, I suppose
**\<sarang\>** Well, anything else of interest to discuss before closing the meeting?
**\<sarang\>** If anyone has thoughts or comments relating to the CLSAG reviewer notes, I'd be glad to hear them
**\<MalMen\>** just one quick question from someone that dont know much abouth CLSAG
**\<sarang\>** sure
**\<MalMen\>** CLSAG will not make possible second layer networkds (missing the word here) ?
**\<sarang\>** No, it doesn't introduce any new functionality toward that
**\<sarang\>** Its only purpose is to make signatures smaller and a bit faster
**\<sarang\>** Off-chain solutions are limited by a lack of scripting and ambiguity around useful things like non-interactive refunds, etc.
**\<MalMen\>** there is something that can possibility second layer in the future for monero yet or we still far from it ?
**\<sarang\>** Introducing such things is tricky (DLSAG is one attempt, but suffers from a linking problem)
**\<MalMen\>** ok, thank you for the heads up
**\<sarang\>** If you are willing to work through the technical language and definitions, the DLSAG paper has some very clever constructions: https://eprint.iacr.org/2019/595
**\<sarang\>** (disclaimer: I am a co-author on the paper, but did not come up with the original idea)
**\<MalMen\>** Ok, I will take a look
**\<sarang\>** It highlights how tricky it can be to enable swaps, payment channels, and the like, given the protocol and indistinguishability restrictions
**\<sarang\>** Oh, I should also add that the DLSAG paper \_was\_ accepted to the FC2020 conferences
**\<MalMen\>** oh, that is good
**\<MalMen\>** I believe that it will be almost impossible to make any "Non-Interactive Refund Transactions" (just took it from the paper) seemless as the other transactions
**\<sarang\>** DLSAG comes very close, but the linking problem is troublesome
**\<MalMen\>** peraphs we would come to a place where we need to choose if we want to acept anything like DLSAG knowing its less private but allow us to have hotswaps and some kind of lightning network working
**\<MalMen\>** or just keep with onechain transactions
**\<sarang\>** I would not expect broad support for such a tradeoff, but who knows
**\<sarang\>** And perhaps a new idea that \_does\_ solve the problem will arise at some point
**\<MalMen\>** we hope so
**\<sarang\>** Anyway, are there other topics of interest to bring up before closing the meeting?
**\<MalMen\>** well, thats all from me, thanks for your time sarang \*
**\<sarang\>** no problem
**\<sarang\>** OK, the meeting is over! Thanks to everyone for attending

159
_posts/2019-12-09-mrl-meeting.md Normal file
View File

@ -0,0 +1,159 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-12-09
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Let's go ahead and get started with GREETINGS
**\<kinghat\>** o/
**\<sgp\_\>** hello
**\<sarang\>** That's long enough!
**\<sarang\>** Let's move to ROUNDTABLE
**\<sarang\>** suraeNoether: what up with you
**\<suraeNoether\>** i'm terribly ill this morning, so my update will be very brief. my work in this past week has involved three incomplete tasks:
**\<suraeNoether\>** 1) CLSAG linkable anonymity proof required some thought. sarang and i have thought about it and we have a strategy to finish writing the proof. sarang: do you want to make the changes to our LA definition or do you want i should?
**\<sarang\>** suraeNoether: I have a writeup for LA in my notebook that I'm transcribing to TeX
**\<suraeNoether\>** and proof\* not just the definition
**\<sarang\>** it works just fine
**\<sarang\>** On that note
**\<sarang\>** Do you have any thoughts on linkability (not LA)
**\<sarang\>** I don't particularly like the Backes definition
**\<suraeNoether\>** uh one sec
**\<sarang\>** Triptych has a version of linkability+non-frameability that I like better
**\<suraeNoether\>** is there soemthing wrong with the definition we proposed initially?
**\<suraeNoether\>** iirc that one's from bender
**\<sarang\>** It's not formalized quite enough, in the apparent opinion of the reviewer
**\<sarang\>** I think it needs just minor work
**\<sarang\>** Triptych formalizes it a tad more IMO
**\<sarang\>** I can add that to the writeup if you like
**\<suraeNoether\>** well
**\<suraeNoether\>** for the sake of the audience, can you describe the 3 different definitions you want to consider? or 2, assuming you want to bail on backes'
**\<sarang\>** Backes requires the following for an LRS: completeness, linkable anonymity, linkability, non-frameability
**\<sarang\>** Right now we combine linkability and non-frameability with non-standard terminology
**\<sarang\>** Backes uses a particular linkability definition: can the adversary use `q` keys to generate `q+1` non-linking signatures?
**\<sarang\>** Where `q` is scaled via the security parameter
**\<sarang\>** I don't particularly like this definition over the "usual" one about producing two linking signatures, but I think it's important to frame the definition as a challenger-player interaction
**\<sarang\>** Our current method does this very informally
**\<sarang\>** I propose a combined linkability definition in my Triptych writeup that's a slight formalization of what CLSAG has now
**\<sarang\>** (it could easily be split into linkability and non-frameability)
**\<suraeNoether\>** hmmmm q scaling with the security parameter is the weird part to me: if the security parameter goes up, so does q... and so this means, for example, the adversary can't produce 3 signatures using 2 keys without some linking occurring. this feels \*weaker\* than the statement "can't produce two signatures using the same key without them being linked"
**\<sarang\>** Yeah, which is why I don't really like it
**\<sarang\>** didn't sit well with me
**\<suraeNoether\>** and we want the property with q=1 anyway to prevent double-spending
**\<sarang\>** So I am proposing not using the Backes definition, but simply formalizing what we have now, a la Triptych
**\<sarang\>** then it's more clear what the linkability player has access to in terms of keys etc.
**\<suraeNoether\>** okay, i'm going to read more deeply into that this afternoon
**\<sarang\>** IMO it's a pretty straightforward formalization
**\<sarang\>** doesn't affect much in practice
**\<suraeNoether\>** backes' definition with q=1 seems to me to imply backes' definition with greater q, but it's possible that it doesn't technically reduce the way it seems. i'll think more about it
**\<sarang\>** That definition doesn't make assumptions about linking tags being equal AFAICT
**\<sarang\>** Whereas ours does
**\<sarang\>** I think that's part of it
**\<sarang\>** Anyway, you were talking about work you'd been doing, before I barged in =p
**\<suraeNoether\>** moving along, my next incomplete task is reviewing triptych's security proofs more deeply, which dovetails with this :P
**\<sarang\>** Yeah, a nice tie-in
**\<suraeNoether\>** finally, i'm working on matching simulations today. i'm experiencing a data management and presentation issue, but i hope for the end of the day a nice graph displaying performance of Eve as a function of ring size and churn length
**\<sarang\>** Nice!
**\<suraeNoether\>** this will come along with a push to my repo with all the code used to generate that, and explanations so people can replicate it
**\<sarang\>** word
**\<suraeNoether\>** that's it, if i had presented in the other order then your "barging" would have been a great segue into \*your\* work for the week :P
**\<sarang\>** We can pretend otherwise
**\<sarang\>** I have completed a draft of the Triptych preprint, which is now in suraeNoether's hands
**\<sgp\_\>** suraeNoether: I'm really looking forward to that chart
**\<sarang\>** it includes my proposed linkability+non-frameability definition
**\<sarang\>** Figured out the CLSAG linkable anonymity definition, which is not as strong as Backes, but does the job IMO
**\<sarang\>** I've also been working with Aram from Zcoin on some related Groth proving system stuff
**\<sgp\_\>** what's the shortfall on the linkable anonymity definition, even if there's no practical difference?
**\<sarang\>** There will be a neat paper coming out from them on that shortly, which they graciously provided to me in advance
**\<sarang\>** sgp\_: Backes permits key corruption, which doesn't work with our DDH hardness assumption
**\<sarang\>** Instead, we assume the adversary can obtain key images
**\<sarang\>** And that the adversary can pack rings with their own malicious keys
**\<sgp\_\>** sarang: thanks
**\<sarang\>** (which you can assume are trivially corrupted)
**\<sarang\>** This is already stronger than the existing definition that was used
**\<sarang\>** Otherwise, I also wish to update the DLSAG paper (which will appear next year in conference proceedings) with the CLSAG security model, since they are structurally extremely similar
**\<sarang\>** So overall, a lot of tedious (but still interesting) stuff involving formal definitions and proofs
**\<sarang\>** When suraeNoether finishes his review of the Triptych preprint, it'll go to the IACR archive
**\<sarang\>** and presumably any CLSAG/DLSAG updates as well
**\<suraeNoether\>** hmm Backes' linkability definition is a puzzle i have very little intuition about: should it be harder or easier to present 2 signatures from the same key without linking the signatures than it should be to present 201 signatures from 200 different keys without any of them linking? \*taps chin\*
**\<sarang\>** The adversary picks which keys IIRC, right?
**\<suraeNoether\>** yeah, adversary can use KeyGen or any other way of selecting the verification keys
**\<suraeNoether\>** may not even know the secret key, so it's genuinely adversarial
**\<sarang\>** ya
**\<sarang\>** The adversarial generation isn't really a big deal, since soundness implies the adversary's choice of keys satisfy the verification equations
**\<sarang\>** and then you rely on the one-way mapping
**\<suraeNoether\>** actually, it's not clear; each verification key needs to be in \mathcal{VK}, and it's not specified where that comes from, i'm assuming from the challenger
**\<suraeNoether\>** in which case the adversary has to pick challenge keys to break linkability, it's not enough for the adversary to pack all rings with fake pubkeys
**\<sarang\>** Backes even notes that generating `q` such signatures is trivial, since you simply use separate keys
**\<sarang\>** Fake pubkeys should be acceptable
**\<sarang\>** since the adversary does all this offline, or otherwise generates the pubkeys in its own (seemingly) valid transactions
**\<sarang\>** The `q=1` case feels like some kind of targeted linking attack, where the general `q` case seems like a broader "hope for a collision somewhere" attack
**\<sarang\>** suraeNoether: thoughts?
**\<suraeNoether\>** nothing concrete. the way this definition is written feels very very counter-intuitive to the way you and i have discussed linkability in the past.
**\<sarang\>** Yeah, and I haven't seen it anywhere else
**\<sarang\>** Again, I don't feel any particular need to use it
**\<sarang\>** But getting the existing definition more formalized in a challenger-player sense seems wise
**\<suraeNoether\>** agreed
**\<sarang\>** roger
**\<sarang\>** OK, that's my update
**\<sarang\>** Does anyone else have interesting (or uninteresting) research to share?
**\<suraeNoether\>** ok, dude, i think i know the problem here
**\<suraeNoether\>** with that definition
**\<suraeNoether\>** or at least my problem with it
**\<sarang\>** Ooh, go on
**\<suraeNoether\>** linkability is a property that has a "correctness" component and a "soundness" component. to correctly link two things means to link them when they should be linked. to soundly link two things is to \*only\* link them when they should be linked
**\<suraeNoether\>** you called this positive and negative linkability at some point
**\<suraeNoether\>** i feel like this definition is mashing the two together
**\<suraeNoether\>** or attempting to
**\<suraeNoether\>** anyway, my thoughts don't go deeper than that yet
**\<sarang\>** Backes uses non-frameability to show that you can't make signatures that \_appear\_ to link without knowing/using the same key
**\<sarang\>** and linkability to mean that you can't make sigs with the same key(s) but different tag(s)
**\<sarang\>** The reviewer didn't like the CLSAG paper's use of positive/negative/soundness in linkability
**\<suraeNoether\>** hmm
**\<suraeNoether\>** okay, that's going to require more thought
**\<suraeNoether\>** anywya, now i'm done. :P
**\<sarang\>** A lot of this is simply getting the right terminology for the definition(s) of choice
**\<sarang\>** I happen to like using linkability to refer to both
**\<sarang\>** since that's typically what you want
**\<sarang\>** but it's two different concepts
**\<sarang\>** OK, we can move on to any other research
**\<sarang\>** or to the next topic, QUESTIONS
**\<suraeNoether\>** i have a pretty general observation
**\<suraeNoether\>** which may be relevant in terms of independent interest
**\<suraeNoether\>** a property like linkability applies to all ZK proofs. for example, our ring signatures are ZK proofs of knowledge of a secret key. but they are \*linkable\* proofs of knowledge, so that if the same witness data (keys) are used for two different proofs (signatures), then an observer can link them.
**\<suraeNoether\>** so just like ZK proofs have a property of correctness (if you know a witness, the proof is valid) and a property of soundness (if you don't know a witness, your proof is invalid), a linkable ZK proof is going to have a dual pair of notions for linkability
**\<suraeNoether\>** i bring this up so that the next version of snarks has an L floating around
**\<sarang\>** There's a related-ish property in sigma protocols, quasi-unique responses
**\<sarang\>** But that relates to responses to the verifier challenge
**\<suraeNoether\>** more reading to do :\
**\<sarang\>** There's probably a subtle relationship to (SHV)ZK
**\<sarang\>** and therefore witness indistinguishability
**\<sarang\>** (which follows from SHVZK)
**\<suraeNoether\>** anyway
**\<sarang\>** Normally, providing two proofs should not reveal distinguishing information about the witnesses
**\<suraeNoether\>** right
**\<sarang\>** Hopefully you will enjoy the Triptych paper, which builds a linkable construction on top of a sigma protocol :)
**\<suraeNoether\>** i enjoyed it the last time i read it, and the tiem before that. it takes awhile to digest :P
**\<suraeNoether\>** ok, i gotta bounce, i'm not feeling well; my list of 3 unfinished tasks is also my list of action items today
**\<sarang\>** roger
**\<sarang\>** My ACTION ITEMS are getting these new definitions and proofs typeset and finalized, determining their DLSAG applicability, a few other organizational issues on the CLSAG paper to prepare it for resubmission, and getting Triptych submitted on review
**\<sarang\>** Any other final thoughts, comments, or questions before this meeting ends?
**\<moneromooo\>** I have an unrelated question.
**\<sarang\>** ?
**\<moneromooo\>** I was wondering whether atomic swaps between two cryptonotes with hte same curve etc (ie, not the general case) is possible now.
**\<moneromooo\>** Well, assuming the tooling was there of course, which it isn't.
**\<moneromooo\>** In theory I mean.
**\<sarang\>** I don't know of a good way that retains indistinguishability as well as DLSAG does, and that still has the tracing issue
**\<sarang\>** If you were willing to accept and mitigate the tracing issue, then its method could do it
**\<sarang\>** its = DLSAG's
**\<moneromooo\>** What is the tracing issue already ?
**\<sarang\>** The fixed basepoint used for dual-address key images allows determination of unwanted signature linking
**\<sarang\>** It isn't clear how to do a DLSAG-type construction with the variable-basepoint key images used currently
**\<sarang\>** I should more precisely say, the use of a fixed basepoint and having output private keys used as the corresponding key image discrete log (this doesn't exist in more recent constructions that use a fixed basepoint but in a different way)
**\<sarang\>** Oh, suraeNoether: do you think it's useful in the LA definition to include the linking tag oracle separately from the signature oracle?
**\<sarang\>** The player can get the linking tag oracle result simply by querying the signature oracle on a public key by using a random ring and message (and ignoring everything but the returned linking tag)
**\<sarang\>** Having a separate oracle only really serves to make it clear that the player doesn't necessarily need to convince a user to sign messages, but can obtain linking tags otherwise
**\<sarang\>** (although in this security model, it can do both)

175
_posts/2019-12-16-mrl-meeting.md Normal file
View File

@ -0,0 +1,175 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-12-16
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<suraeNoether\>** howdy!
**\<suraeNoether\>** suppose we should move onto the roundtable?
**\<sarang\>** Might as well
**\<sarang\>** Who shall begin?
**\<suraeNoether\>** I'm going to ping isthmus
**\<suraeNoether\>** in the hopes that he can describe a bit of the data science work he's currently doing
**\<Isthmus\>** n3ptune and I have been looking at block rewards
**\<Isthmus\>** Lots of funky stuff going on
**\<sarang\>** How so?
**\<Isthmus\>** Isthmus is digging up figures
**\<Isthmus\>** Here's a bad figure, and I'll try to have a nicer one by the end of the meeting
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/f9F4XDd3/image.png
**\<Isthmus\>** x-axis is block height
**\<Isthmus\>** y-axis is the total reward claimed by the miner
**\<Isthmus\>** (fresh + fees)
**\<Isthmus\>** The trend is basically our emission curve (the bottom of the traces)
**\<Isthmus\>** The data points above the trend are miners who made good blocks with fees on top of reward
**\<suraeNoether\>** exponential decay shape of the graph comes from our emission curve (fees are related to block reward). is the piecewise break from bulletproofs?
**\<Isthmus\>** The anomalies below the line are what's interesting
**\<Isthmus\>** There's a few distinct events that happened
**\<Isthmus\>** For each, we can tell a few things:
**\<Isthmus\>** Exactly which blocks were mined by that miner/pool/software
**\<Isthmus\>** (linkability)
**\<Isthmus\>** And exactly how long it took them to notice that they were making suboptimal blocks, and fix the software
**\<Isthmus\>** You can tell a bit more by adding size as the color
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/HUoctx7I/image.png
**\<Isthmus\>** Scale is blue to yellow
**\<Isthmus\>** So there I've zoomed into a small section
**\<Isthmus\>** Looking at the band from 1225000 to 1275000ish
**\<Isthmus\>** It looks like the blocks claiming \*less\* reward than empty blocks are about the same size as those produced by others
**\<suraeNoether\>** that graph is gorgeous bro
**\<Isthmus\>** thx :- )
**\<sarang\>** Odd behavior
**\<sarang\>** The definition of suboptimal, you might say...
**\<Isthmus\>** Yeah, because their sizes are about the same as the surrounding blocks, here are two guesses for what might be happening
**\<Isthmus\>** Maybe other miners are making high-fee big blocks, and the ones below the trend are the suckers that make big blocks after the mempool has been tapped out for high-fee txns
**\<Isthmus\>** But based on how bounded the second (anomalous) trend is, I think it might just be a software bug?
**\<Isthmus\>** I just discovered this like 20 hours ago, so I haven't done full exploration
**\<Isthmus\>** I'll be able to drill down into the blocks and actually figure out what was going on
**\<Isthmus\>** (that's about where it's at right now)
**\<sarang\>** It's really interesting to see it mapped out so clearly
**\<suraeNoether\>** thanks so much, isthmus; it seems to me like i've read at least one paper about purposely claiming smaller rewards for a variety of game-theoretic reasons...
**\<suraeNoether\>** i'm going to try to dig up at least one of htem
**\<suraeNoether\>** i have so many questions about this
**\<sarang\>** It would be good to know which particular software (if it's specific) leads to this, due to how common it appears to be
**\<sarang\>** suraeNoether: your roundtable?
**\<suraeNoether\>** yeah, sure: Matching. I \*think\* i'm \*one\* bug away from getting all the data i want. and I'm talking to Insight Data Science to throw a fellow at the simulation results to help me come up with best-practices recommendation
**\<suraeNoether\>** my current bug is silly and strange, in that i'm not adding the number of nodes and edges my software is expecting. initially i thought this was a problem with computing the number of available ring members or something like that, but i'm still trying to figure it out
**\<sarang\>** Do you have code ready that can reproduce it?
**\<suraeNoether\>** it occurs in a random test in testSimulator.py, not any of my deterministic tests
**\<suraeNoether\>** so i'm still hunting down exactly the conditions that lead to the bug, and attempting to isolate it as a new unit test
**\<suraeNoether\>** the graph theoretic component is working perfectly, the analysis component exploring parameter space is working perfectly, but the simulator keeps hitting this snag and then we're off to the races
**\<endogenic\>** oops, here
**\<suraeNoether\>** welcome
**\<endogenic\>** suraeNoether: you dont think V could make all those masks by himself even in 20 years though?
**\<sarang\>** suraeNoether: is the currently-pushed code the version you're working with?
**\<suraeNoether\>** yes, the commit i pushed this morning
**\<suraeNoether\>** to matching-buttercup branch
**\<suraeNoether\>** so, someone brought up by sidechannel the question about whether i should re-implement the sims in rust in the hopes that the improved explicit references of rust would help find the errors
**\<sarang\>** Do you suspect that could be the origin of the errors?
**\<suraeNoether\>** i think refactoring the whole codebase is a last-ditch effort for finding the bugs, though
**\<sarang\>** If they're simply algorithmic mistakes, switching to Rust might not do anything
**\<suraeNoether\>** no; i literally think i'm merely predicting the number of nodes and edges incorrectly based on the total nodeset as opposed to only the nodes that can be spent.
**\<endogenic\>** have you tried log statements?
**\<endogenic\>** secret weapon
**\<suraeNoether\>** and i'm in the midst of tracking that down
**\<Isthmus\>** Could you tweak the simulation to be 3 blocks long, 2 transactions per block, with spend pattern & ring member selection algorithm = pull from previous block
**\<Isthmus\>** Would the issue persist and be easy to spot by eye?
**\<sarang\>** endogenic: your suggestion reminded me of https://xkcd.com/451/ =p
**\<endogenic\>** except that i am
**\<endogenic\>** :P
**\<sarang\>** Nono, the statement about logs!
**\<sarang\>** Sorry, digression
**\<suraeNoether\>** isthmus unfortunately i believe the problem may be in the ring selection algorithm i have written (which is only uniform at this point), so that would reduce the problem away
**\<suraeNoether\>** but i'm attempting something similar next
**\<suraeNoether\>** right now, debugger is my friend
**\<suraeNoether\>** sarang, how about you?
**\<endogenic\>** log statements are nice because you can let the whole thing run
**\<sarang\>** Several things to mention
**\<endogenic\>** debugger is also nice.
**\<sarang\>** I modified the linkability and non-frameability definitions in Triptych, and would like to see if they can be directly used in CLSAG as well
**\<sarang\>** I've come around on Backes' definition of linkability
**\<sarang\>** I updated the CLSAG linkable anonymity definition, as well as its proof
**\<sarang\>** Reviewed a paper by the Zcoin folks on hierarchical Groth commitment proofs
**\<sarang\>** Looked over some changes that Zcoin made to fix a problem they had relating to Groth proofs (doesn't apply to Triptych)
**\<sarang\>** Worked out some example code for doing inversion via an MPC for use in computing certain linking tag constructions
**\<sarang\>** and wrote out some simple draft MPC ideas for RCT3 and Triptych, which for now assume honest-but-curious players
**\<suraeNoether\>** nice!
**\<sarang\>** The good news on MPC is that it's certainly possible to collaboratively compute the inverse-based key images used in those proving systems
**\<sarang\>** The bad news is it requires something akin to Paillier encryption, which leads to some computational overhead
**\<suraeNoether\>** hmmm are you looking into the MPC stuff for linking tag constructions due to the constructions and usage of linking tags in Triptych?
**\<sarang\>** (note that my example code should \_not\_ be taken to be a secure Paillier implementation)
**\<sarang\>** Yep, the MPC is to handle linking tags in Triptych, RCT3, and Omniring
**\<sarang\>** Even though Omniring can use traditional linking tags, even that construction still requires an underlying inversion
**\<sarang\>** There are also affine quantities to compute, but those are understood
**\<suraeNoether\>** refresh my memory: which, if any, of those 3 require self-sends?
**\<sarang\>** None of them
**\<sarang\>** DLSAG and Lelantus would require this
**\<endogenic\>** LELANTUS
**\<suraeNoether\>** okay, so what, in your heart of hearts, are you hoping for from linking tags?
**\<sarang\>** The problem, previously, was that it was not clear how to enable multisig support when the linking tags require a secret key inversion
**\<suraeNoether\>** aaaaah
**\<sarang\>** Now that there's an understood MPC to compute this, it means multisig support is feasible
**\<suraeNoether\>** gotcha gotcha
**\<suraeNoether\>** you had questions about multisig for me
**\<sarang\>** The downside to the MPC is that Paillier can't take advantage of the efficient curve libraries we all know and love
**\<suraeNoether\>** we can address them now or after the meeting if you like
**\<silur\>** hoi sorry for being late
**\<Isthmus\>** holla
**\<suraeNoether\>** long time no see silur
**\<endogenic\>** whatup silur
**\<sarang\>** Paillier requires RSA modulus stuff (but there aren't issues with trusted setup etc.)
**\<sarang\>** Encryption and decryption require exponentiation with variable modulus
**\<sarang\>** So computationally-constrained devices would need to able to support this
**\<sarang\>** s/to able/to be able
**\<suraeNoether\>** so are we hoping for an MPC to compute inversion-based key images... such that the MPC is more consistent with the development history of monero/cryptonote? ie based on the DL setting in Ed25519 instead of RSA?
**\<suraeNoether\>** or at least, one of the items on our "wish we had" list?
**\<sarang\>** Such a thing would be great, but as you pointed out, getting the required homomorphicity would imply a DL break, or some such thing
**\<silur\>** can you elaborate on "inversion based key images"?
**\<silur\>** or shall I just review it from the log?
**\<sarang\>** Key images / linking tags in newer proving systems use the form `(1/x)\*U`
**\<suraeNoether\>** rather than x\*H(X)
**\<suraeNoether\>** U is fixed, yes?
**\<sarang\>** Here the division is an inverse, `x` is the secret key, and `U` is either globally fixed or depends on the proof statement
**\<sarang\>** but it's public
**\<suraeNoether\>** uhmmmm wait a moment:
**\<sarang\>** It's globally fixed in the more efficient versions of the proving systems
**\<suraeNoether\>** my comment had to do with an efficient group-to-scalar map that had any sort of homomorphicity built in
**\<suraeNoether\>** oh oh oh
**\<suraeNoether\>** i get what you are saying
**\<sarang\>** For context: https://github.com/SarangNoether/skunkworks/tree/inverse-mpc
**\<sarang\>** The inverse.py script shows how the process works, and the markdown documents describe one possible use for RCT3/Triptych (again, with many assumptions on the players)
**\<sarang\>** The encryption homomorphicity is important for the MPC method that Gennaro and Goldfeder introduce
**\<suraeNoether\>** so most generally, each person has a secret x\_i and there is a function f such that you want to compute f(x\_1, ..., x\_n)\*U with some friends. you were using f(x\_1, ..., x\_n) = 1/sum(x\_i) ?
**\<suraeNoether\>** you know what: let's talk about this after the meeting
**\<sarang\>** Yeah, better for after meeting
**\<suraeNoether\>** so, isthmus, myself, and sarang have all brought the room up to speed. does anyone else want to talk about any monero-related research they are doing?
**\<silur\>** can't we somehow exploit the bootle inner-product encryption with a killian randomization here somehow? the killian randomization preserves linear combinations so everything before multiplying with U is the same
**\<silur\>** but individual inputs are useless
**\<silur\>** and at the last step the same inner-product for the last vector reduces into a Z\_p element?
**\<sarang\>** I don't see how to directly apply that to the share derivation in Gennaro
**\<sarang\>** The multiplicative-share to additive-share method, I mean
**\<sarang\>** (which is the point of their Paillier-based protocol)
**\<silur\>** Oh the Genaroo-Goldfeder method IS a hard requirement
**\<silur\>** then we can't inded :)
**\<silur\>** I wasn't aware it's a must-have
**\<sarang\>** Well, we don't \_need\_ to use Gennaro-Goldfeder
**\<sarang\>** but it seems reasonably efficient and useful if you can accept the homomorphicity requirement
**\<sarang\>** In the interest of time, let's move to ACTION ITEMS
**\<sarang\>** Mine are to continue work on the MPC stuff, get CLSAG definitions ported as necessary (would like to discuss with suraeNoether as well), and get final review on the Triptych draft to get posted to IACR
**\<silur\>** triptych? O.o
**\<sarang\>** ?
**\<suraeNoether\>** mine is to hunt down and kill my final bug, work on the churn report, review the triptych draft (finally) and continue chatting with isthmus about getting a data science fellow working with me on matching/churn
**\<silur\>** I was not familiar with that, will look into
**\<suraeNoether\>** it's a paper sarang is presently writing
**\<silur\>** too much meetings missed :D
**\<sarang\>** silur: Triptych is a linkable ring signature construction based on Groth 1-of-many commitment proofs
\<3
**\<sarang\>** Preprint draft forthcoming
**\<sarang\>** There's a super-efficient version for which I can't reduce soundness to a known hardness assumption
**\<sarang\>** If you want to take a look silur, most welcome
**\<sarang\>** The less-efficient version does reduce nicely
**\<silur\>** yea I'd be more than happy to look into
**\<sarang\>** neat
**\<sarang\>** OK, I suppose we can formally adjourn and continue discussions as desired

88
_posts/2019-12-23-mrl-meeting.md Normal file
View File

@ -0,0 +1,88 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-12-23
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<suraeNoether\>** we'll start with GREETINGS. hiya!
**\<suraeNoether\>** mele kalikimaka, etc
**\<suraeNoether\>** let's move along to the ROUNTABLE
**\<suraeNoether\>** i know isthmus has been up to some interesting stuff with block sizes and fees, but he doesn't appear to be here. sarang, as usual, has been busy. you want to start, sarang?
**\<sarang\>** Sure
**\<sarang\>** I redid the CLSAG linkability and non-frameability definitions, theorems, and proofs
**\<sarang\>** and then did a major reorganization of the preprint for clarity and style/format
**\<sarang\>** It's ready for suraeNoether's review, and then posting
**\<sarang\>** Additionally, the Triptych preprint draft is ready for suraeNoether to review as well
**\<sarang\>** and then it can be posted
**\<sarang\>** good times
**\<suraeNoether\>** word, word
**\<suraeNoether\>** does anyone have any questions for sarang?
**\<sarang\>** Apparently not!
**\<mikerah[m]\>** I have a question for the MRL team regarding L2 scaling for Monero: Are there any scalability solutions currently deployed on Monero? If not, why not?
**\<sarang\>** I assume you mean off-chain?
**\<mikerah[m]\>** I do mean off-chain
**\<suraeNoether\>** not currently deployed. DLSAG and thring signatures are two fundamental pieces of off-chain scaling
**\<suraeNoether\>** DLSAG is currently... uhm... accepted for publication? did iirc?
**\<sarang\>** Accepted to FC2020
**\<suraeNoether\>** that's a spicy meatball, yes
**\<sarang\>** Awaiting some likely rewrites for definitions
**\<sarang\>** Downside is that indistinguishable refund-compatible transactions don't play nicely with key image requirements
**\<suraeNoether\>** mikerah[m]: requires some more research into how to ensure consistency in key image use
**\<suraeNoether\>** ^
**\<mikerah[m]\>** So, the current state of the art for monero is DLSAG, thring signatures and the Tari sidechain?
**\<suraeNoether\>** tari sidechain is independent
**\<sarang\>** Tari is a separate project
**\<suraeNoether\>** but built on top of monero, from my understanding
**\<sarang\>** No
**\<suraeNoether\>** er... sidechain
**\<suraeNoether\>** not \*on top of\*
**\<sarang\>** IIRC they're doing a MW-based implementation
**\<suraeNoether\>** oh
**\<suraeNoether\>** news to me \*shrug\*
**\<sarang\>** Hoping to do merge mining
**\<sarang\>** But I have not been following their recent work
**\<suraeNoether\>** ah
\<suraeNoether "news to me \*shrug\*"\> Me too. I guess the association to fluffypony made me assume that it was Monero related
**\<suraeNoether\>** well, for my part of the roundtable, my work this week was to start copy-editing triptych and clsag, and to work on my matching simulations. I just made a push this morning... https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
**\<suraeNoether\>** anyone can run tracing.py and it will create a data folder, stash human-readable simulated monero transcripts inside...
**\<sarang\>** mikerah[m]: to be clear, DLSAG is not deployed anywhere
\<sarang "mikerah: to be clear, DLSAG is n"\> Thanks for the clarification.
**\<suraeNoether\>** these transcripts say things like "Alice sends key NODE\_ID with ring members RING\_MEMBERS, authorizing the creation of outputs NEW\_NODE\_ID owned by Bob." It's a "ground truth" ledger.
**\<suraeNoether\>** these transcripts also contain the accusations that Eve makes. "Eve thinks ring signature NODE\_ID belongs to Bob. In actuality, it belongs to Alice." sort of thing
**\<suraeNoether\>** in theory, anyone can fire up tracing.py, tweak the parameters inside, and see the simulated ledger
**\<suraeNoether\>** the ledger is working just fine
**\<sarang\>** nice
**\<suraeNoether\>** unfortunately, but also fortunately, once i put these transcripts into human readable format it became immediately obvious there was a problem with my Eve
**\<suraeNoether\>** she is allegedly granted knowledge of her part of the graph, but she doesn't incorporate that knowledge into her matching solution appropriately.
**\<suraeNoether\>** so the previous numbers i shared in here, which i took care to explain where provisional, are lower than what we can expect from a realistic eve.
**\<suraeNoether\>** these problems were not being caught by my unit tests
**\<sarang\>** What needs to be done to properly account for that?
**\<suraeNoether\>** the run\_experiment function in tracing.py builds a dictionary called eve\_ownership, which is not utilized correctly, and allegedly deletes spurious ring members, but i have some evidence that this isn't being done correctly either
**\<suraeNoether\>** what really needs to happen is that eve builds a sub-ledger by deleting all her known information, so that it's purely "uknown" data to Eve, before playing the matching game
**\<suraeNoether\>** that, together with reporting her known information, would fix the problem
**\<suraeNoether\>** since i have CLSAG and triptych to take care of, and since so much of this code is human readable at this point, i'm putting this project down until the new year
**\<suraeNoether\>** especially since "the problem" is easily explainable and I can point to where it's occuring
**\<suraeNoether\>** but, for example, if anyone wants to just simulate a ledger using different stochastic matrices or spendtime distributions, they can tweak the parameters inside of tracing.py and generate as many ledgers as they like
**\<suraeNoether\>** and now you can read them like a story. the world's least interesting procedurally generated story.
**\<suraeNoether\>** i'll be unavailable for the next 72 hours or so (family is coming into town) but i have CLSAG and triptych printed; i'm about 1/3 of the way marking up my copy of triptych
**\<suraeNoether\>** that's all i have today. does anyone have any questions for me about that, or other questions on anything research-y?
**\<sarang\>** When you're done with Triptych, will suggestions be added as Overleaf review comments?
**\<suraeNoether\>** i was going to add some as comments and send the rest as an email to you
**\<sarang\>** Great, thanks
**\<sarang\>** You have the line-numbered version?
**\<suraeNoether\>** yep
**\<suraeNoether\>** okay, let's move onto ACTION ITEMS
**\<suraeNoether\>** sarang?
**\<sarang\>** I'll be addressing some multisig-related MPC stuff for RCT3 and Omniring
**\<sarang\>** Then working on any necessary updates for CLSAG and/or Triptych based on review
**\<sarang\>** and then getting both papers posted to IACR
**\<suraeNoether\>** Helping sarang finish triptych and clsag; if i finish this before end-of-year, i'll go back to matching
**\<sarang\>** Oh, a longer-term action item is to backport the CLSAG security model changes to DLSAG, but that's likely not this week
**\<sarang\>** I don't recall the DLSAG reviewers mentioning it, but it should be done anyway
**\<suraeNoether\>** allrighty
**\<suraeNoether\>** unless anyone has any final quesitons
**\<suraeNoether\>** i think we can adjourn
**\<sarang\>** Happy Festivus!

219
_posts/2019-12-30-mrl-meeting.md Normal file
View File

@ -0,0 +1,219 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2019-12-30
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<suraeNoether\>** welcome everyone, to the last MRL research meeting of the year
**\<suraeNoether\>** if i had thought about it, i'd have something more in-depth prepared but it just occurred to me ;P
**\<suraeNoether\>** let's start with 1) GREETINGS
**\<endogenic\>** o/
**\<sarang\>** hi
**\<suraeNoether\>** good and you, oh not so bad
**\<suraeNoether\>** isthmus was here mere moments ago
**\<Isthmus\>** Kind of. Splitting headache. Looking at screen intermittently.
**\<sarang\>** yikes
**\<endogenic\>** :(
**\<Isthmus\>** C'est la vie.
**\<suraeNoether\>** okay, well; go away isthmus and come back when you're healthy
**\<suraeNoether\>** you'll get us all sick with headaches left and right
**\<endogenic\>** i have a headache now
**\<Isthmus\>** See, we should just ban headaches at the protocol level
**\<Isthmus\>** Not just in the wallet.
**\<suraeNoether\>** no your headache now
**\<suraeNoether\>** before we move onto 2) ROUNDTABLE I would like to bring up a single administrative issue
**\<suraeNoether\>** i would like to propose that we consider switching meeting times; we selected 17 UTC mondays essentially at random about 2 years ago
**\<sarang\>** ?
**\<sarang\>** What's a preferred time?
**\<suraeNoether\>** nowadays, not all of our participants easily are able to attend that time, so often it's just sarang and i
**\<suraeNoether\>** so while i don't have a lot of time constraints, i wanted to hear from folks like isthmus who oftentimes have meetings at around the same time
**\<suraeNoether\>** and open the room up for general discussion about timing for meetings
**\<Isthmus\>** ty
**\<suraeNoether\>** i know this is boring, but it's been on my mind for more than a month now
**\<sarang\>** Suggestions on a better time?
**\<endogenic\>** an hr fro
**\<Isthmus\>** I'm normally on Pacific time so Monday 1700 UTC is early and right when I'm getting swamped at the office
**\<endogenic\>** m now?
**\<endogenic\>** nm
**\<Isthmus\>** I'm just here now cuz on holiday & EST
**\<sarang\>** How about 18:00 or 19:00 UTC?
**\<endogenic\>** Weds?
**\<Isthmus\>** Weds at 18 or 19 would be better
**\<Isthmus\>** In that case, I think I could block it on my work calendar as a recurring event
**\<sarang\>** We could always try a new datetime out and see how it goes
**\<suraeNoether\>** i second wednesdays at 18-19 UTC provisionally for the first month of the year just to see how it works out re: participation
**\<sarang\>** I make sure the topic bar shows the meeting datetime
**\<Isthmus\>** +1
**\<sarang\>** OK, Wednesday at 18:00 UTC it is
**\<Isthmus\>** Thanks! Will be very helpful for me.
**\<suraeNoether\>** okay, neato burrito
**\<suraeNoether\>** onto 2) ROUNDTABLE
**\<suraeNoether\>** since the holidays were last week, maybe we can make this not just a "here's what I did last week" thing but also a "here's what we did this year" thing, but that could end up being a... surprisingly long list
**\<suraeNoether\>** but we don't have to go in-depth
**\<suraeNoether\>** sarang or isthmus, do you guys want to begin? wait, no, isthmus: go away and treat your headache
**\<sarang\>** I finished up a draft MPC for the aggregated version of RCT3 this past week
**\<sarang\>** And am currently in the weeds with some Omniring stuff that has been puzzling
**\<sarang\>** Additionally, my funding request is open: https://ccs.getmonero.org/proposals/sarang-2020-q1.html
**\<suraeNoether\>** i strongly recommend that everyone donate to sarang's funding request
**\<suraeNoether\>** well, i mean, whatever you are comfortable with
**\<sarang\>** and I'm on pins and needles for any comments from suraeNoether on CLSAG or Triptych preprint updates
**\<suraeNoether\>** what i mean to say is: this is a valuable request, and if you have been considering donating to the CCS but don't know where your money will have a big impact, sarang's fund is a high priority ticket imho
**\<sarang\>** Much appreciation for all the support
**\<sarang\>** I'm eager to see what the next year holds in the research space, particularly relating to transaction protocols
**\<Isthmus\>** Yea, what's our research theme for 2020
**\<Isthmus\>** I'll obviously continue to be a huge PITA about information leaks
**\<sarang\>** yes plz
**\<sarang\>** "2020: zero knowledge, infinite heart"?
**\<Isthmus\>** Ring size 2020?
**\<Isthmus\>** Oh wait, it's not a prime number
**\<sarang\>** People are going to think there's a technical reason for having prime-number ring sizes :/
**\<sarang\>** Interestingly, for some protocols, you specifically \_can't\_ have a prime number size!
**\<suraeNoether\>** for any merkle-tree based approach, you have to stick with powers of 2
**\<suraeNoether\>** for 2020, a few things i'd like would be a formal protocol specification for a tryptich-based protocol, using ristretto, going down to the nitty gritty details of optimized arithmetic, tor integration, etc
**\<suraeNoether\>** thing is, i think we are eventually going to need to abandon the DL setting for efficiency and security reasons; either switching to multilinear pairings may be necessary for efficiency, but still boils down to computational security. on the other hand, switching to other hardness assumptions like RLWE, which are believed to be quantum-secure, is an area of active research. that assumption also has a
**\<suraeNoether\>** very different profile for use in cryptocurrencies because key sizes and signature verification speeds are very different in the new setting
**\<suraeNoether\>** my roundtable contribution from this past week: i got flu-like symptoms after xmas, so all I could do was sit around and be grumpy, so I ... copy-edited triptych and clsag
**\<suraeNoether\>** (best thing to do when grumpy is to grade papers???)
**\<sarang\>** Looking forward to your notes on those
**\<suraeNoether\>** should be before 3PM today
**\<sarang\>** Hooray!
**\<sarang\>** It's a Festivus miracle!
**\<suraeNoether\>** i'll be switching back to matching simulation stuff literally next year
**\<suraeNoether\>** festivus miracles involve being able to use the aluminum pole on your grievances
**\<endogenic\>** i dont get that reference but i will google
**\<sarang\>** I'll be continuing a deep-dive into some Omniring stuff this week, to determine if an issue I ran into presents a problem with any of the proofs
**\<Isthmus\>** My roundtable is still plotting, but should be rendered shortly
**\<suraeNoether\>** after recovering from the flu, or whatever i had, though, i have to say: i feel like a million bucks and i'm super excited to finish off triptych today
**\<suraeNoether\>** endo and isthmus and sarang can all attest to the number of times per year i say i feel like a million bucks
**\<Isthmus\>** :- )
**\<endogenic\>** 1/4 times per year so far
**\<suraeNoether\>** when the moon hits your eye like a big pizza pie, thatsa N=1
**\<Isthmus\>** Ah, here we go
**\<endogenic\>** i feel for the transcription translators who do these logs
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/ntGPLKhz/image.png
**\<Isthmus\>** ^ non-coinbase TXNs as of late
**\<suraeNoether\>** oh my fkn god
**\<Isthmus\>** I zoomed in on lower values there, there are some absurd outliers
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/Uz5uJDlS/image.png
**\<suraeNoether\>** so i like the idea of having an adjustable unlock time for smart contract reasons. ...
**\<endogenic\>** for m'kids
**\<suraeNoether\>** hey, sarang: think the range proof technique for the trigger block height in DLSAG could be janked around to hide \*all unlock times\*?
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/xS32XCWP/image.png
**\<Isthmus\>** ^ All from the last few months
**\<Isthmus\>** Excluding the giant ones
**\<sarang\>** I believe it could
**\<Isthmus\>** Apparently unlock\_time supports both unix timestamps and height... There are 13 transactions that used UNIX time and the rest are height-based
**\<sarang\>** unix timestamps? did not know that
**\<Isthmus\>** There's one transaction whose outputs will unlock in the year 46000, lol
**\<suraeNoether\>** hmmmm
**\<suraeNoether\>** i can't think of a good reason to allow unix timestamps
**\<endogenic\>** who uses unlock time currently?
**\<suraeNoether\>** costs of hiding all unlock times is a new range proof, but that can be batched with bulletproofs... and variable unlock times are desirable for smart contracting...
**\<Isthmus\>** @endogenic apparently 8 different sets of people, and they all use it differently
**\<Isthmus\>** xD
**\<endogenic\>** lol
**\<suraeNoether\>** the DLSAG connection is strong with this
**\<endogenic\>** surae is one of them
**\<Isthmus\>** https://xmrchain.net/search?value=2c2762d8817ea4d1cb667752698f2ff7597a051d433043776945669043d908b5
**\<Isthmus\>** "unlock\_time": 1420722551128,
**\<suraeNoether\>** i'm \*really\* bad at monero
**\<sarang\>** Not only batched, but aggregated for logarithmic size benefits
**\<suraeNoether\>** can anyone think of a good reason to keep unlock time in plaintext?
**\<endogenic\>** auditability
**\<sarang\>** It's also smaller
**\<endogenic\>** forgive me monero gods
**\<sarang\>** Otherwise you have to put it into a commitment
**\<Isthmus\>** What is the point of unlock time?
**\<Isthmus\>** Serious question.
**\<Isthmus\>** I need to understand the intended use cases to figure out how we should handle it
**\<moneromooo\>** A reason to use UNIX timestamps is to not depend on block time changes.
**\<endogenic\>** (unreclaimable) vesting period; force-hodl
**\<sarang\>** that's a fair point
**\<Isthmus\>** If the unlock time is plaintext, then how can the hodl be forced?
**\<Isthmus\>** Erm
**\<Isthmus\>** \*if is encrypted, how enforced
**\<sarang\>** There's a range proof included, showing that the current block height exceeds the committed lock period
**\<moneromooo\>** Can't you easily brute force it ?
**\<sarang\>** The goal is to reduce heuristics around expected spends
**\<suraeNoether\>** endogenic: auditability in this case would be the same security/threat model as our confidential transactions, so that wouldn't reduce our auditability... not to mention, for the folks in the audience, monero balances are guaranteed by the unforgeability property of our signatures; if anyone is capable of cheating the monero system with our confidential transactions, they can also forge signatures with
**\<suraeNoether\>** elliptic curves, which breaks a lot more than just monero.
**\<Isthmus\>** I second mooo's question
**\<sarang\>** moneromooo: the lock time is in a Pedersen commitment
**\<endogenic\>** suraeNoether: was joke :)
**\<sarang\>** which is perfectly hiding
**\<suraeNoether\>** isthmus: early cross-chain swap models require unlock times to elapse to use SPV
**\<endogenic\>** but how does recipient easily verify time til unlock isnt ridiculous through only range proof?
**\<suraeNoether\>** endogenic: it's a joke, but like a making a math joke in a math class, it's always followed up by a serious discussion of why it's funny. #mathteacherlife
**\<sarang\>** That needs to be communicated to the recipient endogenic
**\<endogenic\>** suraeNoether: one-up'd
**\<sarang\>** The range proof is included at spend time
**\<sarang\>** not at output generation time
**\<Isthmus\>** Ohhhh
**\<moneromooo\>** So a verifier gets a yes/no, and at some point a no becomes a yes.
**\<suraeNoether\>** moneromooo: can't brute force due to sarang's observation about perfect hiding
**\<moneromooo\>** Right ?
**\<sarang\>** not quite
**\<endogenic\>** sarang: out of band?
**\<sarang\>** When you generate the output, you specify an unlock time commitment, and transfer the plaintext version to the recipient either encrypted or out of band
**\<moneromooo\>** I mean, from a verifier's perpective, they will need to either reject a spend, or ok it.
**\<Isthmus\>** -\_-
**\<sarang\>** When the output is spent, a range proof is generated using a particular time offset against the commitment, to show the lock time has been exceeded relative to the current block height
**\<moneromooo\>** When they stop getting a verification failure, there's no other reason (currently) other than that, no ?
**\<sarang\>** The method is a bit unintuitive until you write it out, TBH
**\<moneromooo\>** Oh. I see. Thanks.
**\<sarang\>** but it's included in the DLSAG preprint
**\<moneromooo\>** er.
**\<suraeNoether\>** moneromooo: you wouldn't be able to construct a range proof on [0, ..., N] with time offset -3
**\<suraeNoether\>** it wouldn't be a valid proof
**\<suraeNoether\>** the trickiness is in realizing how the DLSAG construction actually captures the offset
**\<moneromooo\>** So you include the block hash at currnet block then ?
**\<suraeNoether\>** let me pull it up
**\<sarang\>** But moneromooo, it's important to note that you can't simply brute-force the verification at each successive block until it succeeds
**\<suraeNoether\>** for the audience members: https://eprint.iacr.org/2019/595
**\<sarang\>** The signer generates the proof once, at spend time
**\<moneromooo\>** OK, that's good enough for me. Thanks.
**\<sarang\>** There's some subtlety in choosing the offsets and such, to reduce heuristics, but the method makes sense
**\<suraeNoether\>** bottom of page 10, left hand column
**\<sarang\>** Cost would be replacing plaintext lock times with commitments, and extending bulletproofs to include the lock proof
**\<suraeNoether\>** this would be the first step toward "private" smart contracts that depend on dev-selected unlock times
**\<suraeNoether\>** in a sense it's more basic than DLSAG, almost an independent component used in DLSAG. it should have occurred to me before that it was basically it's own construction...
**\<sarang\>** It is an independent component... you can do DLSAG with plaintext trigger heights
**\<suraeNoether\>** \*nod\*
**\<sarang\>** but it's probably a bad idea to do so
**\<endogenic\>** i have to step out y'all
**\<suraeNoether\>** which means it has its own stand-alone security definitions. in this case, the definitions rely on some adversarially generated blockchain, yadda yadda
**\<Isthmus\>** I think that would be worthwhile to switch to unlock time commitments... Right now an adversary can partition (/fingerprint) the blockchain into ~20 different anonymity puddles based on unlock time alone.
**\<Isthmus\>** When I first plotted it I was expecting a few Easter eggs, not heuristic info bleeding everywhere.
**\<endogenic\>** keep killin it Isthmus
**\<suraeNoether\>** okay, anyone else want to present any research or thoughts at our roundtable?
**\<moneromooo\>** If you guys are looking at making unlock time a commitment, maybe this is a good time to look at a possible semantics change for unlock time to ease future things like atomic swaps etc.
**\<Isthmus\>** ^ ooooh
**\<sarang\>** How so?
**\<suraeNoether\>** yeah, please go on
**\<Isthmus\>** Ok, my head is figuratively literally splitting in half, so I'mma peace out. Thanks y'all.
**\<Isthmus\>** gg
**\<moneromooo\>** By... er... thinking of the requirements you know of for atomic swaps etc, and what semantics would best match those.
**\<sarang\>** See ya Isthmus; feel better
**\<sarang\>** also see ya endogenic
**\<moneromooo\>** I'm thinking in particular of the fact monero's unlock\_time semantics do not match bitcoin's, and bitcoin's used for more fancy things like atomic swaps.
**\<sarang\>** Ah ok
**\<Isthmus\>** Oh but before I go, huge shoutout to @n3ptune who curated the data set
**\<Isthmus\>** Ok ciao!
**\<suraeNoether\>** moneromooo: yeah, we need to nail down specific examples of usual atomic swaps with bitcoin and how the masked unlock times in monero will play with the unmasked lock times in bitcoin...
**\<suraeNoether\>** for sure
**\<suraeNoether\>** isthm and i are having a video call about it after he feels better. i'll take notes and we'll draft an issue.
**\<suraeNoether\>** allrighty, we are coming up on an hour
**\<sarang\>** Action items, I suppose?
**\<suraeNoether\>** indeed
**\<suraeNoether\>** Mine: sending comments to sarang re: triptych and clsag, consulting with isthm about masking unlock times... which maybe we should do over IRC instead of a video call... to make a donation to sarang's funding request...
**\<sarang\>** I'll be continuing that Omniring issue, editing CLSAG/Triptych based on suraeNoether's reviews, and a few odds and ends relating to code libraries and MPC
\< does anyone have any last questions?
**\<sarang\>** Nay
**\<sarang\>** I suppose we can adjourn then
**\<gingeropolous\>** when ringsize a bajillion
**\<sarang\>** Soon (tm)
**\<gingeropolous\>** :)
**\<sarang\>** Or the Futurama answer: "Soon enough." "That's not soon enough!"

221
_posts/2020-01-08-mrl-meeting.md Normal file
View File

@ -0,0 +1,221 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-01-08
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS to everyone
**\<almutasim\>** Hi.
**\<binaryFate\>** hi hi
**\<sarang\>** Let's start with ROUNDTABLE
**\<sarang\>** The preprint for Triptych, a new linkable ring signature construction that can be extended for use in transactions, is on the IACR archive
**\<sarang\>** Link: https://eprint.iacr.org/2020/018
**\<sarang\>** CoinTelegraph just released an article about it (but note there are some errors in the data presented there, that I'm told will be fixed)
**\<sarang\>** I plan to make an update on the size and time data, to properly account for batch verification and ensure fair comparison
**\<sarang\>** More work was done on the multi-index version of Triptych, fixing soundness in exchange for a separate proof relation that we need to show is equivalent to another proof relation
**\<sarang\>** This would allow even better performance
**\<sarang\>** I worked out an MPC for that version of Triptych as well, which would be useful for multisig
**\<sarang\>** And I'm presently working on some questions relating to Omniring math that I've brought up with that paper's authors
**\<sarang\>** Does anyone else wish to share interesting research work?
**\<almutasim\>** When the time is right, at a key juncture, we could have a press release on Triptych. Monero Outreach could support that. Maybe when it is established that it is going into a release.
**\<sarang\>** To be clear, there are no guarantees that Triptych, or any presently-known construction, is fit for deployment
**\<almutasim\>** Right.
**\<Isthmus\>** I've got some fingerprinting stuff, and n3ptune just completed a pretty cool network analysis
**\<sarang\>** Ooh
**\<sarang\>** Isthmus: what sort of data have you uncovered?
**\<Isthmus\>** Ah my fingerprinting notes are nothing new or exciting, just an idea that might make data presentation more intuitive. So, I tend to think about wallet fingerprinting in a kind of abstract way - every transaction sits at some corner of a hypercube in a high-dimensional space made of different heuristics yadda yaddaaa yadda
**\<Isthmus\>** So even though I work with sets of boolean features on the backend, wanted a good way to show results
**\<Isthmus\>** This is my first attempt: https://mitchellpkt.github.io/fingerprint.html
**\<sarang\>** What, you can't accurately present visualizations of high-dimensional hypercubes? =p
**\<Isthmus\>** llol
**\<Isthmus\>** This is somewhat by @suraeNoether adding human-interpretable output to the graph matching
**\<sarang\>** I like the idea of enumeration like that
**\<Isthmus\>** thanks! It figure it's also an easy way to pass around data in a 2-column CSV chart, and researchers can do substring matching on portions that they find relevant to a given analysis
**\<suraeNoether\>** Ack sorry! I'm here! Time change got me unawares
**\<sarang\>** Isthmus: is there anything to share about the network analysis you mentioned?
**\<n3ptune\>** Re: questions on block propagation timing asked last month, I've collected and analyzed block receipt timing data from our global nodes recorded during the past 6 months
**\<sarang\>** Nice!
**\<sarang\>** What conclusions?
**\<n3ptune\>** Isthmus has notes about interpretation and I have more to write but you can look at the graphs here https://github.com/noncesense-research-lab/archival\_network/wiki/Block-propogation-time
**\<Isthmus\>** This was RE a question that @moneromooo asked, right?
**\<Isthmus\>** Units are size in bytes and timestamps in milliseconds, right?
**\<suraeNoether\>** that was my question ^
**\<n3ptune\>** we used this formula where NRT is Node Received Timestamp: prop\_time\_lower\_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] - MIN[NRT(h,1), NRT(h,2), NRT(h,3)]
**\<sarang\>** What are the changing indices there?
**\<sarang\>** Different nodes?
**\<sgp\_\>** hello
**\<n3ptune\>** yeah, that goes up to 3 but there are 4 nodes total
**\<sarang\>** got it
**\<suraeNoether\>** so block prop time is reliably at least 0.1s. interesting.
**\<Isthmus\>** Oh scatter heatmap is height from dark=old to light=new
**\<Isthmus\>** ^ color scale
**\<sarang\>** And those are the differences between the miner-reported timestamp and the node's wall clock upon receipt?
**\<Isthmus\>** Miner reported timestamps are not considered anywhere in this study
**\<Isthmus\>** But we did that elsewhere
**\<suraeNoether\>** hm then what is being measured for prop time?
**\<sarang\>** So these are blocks only passed between your nodes?
**\<sarang\>** Where you look at local times on send and receipt?
**\<Snipa\>** ^ Was going to ask that, as the min propogation time seems particularly low, as 100msec is quite low in our experience to cross the globe.
**\<sarang\>** Or better question: how is NRT computed
**\<n3ptune\>** it's the difference in timing between different nodes receiving the same blocks
**\<sarang\>** Ah, ok
**\<Isthmus\>** Yea, not passing between our nodes, but passing through our nodes
**\<n3ptune\>** NRT is recorded from the node system time when a block arrives
**\<sarang\>** Independent of the peer from which they receive
**\<sarang\>** (which would differ)
**\<sarang\>** Seeing the difference between miner-reported time (which could be inaccurate) and wall-clock receipt time would also be interesting
**\<suraeNoether\>** hmmmm
**\<endogenic\>** o/
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/brPsQyeU/image.png
**\<Isthmus\>** @sarang just for you
**\<sarang\>** So what we're really seeing here is not propagation time directly, but variability in one layer of propagation time
**\<sarang\>** here = the initial plots, not this one
**\<Snipa\>** I'll have to check pool log data, as I might be able to give some extra data points if you're interested. We started to log the time in which a pool node finds a block, versus when that block is stored into our database, which means it's been processed by the local node, as we skip all monerod timings on the pool itself.
**\<suraeNoether\>** oooop
**\<suraeNoether\>** that's cool
**\<sarang\>** Very high times
**\<Isthmus\>** @Snipa very nice!
\< can you elaborate?
**\<suraeNoether\>** isthmus well it's how long it takes for the block to propagate from one of your nodes to another of your nodes; not time it takes to propagate from a miner to one of your nodes
**\<sarang\>** I mean that for the initial plots you showed, you can't directly interpret the time for the block to reach your node after it's mined
**\<sarang\>** suraeNoether: no
**\<suraeNoether\>** no?
**\<Isthmus\>** Yea, we very deliberately labeled all of the axes "prop time lower bound" for that reason
**\<Isthmus\>** Also, we could always posit that there is an old PC on dialup somewhere in Nebraska with a 4 minute prop time, but that's not meaningful
**\<sarang\>** suraeNoether: it's looking at the difference in receipt time, whichever path the block took in total propagation
**\<Snipa\>** Hrm, auctually, I can provide a data stream of our global block propgations, as every node has a local reporter that we can hook.
**\<Isthmus\>** @Snipa yes please!
**\<suraeNoether\>** sarang that's true also
**\<n3ptune\>** that data would be awesome to work with
**\<Isthmus\>** I'll posit something that might be wrong:
**\<Isthmus\>** It's a hacky data science way of thinking -
**\<Snipa\>** Hit me up a bit later and we can discuss how to get it to you, and go over data formats.
**\<Isthmus\>** Shoot, I gotta get off the bus
**\<suraeNoether\>** isthmus: you have two sensors set up to detect propagation time. but you need 3 to triangulate, ala seismic detection of epicenters
**\<sarang\>** Don't leave us with that cliffhanger Isthmus!
**\<suraeNoether\>** i'm on the edge of my seat
**\<suraeNoether\>** i spilled my tea
**\<suraeNoether\>** i'm so upset at isthmus right now i could just light myself on fire
**\<sarang\>** Stay on the bus Isthmus... it'll loop back around to your stop eventually
**\<sarang\>** In the meantime, any other interesting tidbits on this work?
**\<sarang\>** This is very interesting data
**\<suraeNoether\>** while we are waiting on Isthmus, I'll give my super-brief update: after some discussions with endo, my matching code has been made significantly more efficient, easy to understand, and easier to debug; i'll be making a push later today. my two categories of work today are re-reviewing CLSAG and working on matching
**\<n3ptune\>** that's it for now, we will update
**\<endogenic\>** his pseudocode now fits onto one sheet of notepad paper..
**\<suraeNoether\>** isthmus and i also technically had a conversation about writing up a proposal to encrypt and enforce all lock times, but we haven't gotten details worked out yet
**\<sarang\>** You mean using DLSAG-style commitments?
**\<sarang\>** We'd discussed it earlier in a meeting
**\<suraeNoether\>** yep, last meeting iirc. but i actually had a call with isthmus about it. i view this move as a very good boost in privacy in the sense that it covers up a source of non-randomness in the large data sets that isthmus likes to comb through.
**\<sarang\>** I can work out the size and time implications on that if you like
**\<suraeNoether\>** i'm not convinced it is worth the additional cost to our txn sizes, but we'll see how it shakes out
**\<sarang\>** Since it could be bundled into the existing bulletproof
**\<suraeNoether\>** ^ ah
**\<sarang\>** Yeah, size is not the issue here due to the logarithmic scaling
**\<suraeNoether\>** yeah, and verification times are speedy as a cheetah's balls
**\<suraeNoether\>** pardon me, this is a public meeting, i should be less vulgar. please accept my apologies.
**\<sarang\>** Right... there's a linear increase in verification time, but with the benefits of multiexp that's reduced a bit
**\<sarang\>** CoinTelegraph has updated their article: https://cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity
**\<sarang\>** Thanks to the author for taking care of that so quickly
**\<almutasim\>** A press release could get more coverage, when and if it is desired.
**\<sarang\>** suraeNoether: interestingly, due to bulletproof padding, for many transactions there would be no size increase aside from the space taken up by the commitment data
**\<suraeNoether\>** good on cointelegraph
**\<sarang\>** (as opposed to a smaller plaintext representation)
**\<suraeNoether\>** sarang: could a similar approach be used to include a ciphertext of a message?
**\<suraeNoether\>** ie moneroMail
**\<Isthmus\>** Sorry somebody got in a fight with the bus driver right before my stop
**\<sarang\>** Not really... there's some spare space in bulletproofs that could hold something 1-2 proof elements of arbitrary data by controlling randomness (I'd need to check the details)
**\<Isthmus\>** Sigh San Francisco
**\<sarang\>** Welcome back Isthmus
**\<Isthmus\>** Ok lemme whiteboard some stuff 1 sex
**\<Isthmus\>** n3ptune: do you want to share the padding?
**\<Isthmus\>** In the blocks
**\<n3ptune\>** sure
**\<suraeNoether\>** sarang so enough for a key exchange but unlikely enough for a ciphertext?
**\<sarang\>** Well, you're limited by space
**\<n3ptune\>** Is there a known purpose for the null padding tag in tx\_extra?
**\<sarang\>** I don't remember if Poelstra and friends found 32 or 64 bytes of space
**\<sarang\>** n3ptune: good question for moneromooo et al.
**\<sarang\>** While we await Isthmus' continued update, anything else of interest to share?
**\<sarang\>** Or ACTION ITEMS, according to the agenda?
**\<suraeNoether\>** i want to provide final comments to you on clsag but i'm very unlikely to get that finished today
**\<suraeNoether\>** but it's on my mind for this week
**\<Isthmus\>** Back
**\<suraeNoether\>** Front
**\<sarang\>** Mine are to get CLSAG submitted (after review), to hopefully nail down this Omniring issue and pass it to the authors, work on a few EC curve library updates for proof of concept code, and get preprint stuff taken care of via monero-site MR
**\<sarang\>** Isthmus: please go ahead
**\<sarang\>** (oh, and update the Triptych preprint performance data with better clarity)
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/gAM3VbDV/1578508953.JPG
**\<sarang\>** wat dis
**\<Isthmus\>** So let's say that we have 100 of n3ptune/NRL's archival nodes running
**\<Isthmus\>** If we have only 2 nodes, then our propagation envelope will have a lot of variability, be topology dependent (assume archival nodes don't connect to each other), and just t\_second - t\_first
**\<Isthmus\>** As we add a 3rd node, it has the possibility of increasing the measured prop time (since it could hear before or after) but can't decrease the prop time since it's max-min
**\<Isthmus\>** As we get up to 100 nodes, the variability will probably smooth out and we approach the true reasonable prop time (from miner to global nodes with broadband internet)
**\<sarang\>** Doesn't prop time depend on max/min among all nodes? So the third node could fall outside the envelope of the other two and affect the value?
**\<Isthmus\>** Yeah, that's the point
**\<sarang\>** OK, I must have misinterpreted
**\<sarang\>** Oh, can't \_decrease\_
**\<sarang\>** nvm
**\<Isthmus\>** Painting very broadly, when we adad the 3rd node there's a 2/3 chance that it'll fall outside the N=2 and increase the prop time, and a 1/3 chance that it'll be between the first 2 nodes.
**\<Isthmus\>** Sorry, I'm giving a kind of scattered description cuz I just realized this on the bus
**\<almutasim\>** Max-Min is a very sensitive metric, sensitive to outliers.
**\<Isthmus\>** Hmm lemme ponder on that
**\<Isthmus\>** Skipping over that for now
**\<Snipa\>** How're you pulling the time in which the block is received? Tweaked monerod/using it's logs or polling on the RPC interface to determine when it's auctually viably added to the box?
**\<Isthmus\>** That's a n3ptune question, they do all the DevOps and data engineering. All ended up in a SQL database by the time I got to it
**\<n3ptune\>** tweaked monerod
**\<Snipa\>** On P2P receive then?
**\<Isthmus\>** So for each height we have epsilon (green line) which our many-node approximation of global prop time
**\<n3ptune\>** you can also use monerod --block-notify, if you point that to a shell script that writes the timestamp
**\<Snipa\>** --block-notify waits until the block is committed, which is why I ask, because nodes that do not use NVMe have much slower propagation times in general, as you're waiting on disks to write.
**\<n3ptune\>** i like that better because then you can use the stock daemon. but we don't use that yet
**\<sarang\>** OK, so using the max-min metric, assuming relatively even node placement across the network topology?
**\<Isthmus\>** Yeah, though after @almutasim I'm considering a few other less sensitive metrics
**\<Isthmus\>** slap all those epsilons into a histogram, and that's the plot on the right.
**\<sarang\>** The outliers being nodes close to the miner and far from it, topologically
**\<Isthmus\>** Uhm, the outlier might be only 2 hops away but one of the hops is really slow
**\<n3ptune\>** P2P Receive: no it happens when it adds it to the blockchain, after it determines whether or not it's an alt block. this was because we had another original goal to capture alt blocks data. the daemon patch is shared here https://github.com/neptuneresearch/monerod-archive
**\<Isthmus\>** @sarang so it depends if topological distance definition is just the p2p connectivity graph or takes into account time between vertices
**\<sarang\>** right
**\<Isthmus\>** And that epsilon plot is basically what n3ptune shared earlier except instead of "max-min with 4 nodes" it is "asymptotic approximation of global prop time"
**\<Isthmus\>** ^talking about x-axis of histogram
**\<n3ptune\>** --block-notify waits until the block is committed \>\> oh then i guess this method of doing it in blockchain::add\_new\_block() at least occurs before block-notify would. but yes it isn't \*immediately\* on receive
**\<sarang\>** Since we're just about out of time, any last bits of information before adjourning (discussion can of course continue) for log purposes?
**\<Isthmus\>** Oh yea
**\<Isthmus\>** just a quick note that tx\_padding is used in the wild, but unclear why
**\<Isthmus\>** In the scatter plot showed earlier, the vertical bands from left to right are empty blocks and then N=1,2,3... transaactions
**\<sarang\>** That's a question for someone like moneromooo
**\<Isthmus\>** Of course there's variability in the horizontal width of the vertical bands due to transaction size differences, but the variability in coinbase-only blocks was straange
**\<Isthmus\>** https://xmrchain.net/tx/acdf8eac41a7a76fd899e09640db34023abff66b3ae2c9ea86e49f19c0720af4
**\<Snipa\>** Not really, coinbase only blocks are quite common due to pool design.
**\<Isthmus\>** No no, the size\*variability\* in coinbase-only was strange
**\<Isthmus\>** Turns out some (now fingerprinted) miners are using lots of null padding, check out the tx\_extra for this coinbase
**\<sarang\>** gadzooks
**\<Snipa\>** Not super surprising.
**\<Isthmus\>** Looks like bloat to me
**\<Isthmus\>** Bunch of blocks waste space with nulls in tx\_extra
**\<Snipa\>** Possibly, it's also something that can be requested by a pool.
**\<Snipa\>** As that's the block padding that we use for extra nonce storage space.
**\<Isthmus\>** "As that's the block padding that we use for extra nonce storage space." block nonce or transaction nonce? This is padding in the coinbase transaction
**\<Snipa\>** Oh sorry, txn, my bad.
**\<Isthmus\>** Do you know why some miners use the padding and some don't?
**\<Snipa\>** Lemme look through some of my decoding code I wrote for that.
**\<Isthmus\>** I'd been comparing:
**\<Isthmus\>** https://xmrchain.net/search?value=1988283
**\<Isthmus\>** and
**\<Isthmus\>** https://xmrchain.net/search?value=1985042
**\<Isthmus\>** Since they seem to be exactly the same besides different padding
**\<Isthmus\>** Anyways, thanks for letting me ramble and shifting meeting time
**\<Snipa\>** For quick reference: The block's CB TXN contains an "extras" section, which is requested from Monerod as the extra space in which arbitary data can be written. This data is used by pool implementations to implement the per-pool nonces as well as any custom nonce data used by more advanced techniques.
**\<Isthmus\>** "extra space in which arbitrary data can be written"
**\<Snipa\>** You can use this data in a number of ways, particularly with knowledge of pool design, as the two main pool implementations use this space similarly, but have different sizes based on various addon support.
**\<Isthmus\>** Ooh, what are the current use cases?
**\<Snipa\>** You also can identify what pool instances are submitting blocks, as pools use unique identifiers in particular bytes.
**\<Isthmus\>** (I have no knowledge of pool design)
**\<Snipa\>** https://github.com/Snipa22/nodejs-pool/blob/master/lib/coins/xmr.js#L115
**\<suraeNoether\>** For those of you who are interested in helping out with Monero Kon 2020 in Berlin, there is a meeting happening right now for prospective volunteers. This is research related, but otherwise off-topic, so I'm just dropping this here.
**\<Snipa\>** ^ is the implementation you'll find on pools that support the XNP extensions I wrote awhile ago.
**\<sarang\>** Yeah, we can formally adjourn the meeting, but carry on the conversation
**\<sarang\>** Thanks to everyone for attending

135
_posts/2020-01-15-mrl-meeting.md Normal file
View File

@ -0,0 +1,135 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-01-15
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<sgp\_\>** hello
**\<almutasim\>** Hi.
**\<ArticMine\>** Hi
**\<koe\>** hi
**\<vtnerd\>** hi
**\<suraeNoether\>** Wow what a turnout!
**\<atoc\>** Hello
**\<rehrar\>** hi
**\<sarang\>** Let's continue with ROUNDTABLE discussion
**\<sarang\>** suraeNoether: anything of research interest to share?
**\<ajs\>** ajs archived the channel.
**\<sgp\_\>** um.... is the channel now gone on Mattermost?
**\<suraeNoether\>** not yet... Right now I'm just copy editing CL sag, working on matching code, and looking into possible speedups for triptych
**\<ajs[m]\>** ?
**\<suraeNoether\>** I expect about an hour before clsag is done
**\<ajs[m]\>** I thought it was just for me
**\<atoc\>** I noticed it disappeared too.
**\<sgp\_\>** it's gone
**\<rehrar\>** lol
**\<rehrar\>** give me a sec
**\<suraeNoether\>** Hmm. Who was running it?
**\<sgp\_\>** sorry for derailing, something to fix later
**\<suraeNoether\>** Oh
**\<suraeNoether\>** Moving along :) what about you, Sarang?
**\<sarang\>** Sure
**\<koe\>** for those who want to access logs later: https://monerologs.net
**\<ajs[m]\>** lol
**\<sarang\>** The Triptych preprint has been updated with new efficiency data and some minor typo corrections (IACR 2020/018)
**\<sarang\>** It will appear on monero-site as MR 1197
**\<sarang\>** The DLSAG paper is being revised for its publication in the FC 2020 proceedings
**\<sarang\>** and we're working on updating the security model for later journal submission
**\<sarang\>** I have a monero-site MR ready to go for the CLSAG updates (MR 1202) as soon as suraeNoether's review is complete
**\<sarang\>** (and I get it updated on IACR)
**\<sarang\>** I did some major overhauls on the curve libraries that I use for ed25519 and ed448 testing (for prototyping only; don't use them in production)
**\<sarang\>** That included porting them to a bunch of other research projects
**\<sarang\>** I also did some updates on my Lelantus code to fix some Fiat-Shamir transcript issues
**\<sarang\>** And that's about it
**\<sarang\>** Does anyone else have research to share?
**\<sarang\>** We can also have any questions as well
**\<atoc\>** Currently I have been just familiarizing myself with Monero Research
**\<atoc\>** I have read quite a bit of Zero to Monero, and I also looked at the bipartite matching project: https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
**\<atoc\>** I did have some questions, but I can go through them later with surae perhaps?
**\<suraeNoether\>** Sure, now is fine with me too
**\<suraeNoether\>** It's on topic :P
**\<sarang\>** Sure, go ahead
**\<koe\>** speaking of ZtM, thanks to Articmine the dynamic fee section has been greatly elaborated; anyone curious about all the justifications and derivation and analysis can find it in the latest draft; all that remains before I can publish are multisigs, bulletproofs, and proofreading (each of which will take a long time admittedly)
**\<koe\>** https://www.pdf-archive.com/2020/01/15/zerotomoneroebookmaster-v1-0-17/zerotomoneroebookmaster-v1-0-17.pdf
**\<atoc\>** Ok cool, well can you briefly give a high level description of this project? From what I understand so far is that this project will be used for user analysis along with statistical models, but hearing an overview from in your words would be nice.
**\<rehrar\>** it's good to see ZtM getting the update :)
**\<suraeNoether\>** Gotcha okay so first think about the Monero blockchain using two columns. List all of the one-time output keys from coinbases and from other transactions on the left and list all ring signatures or if you like key images on the right-hand column
**\<suraeNoether\>** You can then go and draw edges between one time keys and ring signatures indicating ring membership. So if I publish a ring signature with ring members a b and c, my ring signature on the right would have edges connecting it to the outputs a, b, and c on the left
**\<suraeNoether\>** These are what I call red edges in my code, and I also indicate blue edges connecting ring signatures on the right with the new fresh transaction one time keys that are output from their respective transactions on the left
**\<sarang\>** koe: I asked this before, but how detailed are you looking to get with bulletproofs?
**\<sarang\>** I fear you may end up essentially rewriting their entire paper, with little benefit to the typical reader
**\<suraeNoether\>** So the Monero blockchain can be visualized as this two-colored bipartite graph with one-time keys on the left, ring signatures on the right, red edges indicating ring membership, and blue edges indicating output relationships
**\<Isthmus\>** Hey @koe I owe you an email. I have some protocol notes, but have just been super swamped.
**\<atoc\>** Cool cool, I
**\<Isthmus\>** I'll try to get the email out in the next few days
**\<atoc\>** I'm with you\*
**\<scoobybejesus\>** i am sort of busy, but wanted to throw out a question (in other words, don't let this question interrupt the current line of talk). a response anytime would be great, though
**\<scoobybejesus\>** I was thinking about how people complain about outputs getting locked up for 10 blocks. Consequently one must send to themself a multi-out txn to prevent that from happening. What if we made the standard tx 2-in and 3-out (2 change)? And maybe set them to send to different accounts, so they take on independent/divergent decedent txn histories. Was curious if MRL had thoughts/impressions
**\<Isthmus\>** I also got halfway through updating Big Bang paper, but then got distracted. Hoping to finish that this weekend or next.
**\<suraeNoether\>** The ground truth of the situation is that each ring signature has a ring member that is the true signer of the signature, so for every ring signature with a bunch of red edges leading to a bunch of one-time output keys, somebody who's trying to track transactions is trying to pick the true spender from these red edges
**\<suraeNoether\>** And this is called the matching problem in the graph theory world, sometimes also called the assignment problem, sometimes called the assigned marriage problem lol
**\<suraeNoether\>** So somebody who is trying to track transactions on the Monero blockchain is really trying to find a maximum matching on the Monero blockchain, linking signatures to true spenders
**\<sgp\_\>** scoobybejesus: I'd rather find ways to reduce the lock time
**\<koe\>** no worries Isthmus :); sarang that's a valid concern and Im really not sure since I don't actually understand bulletproofs yet; I think if the bulletproofs paper is clear enough it will be fine to point people in that direction; I dislike the idea of leaving things open ended, but maybe it's just a useless hangup ^.^
**\<suraeNoether\>** The signatures themselves give nothing away about which edge is supposed to be the true spender, so without any additional information the attacker just has to guess, and so every possible maximum matching is equivalently good in this world
**\<atoc\>** Ah okay, I see. It seemed as if you were trying to find out if there was a way to trace back transactions.
**\<suraeNoether\>** I am kinda
**\<suraeNoether\>** So my graph theory python code allows you to build a graph, and then find maximum matchings, and if you wait the edges, it'll find the heaviest weight matching so that somebody using extra metadata can do better than just guessing at random
**\<suraeNoether\>** Weight\*
**\<almutasim\>** How do you assign weights?
**\<suraeNoether\>** Right so that's outside of the scope of graph theory and in the scope of my simulations...
**\<almutasim\>** Ah. Are they probabilities?
**\<atoc\>** Is this where statistical models come into play/
**\<suraeNoether\>** Yep. The way that I'm trying to do this is I'm simulating an economy between Alice, Eve and exchange with KYC information, and Bob representing all background players in the Monero economy. I'm even telling Eve the information about the Markov chain from the beginning, which models eves perfect ability to learn your habits.
**\<suraeNoether\>** So this Eve is able to wait the graph using some null hypothesis about user behavior
**\<suraeNoether\>** once she does this, even though she doesn't know the ground truth reality of the blockchain, she can find a maximum likelihood estimate which corresponds to a maximum weight matching
**\<sarang\>** s/wait/weight/ ?
**\<suraeNoether\>** Weight\* sorry I'm on voice to text
**\<suraeNoether\>** So the simulator simulates an economy, strips information out of the graph that Eve doesn't know, hands the blockchain to Eve, Eve weights the graph and compute some maximum likelihood estimate, and this maximum likelihood estimate is compared to the simulators ground truth
**\<suraeNoether\>** When things are working I get preliminary data that suggests that Eve is really really bad at this game Even though she's given perfect information about Alice's habits
**\<suraeNoether\>** But that's all preliminary because my code is only intermittently working and I am currently in the midst of refactoring it to be simpler.
**\<almutasim\>** That's encouraging.
**\<atoc\>** Quite interesting surae. I understood about half of it before, but given you're description I see the goal of the project now.
**\<atoc\>** Ah I see, was MoneroLink done by the Monero community or third-party?
**\<surae\>**: The fact that it was written by people who had a financial interest in succeeding compared to Monero was viewed as very suspicious by a lot of folks.
**\<koe\>** suraeNoether have you collected a list of tracability analysis papers? for example sarang mentioned a preprint earlier; or maybe Isthmus has that list
**\<surae\>**: Andrew Miller from Zcash and a couple of other folks who were involved with Zcash were authors
**\<surae\>**: Actually you know, Sarang may have a better list than I would... A paper came out last year describing a game not dissimilar from my graph theory game and they named it after sun tzu. But I can be more helpful in finding background papers. Basically any papers on the traceability of anonymous communication networks has some degree of applicability to the Monero blockchain
**\<surae\>**: "perfect matching disclosure attacks" is a general paper that was critical in the construction of the matching stuff
**\<atoc\>** I see I see. So I see a couple of todos listed (unity tests and another). What are some important priorities for this project? I feel I can contribute to this project as a start.
**\<atoc\>** Just a little background about myself: I'm an academic researcher in theoretical computer science (neural algorithms).
**\<surae\>**: Let's talk about that after the meeting
**\<atoc\>** sure
**\<Isthmus<75>\>** Dang, I got bumped off IRC
**\<Isthmus<75>\>** Can't log back in
**\<surae\>**: speaking of the meeting, isthmus tells me that he has lost access to IRC... And I also happened to lose access to IRC and I'm just using the keybase bridge
**\<Isthmus<75>\>** \*IRCcloud
**\<surae\>**: it looks to me like IRC cloud has gone down which means the vast majority of the people in this room are probably not here anymore
**\<Isthmus<75>\>** @atoc nice to meet you, excited to contribute
**\<Isthmus<75>\>** \*to collaborate
**\<Isthmus<75>\>** Sorry, I'm in a meatspace meeting too
**\<surae\>**: So we'll give it a few more minutes and if I receive cloud doesn't come back or if nobody else speaks up, I say we adjourn the meeting
**\<surae\>**: If irccloud\*
**\<Isthmus<75>\>** So I just realized that we aren't fully utilizing the archival network data. But I'll wait for our IRCcloud comrades to return
**\<sgp\_\>** yes, irccloud seems to be down for everyone
**\<surae\>**: I had a question for isthmus about the archival network and lock times
**\<Isthmus<75>\>** sup
**\<surae\>**: I want to know the distribution of fork lengths observed so far, and I also want to know the distribution of forklengths experienced by a new node syncing
**\<atoc\>** isthmus nice to meet you as well.
**\<atoc\>** hmm okay and sorry what do you mean fork lengths?
**\<surae\>**: As in Nakamura consensus resolving a fork
**\<surae\>**: Nakamoto
**\<surae\>**: WTF that was autocorrect too not voice to text
**\<almutasim\>** It should be correcting the other way.
**\<atoc\>** I see, alright I will begin looking into this.
**\<surae\>**: Isthmus actually specifically I want an estimate of the parameter r under the null hypothesis that fork lengths are negbinom(p, r)
**\<surae\>**: I think lock time has to be proportional to r to protect most transactions from most rollbacks
**\<surae\>**: Okay since irccloud is now fartcloud, I say this meeting is adjourned.
**\<koe\>** good meeting! happy day to yall
**\<surae\>**: Good seeing you around koe
**\<sgp\_\>** thanks
**\<almutasim\>** Thanks. Good meeting.

283
_posts/2020-01-22-mrl-meeting.md Normal file
View File

@ -0,0 +1,283 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-01-22
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<binaryFate\>** hi!
**\<sgp\_\>** hello
**\<suraeNoether\>** Hi
**\<koe\>** hiya
**\<Isthmus\>** holla
**\<sarang\>** Let's move to ROUNDTABLE
**\<sarang\>** Isthmus: you posted some data on the agenda; care to discuss?
**\<sarang\>** Link to data: https://github.com/monero-project/meta/issues/430#issuecomment-576455137
**\<Isthmus\>** Sure
**\<Isthmus\>** First, glanced at distribution of number of outputs on miner transactions
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/OB2UWpjs/image.png
**\<Isthmus\>** This is mostly a historical novelty from back in the days of denominated XMR - since RingCT became mandatory at block 1400000 all miner transactions have been 1OTXs.
**\<Isthmus\>** \*single-output coinbase transactions
**\<sarang\>** So that chart is for \_all\_ miner txns?
**\<sarang\>** Throughout all of time?
**\<Isthmus\>** From genesis block to last week
**\<Isthmus\>** Courtesy of n3ptune's magic database xD
**\<Isthmus\>** Another mostly historic novelty - altruistic transaction selection by miners who would include many/large transactions in their blocks, incurring a coinbase penalty that is not offset by the added fees. (In other words, they would have had a higher total block payout by mining an empty block.)
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/0pcNROcT/image.png
**\<Isthmus\>** color is size, starting at blue = small
**\<Isthmus\>** This seems to not be a very common practice these days
**\<Isthmus\>** Altruistic mining could be banned at the protocol level, but at the moment I'm not inclined to do so
**\<koe\>** more advanced altruism based on suboptimal tx inclusion will involve more intensive analysis, which I provided pseudo code for this week, if that path is chosen
**\<suraeNoether\>** Any comparison against partially filled blocks rather than empty blocks?
**\<Isthmus\>** @koe yea do you want to jump in
**\<sarang\>** Yeah koe please do
**\<sarang\>** koe: if you have a link to the pseudocode can you include it here?
**\<koe\>** well this week I: made pseudo code for Isthmus blockchain analysis, deep proofreads of several ZtM chapters, talked with cohcho and jtgrassie about uniformity of coinbase tx
**\<koe\>** more or less improved a roadmap of future monero developments: https://justpaste.it/5io6e which we can talk about some items
**\<koe\>** latest ztm2 draft, I have honestly been pushing off multisig edits, but not making no progress https://www.pdf-archive.com/2020/01/22/zerotomoneromaster-v1-0-20/zerotomoneromaster-v1-0-20.pdf
**\<sarang\>** Enforcement of exact block rewards seems straightforward and a good idea
**\<koe\>** pseodo code https://paste.debian.net/1127152/
**\<sarang\>** Regarding ZtM, are there topics in progress for which you'd like particular information or assistance?
**\<koe\>** currently working on multisig, and have already gone through most documentation available, but there are some things that aren't clear despite documents
**\<koe\>** so if anyone knows about multisig, Id like to discuss with them
**\<koe\>** otherwise will dive into code base
**\<suraeNoether\>** I'm not super familiar with the code base, but I'm familiar with what it's supposed to abstractly represent
**\<sarang\>** Thanks koe
**\<suraeNoether\>** So if you have questions koe about how things are supposed to work (as compared to how things are currently implemented)
**\<suraeNoether\>** Lmk
**\<koe\>** ok Ill hit you up
**\<sarang\>** Anything else of interest to share koe? You've clearly been busy!
**\<koe\>** well there are all the things in the roadmap, in particular enforcing 1 output from coinbase (since Isthmus found literally all coinbase for 4 years have been single output), and possibly enforcing single-type ring membership (only coinbase ring emmbers, only rcttypebulletproof2 ring members) since 99.5% of coinbase are owned by pools who are easy
**\<koe\>** to fingerprint
**\<sarang\>** Single-type enforcement was brought up a few times by sgp\_ in the past as well
**\<koe\>** see https://minexmr.com/pools.html where 99.5% of hash is accounted for
**\<sarang\>** My concern was that a full segregation of coinbase outputs means certain heuristics are only moved "down chain" by a single hop
**\<sarang\>** Meaning there's likely improvement for sure, but perhaps more marginal than desired
**\<atoc\>** koe, do you still need proofreading of ZtM or are you good on that?
**\<suraeNoether\>** I'm in favor of enforcing single output coonbase txns by consensus. I'm in favor of enforcing block reward. I'm tentaticely in favor of type-restricted rings.
**\<koe\>** always need proofreading :) even after it's published lmao, I've received some good emails that are incorporated in v2
**\<sgp\_\>** I actually was going to re-introduce the topic again here to keep it on everyone's minds, so nice timing
**\<sgp\_\>** related: https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43
**\<atoc\>** koe, I am have some notes that I need to send you.
**\<atoc\>** I will try to get them to you soon.
**\<koe\>** ill look forward to them :) (email me)
**\<moneromooo\>** Enforcing single output coonbase txns would prevent p2pool.
**\<atoc\>** will do :)
**\<suraeNoether\>** Atoc, I believe that my mojojo branch is no longer bugging out, although data isn't being written to file how I want. The actual tracing game script I am running will be pushed soon(tm)
**\<koe\>** jtgrassie is p2pool your project?
**\<moneromooo\>** AFAIK nobody is doing it yet.
**\<suraeNoether\>** But simulator is now successfully simulating a monero economy between Alice, Eve, and Bob to model flavors of EABE
**\<atoc\>** cool suraeNoether I have been falling a bit behind and will catch up today and get you my thoughts
**\<atoc\>** good to know the unit tests are working fine
**\<atoc\>** Nice
**\<suraeNoether\>** It's all good, I'll still be plugging away
**\<sarang\>** Any other questions/comments for koe?
**\<sgp\_\>** no specific questions, but I have a related topic for mining pools besides coinbase outputs when time allows
**\<sarang\>** OK, first, is Isthmus back? He had to step away briefly
**\<sarang\>** Isthmus: care to finish up your data?
**\<Isthmus\>** Also, it's not "kicking the can down the road" depending on how you implement it
**\<sarang\>** (then we can move to sgp\_)
**\<Isthmus\>** But yea, moving on
**\<sarang\>** Hold on
**\<Isthmus\>** Discovered that everybody seems to use the miner\_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
**\<sarang\>** Why would coinbase-only not do this?
**\<sarang\>** If you assume the spend patterns would be sufficiently different, I agree
**\<Isthmus\>** Uhm, I could get in the weeds with this
**\<Isthmus\>** On like 4 levels
**\<Isthmus\>** lol
**\<Isthmus\>** From an \*on chain\* perspective, there's two questions we can ask
**\<Isthmus\>** 1) Is this ring spending a coinbase
**\<suraeNoether\>** \me pulls up lawn chair
**\<Isthmus\>** 2) Which coinbase is this ring spending
**\<Isthmus\>** #1 is hard to hide
**\<Isthmus\>** #2 can be accomplished
**\<Isthmus\>** making #2 unanswerable can be accomplished
**\<Isthmus\>** I'm an evil exchange
**\<Isthmus\>** With current system, I can fingerprint which pools my users belong to
**\<Isthmus\>** Aah ha, this person makes monthly deposits that are 4-input transactions each spending from a ring with 62 B null padding, so I know that they have about 3000 H/s attached to minexmr.com
**\<Isthmus\>** \*each spending from a coinbase whose miner tx\_extra has...
**\<Isthmus\>** But with coinbase-only txns, we strip the pool-to-user link
**\<sarang\>** fair
**\<Isthmus\>** Sure, as an exchange I can look at each user, and their average number of coinbases per ring
**\<Isthmus\>** And if it's more coinbases per average I could suspect that they're a miner
**\<Isthmus\>** But that's about all
**\<sgp\_\>** while there are some concerns with coinbase-only having only a layer of separation, I think the real benefits are being minimized slightly, especially to non-mining users
**\<koe\>** also, coinbase is currently polluting normal tx rings, since a large proportion are identifiably spent/not spent
**\<sarang\>** koe: the newer weighted selection algorithm does help this to an extent (relative only to tx weight, nothing else)
**\<suraeNoether\>** One thing that is important about privacy is that third parties that have data like this are lawyer magnets. If an exchange couldn't possibly identify their mining user habits, they can't be hacked or subpoenaed to determine one of their customer's hash rates
**\<Isthmus\>** In my ideal world, we have 13 ring members and two selection algorithms. Precisely 11 of the members are non-coinbase, selected with current algorithm. Precisely 2 of the members are coinbase(/coinbase-only) that are selected independently.
**\<sgp\_\>** Isthmus: that would not be good for many reasons :)
**\<sgp\_\>** notably, you need a set of at least 3
**\<Isthmus\>** Oh, I'm not married to the numbers
**\<Isthmus\>** Just making an example
**\<Isthmus\>** (trying to avoid the misconception that adjusting our coinbase ring member selection algorithm will somehow be zero-sum with the rest of the anonymity set or users)
**\<nioc\>** koe: I know that rbrunner (sp) made an implementation of multisig so it might be good to speak with him. I don't see him online now and haven't seen him for a little while but should still be around
**\<koe\>** on the other hand, I wonder if enforced ring types is too much like reacting to how people use it; although the same could be said for many other protocol rules
**\<sarang\>** Anyway, I derailed Isthmus's discussion of his other data with this topic...
**\<Isthmus\>** Also, let M be the minimum plausible age between any output and it's temporally closest ancestor coinbase
**\<Isthmus\>** :- P
**\<Isthmus\>** That can either be a plotable feature, or fixed for all transactions at zero
**\<koe\>** nioc ok Ill reach out
**\<Isthmus\>** I think n3ptune and I may plot this for all outputs just to show the point
**\<Isthmus\>** Other two things on the agenda - encrypted unlock time, and tx\_extra in coinbases
**\<Isthmus\>** I can get into these if people are interested
**\<sarang\>** Sure, I saw your information about encrypted locks
**\<sarang\>** (I also wish to address timelocks anyway\_
**\<sarang\>** )
**\<Isthmus\>** Cool, lemme copypasta real quick
**\<Isthmus\>** Oh, and for the encrypted + enforced unlock time, we have to decide on a format. Currently, 3 things are being put in the unlock field:
**\<Isthmus\>** Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks"
**\<Isthmus\>** Large integers like "1980000", presumably to be interpreted as block heights
**\<Isthmus\>** Very large integers like "1578561720", presumably to be interpreted as unix timestamps
**\<Isthmus\>** While normally I'd be loathe to bring real world time onto the blockchain, I am inclined towards this approach: encrypted unlock time is a future timestamp recorded in unix seconds, and each ring must include a range proof comparing the unlock time to the oldest or youngest ring member (I haven't fully thought this through).
**\<Isthmus\>** The minimum lock time of 10 is trivial for any outside observer/miner to enforce by delaying (or rejecting) transactions with rings containing members less than 10 blocks old. This requires no mathematical validation within the transaction.
**\<Isthmus\>** The encrypted unlock time could actually be defined as timestamp - 1500000000 to save a bit of space by removing the offset from some of time between 1970 and deployment, but that could be overengineering.
**\<sarang\>** We have a relatively efficient way to do encrypted timelocks, as introduced in DLSAG
**\<moneromooo\>** Small integers are block heights. If you put 12 now, it's pointless.
**\<suraeNoether\>** I'm 100% in support of encrypted lock times... I know that sarang has done some work into the requirements on that in addition to isthmus
**\<sarang\>** The method is described here: https://github.com/SarangNoether/skunkworks/tree/timelock
**\<sarang\>** It works as follows: outputs come equipped with a timelock Pedersen commitment (units aren't relevant for this at the moment)
**\<moneromooo\>** Small integers are block heights. If you put 12 now, it's pointless." Ahhahahaha that's what everybody is doing. Lemme make a plot real quick
**\<sarang\>** Signatures come equipped with an auxiliary plaintext time that's chosen semi-at-random
**\<sarang\>** as well as a particular auxiliary commitment
**\<sarang\>** There is a range proof constructed using all these values, and CLSAG/MLSAG gets a new set of entries too
**\<sarang\>** This maintains signer anonymity, shows the timelock has passed, but does not specifically reveal information about it
**\<sarang\>** The cost for CLSAG is 1 new group element; the plaintext timelock is replaced by a plaintext intermediate value
**\<sarang\>** and the auxiliary per-signature commitment is 1 new group element
**\<binaryFate\>** does this mean the no-locktime transactions will be indistinguishable from locktime ones? Or just that the locktime ones will have an obfuscated time lock?
**\<sarang\>** The rangeproofs can be worked into the existing bulletproofs, likely for free due to padding
**\<Isthmus\>** Indistinguishable plz
**\<sarang\>** Depends on how it's implemented
**\<suraeNoether\>** indistinguishable would probably require no-locktime txns to have a dummy encrypted locktime
**\<sarang\>** So the cost is 64 extra bytes per signature, and 32 bytes per extra timelocked output
**\<sarang\>** Yep, you'd include zero locktime
**\<sarang\>** and the rest of the process proceeds the same
**\<sarang\>** So this is not free, but it's not terribly expensive either
**\<sarang\>** Anyway, this information is to supplement what Isthmus brought up about how timelocks are handled now
**\<binaryFate\>** It's completely offtopic but I personally like the idea that we can embed an arbitratry hash in a transaction in a way that is indistinguishable from other txs, for timestamping purposes.
**\<binaryFate\>** Would only be half or a quarter of a hash in that case though
**\<binaryFate\>** (using the encrypted time lock field)
**\<Isthmus\>** @binaryFate if we add an enforced encrypted memo field, that would be a very good use case
**\<suraeNoether\>** binaryFate: well, you could always pick your txn key as the Hp of some message. is that not what you mean?
**\<binaryFate\>** it works too, but require you don't lose your local storage.
**\<suraeNoether\>** sure. you want to be able to extract the message also, something like that?
**\<binaryFate\>** just exhibit the message later on and point out to a past hash in the blockchain that timestamps it, without people taking notice this was a timestamping tx.
**\<binaryFate\>** but if you have message you can get hash back, so tx key works perfectly I guess
**\<suraeNoether\>** oh neat
**\<binaryFate\>** anyway, sorry to derail
**\<sarang\>** Isthmus: take it away :)
**\<Isthmus\>** Derailing conversation is a key part of research! :- D
**\<Isthmus\>** I think that's where 2/3 of our interesting stuff comes from
**\<suraeNoether\>** \*nod\* i prefer these lively research meetings for sure
**\<Isthmus\>** Anyways, last topic I had has been discussed significantly since I initially mentioned it. So I'll intro and then duck out of the way
**\<sarang\>** You had some notes, Isthmus, on how timestamps are represented
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/Ovp9yP0j/image.png
**\<sgp\_\>** I will most likely need to take off, so I'll bring up my other mining pool ring signature proposal (which I mentioned in the past) when I get back
**\<atoc\>** @isthmus agreed, it seems that new ideas fluster that way.
**\<Isthmus\>** Oh go @sgp\_
**\<sgp\_\>** ah, so very fast
**\<sgp\_\>** there are special ways we can construct rings for public mining pools to protect the "integrity" of outputs (make it no longer publicly known what transactions they are spent in)
**\<sgp\_\>** for public mining pools that share transaction histories, it's clear which outputs are change outputs, which are later spent by the pools
**\<sgp\_\>** to avoid this, public pools can select rings using exclusively decoys that they create as payments to miners
**\<sgp\_\>** that way, outsiders have no way to distinguish the output from the other outputs given to miners. saves one output per payment, per public pool
**\<sgp\_\>** this is not a consensus change, but it would require a separate "public pool selection mode" or similar
**\<sgp\_\>** Isthmus: how? payouts won't be from coinbase outputs
**\<Isthmus\>** Aah, maybe I was thinking of something slightly different
**\<Isthmus\>** Carry on :- )
**\<sgp\_\>** this protects pool change outputs from being known as spent by the pool in specific transactions
**\<sgp\_\>** that's about it, just wanting to make sure this idea is resurrected, since I introduced it nearly 2 years ago now
**\<sarang\>** Thanks sgp\_
**\<sarang\>** In the interest of time, Isthmus please go ahead!
**\<Isthmus\>** Everybody seems to use the miner\_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/tXHruCE0/image.png
**\<Isthmus\>** This has implications for privacy of all users. For example, I have a list of blocks mined by the pool that added 60 B null padding to each miner transaction. When this person creates multiple-input transactions to claim the reward, ring signatures offer them no protection.
**\<Isthmus\>** (Multi input + miner fingerprint is statistically noisy, so we know when those outputs are really spent, and can rule them out as decoys in other transactions.)
**\<Isthmus\>** To avoid fingerprinting, it's important that any implementation mimics the full hierarchy on any block. For example, if we accommodate {nonce, pool, proxy}, then every miner (including solo mining core software) should put random data in pool & proxy. Otherwise we've just made a fancier way to leave the same fingerprint. :-P
**\<Isthmus\>** Anyways, others in this room have made a lot of progress on how to address this, so I'll let them jump in
**\<sarang\>** Anyone have anything to add in particular to this?
**\<suraeNoether\>** nope, but I have to get going
**\<sarang\>** OK, suraeNoether: any brief update before you go?
**\<sarang\>** Otherwise, no worries
**\<koe\>** sarang is this the encrypted timelock? https://justpaste.it/2754y
**\<suraeNoether\>** just that sarang and i have been having some extremely deep discussions about unforgeability in CLSAG and the crappiness of linkability models... we are nearing some very valuable improvements to d-CLSAG as written...
**\<suraeNoether\>** i'll let him describe more; i've also gotten my matching simulations (apparently) working correctly on my matching-mojojo branch of mrl-skunkworks
**\<suraeNoether\>** other than that, i have to get going
**\<suraeNoether\>** sorry :(
**\<suraeNoether\>** i'll drop in later today for more of an update
**\<sarang\>** koe: you include the auxiliary timestamp in the signature's extra commitment in the model I worked up
**\<sarang\>** Isthmus: anything else that you hoped to share?
**\<sarang\>** (sorry, trying to ensure everyone gets a chance to finish their presentations)
**\<Isthmus\>** Thanks, I'm outta new material
**\<sarang\>** OK, thanks Isthmus
**\<sarang\>** I worked up some stuff on timelocks (shared earlier), did a blag post with sgp\_ relating to supply auditing (to answer questions that often come up), and got into the weeds on security models relating to linkability
**\<sarang\>** Linkability meaning the formal definition used in linkable ring signatures, not any particular transaction linking
**\<sarang\>** koe: what you have may be algebraically equivalent; I'll take a look shortly
**\<sarang\>** OK, did anyone else have something to share that was missed?
**\<sarang\>** So many things to discuss today!
**\<koe\>** well does anyone have thoughts on enforced sorted TLV format for the extra field? I have spammed up the channel a bit recently, with that topic
**\<sarang\>** Can you recap the benefits and tradeoffs briefly, for those who didn't see the earlier discussion?
**\<moneromooo\>** If someone wants to stuff some random data in there, it's as visible as now, no ?
**\<koe\>** and pursuing coinbase extra field standardization by seeking an inter-pool committe
**\<sarang\>** (note that monerologs.net has logs of this and other channels available)
**\<moneromooo\>** What's an inter-pool commite ?
**\<koe\>** committee between pools
**\<koe\>** composed of
**\<moneromooo\>** Oh you mean just talk to pool ops ?
**\<koe\>** lol yeah
**\<koe\>** these things are called standardization committees in industry
**\<koe\>** benefits of enforced sorted TLV + guidelines for use: a) makes sure all implementations are using the same essential format for constructing extra fields, since without guidelines or structure each implementation is ad hoc; b) for those who are privacy minded, there will be a clear way to blend in with other like minded implementers (for example,
**\<koe\>** who knew that the code base sorts field entries, but at least one live implementation does not?); c) leaves extra field almost as open ended as it is now, so those who choose opt-out privacy (choose to stand out from the crowd) for whatever reason, can still do so trivially
**\<sarang\>** In the earlier discussions, were there particular opinions opposed to it?
**\<sarang\>** If so, why?
**\<koe\>** tradeoffs: a) it may have limited real impact on transaction indistinguishability, especially among coinbase tx if most pool operators aren't on board; b) implies no stricter enforcement of the field will be pursued (which would directly address questions of indistinguishability; c) so far as coinbase tx go, many pools publish their mined blocks
**\<koe\>** (counter argument is Monero development is focused on on-chain, and can't concern too much off-chain activity)
**\<sarang\>** Noted; thanks
**\<sarang\>** Since you were interested also in the hidden timelock construction, any other thoughts on that as well (from your link above)
**\<koe\>** actually I just felt inspired, and wanted to confirm my understanding
**\<sarang\>** Keeping in mind that the range proof can be absorbed into the existing one, meaning no effective change in size or verification for that portion of it
**\<sarang\>** Your construction appears algebraically equivalent to what I listed
**\<koe\>** I dont know enough about CLSAG to make a real judgement
**\<sarang\>** The CLSAG part could apply to MLSAG as well
**\<koe\>** Perhaps if we knew how much timelock is being used in the wild
**\<sarang\>** The only difference is how the commitment to zero is handled in the signature
**\<sarang\>** In MLSAG it would be \_very\_ expensive, but in CLSAG it adds only a single auxiliary linking tag, and makes the verification multiexp a bit more expensive
**\<koe\>** oh nice, I was imagining all those extra mlsag scalars
**\<sarang\>** If people think it's worth seriously considering, I can get more precise timing estimates on those curve operations
**\<sarang\>** Yeah, for CLSAG you don't add scalars
**\<sarang\>** It is in no way worth it for MLSAG
**\<sarang\>** either in size or extra verification
**\<sarang\>** The current CLSAG data has some custom curve-op code for efficiency that wouldn't apply to this new 3-CLSAG timelock construction
**\<sarang\>** (the Python code is not suitable for timing, only to see how it works)
**\<sarang\>** Anyway
**\<sarang\>** We're way over time
**\<sarang\>** Anyone have ACTION ITEMS for this week they want to share?
**\<sarang\>** (I find action items useful for me, to help prioritize and share those priorities)
**\<atoc\>** I will continue working with Surae. Hopefully I can share more next week.
**\<sarang\>** I have several... some additional work writing up comparisons of linkability definitions between a few papers, to get some timelock numbers (if it's seen as useful), and some data analysis relating to sublinear protocols
**\<sarang\>** Oh, and one additional note... the IEEE S&B conference is coming up later this year
**\<sarang\>** https://ieeesb.org/
**\<sarang\>** Both suraeNoether and I are on the program committee
**\<sarang\>** It's a great event, and is seeking papers
**\<sarang\>** If you have some work that could be worth sharing, consider writing it up formally and submitting
**\<atoc\>** Ok cool
**\<sarang\>** (you should note any conflicts of interest with the program committee if you feel they apply to you)
**\<sarang\>** I went to this event a while back, and it had great presentations (but was not streamed)
**\<sarang\>** Any other comments, questions, or final remarks before we adjourn?
**\<sarang\>** Normally there isn't so much to cover in one meeting; it's a great problem to have :D
**\<sarang\>** Going once...
**\<sarang\>** going twice...
**\<koe\>** I will be focusing on ZtM2 multisig, which may be done by next meeting in which case Ill start in on bulletproofs; and anything else that comes up, perhaps work on updating the fee priority multipliers for surge situations (emails with ArticMine)
**\<atoc\>** Last thing, I didn't realize IEE had Security and Privacy on Blockchain. That's pretty cool.
**\<sarang\>** I'm happy to help with bulletproofs koe; I have a branch for it in my ZtM repo
**\<sarang\>** atoc: it's a great event
**\<koe\>** all in good time :)
**\<sarang\>** I'm very happy to be asked to be on the committee :)
**\<sarang\>** OK, thanks to everyone for attending, even though we went over the usual time
**\<atoc\>** Yeah that's awesome!
**\<sarang\>** Logs will be posted shortly to the GitHub issue
**\<atoc\>** It was good. There was a lot of material.
**\<sarang\>** Discussion can of course continue
**\<sarang\>** (I just need a stopping point for the posted logs!)

218
_posts/2020-01-29-mrl-meeting.md Normal file
View File

@ -0,0 +1,218 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-01-29
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Let's go ahead and get started with GREETINGs
**\<sarang\>** Hello
**\<ArticMine\>** Hi
**\<RingSize937\>** v Greetings
**\<Isthmus\>** Heyo
**\<koe\>** greetings
**\<Insight\>** hello
**\<atoc\>** Hi
**\<sarang\>** Let's continue with ROUNDTABLE, where anyone is welcome to share research topics of general interest (and discuss any questions arising from them)
**\<sarang\>** Since there was so much to discuss last week, I'll try to keep the discussion focused to the extent possible, for clarity
**\<sarang\>** I have a few brief things to mention
**\<sgp\_\>** hello
**\<sarang\>** First, I wanted to better understand the effects of including hidden timelocks in CLSAG signatures, and worked up a version of 3-CLSAG in C++ for performance tests
**\<sarang\>** Including timelocks would negate the verification time advantages of an MLSAG-CLSAG transition
**\<sarang\>** but would still give size benefits over MLSAG
**\<sarang\>** A similar approach would work in Triptych, so I extended the Triptych test code to 3-Triptych for this purpose
**\<sarang\>** And, just for completeness, updated the Triptych preprint on IACR to a general d-LRS construction
**\<sarang\>** Here is the 3-CLSAG test code, for those interested: https://github.com/SarangNoether/monero/commit/db33d18bb889043c4bdea6d8582ffe2f6c581d28
**\<sarang\>** And the 3-Triptych concept code: https://github.com/SarangNoether/skunkworks/commit/f7581a385d72baa3dbb60c83e8d856a9335bec1f
**\<sarang\>** And the updated Triptych preprint: https://eprint.iacr.org/2020/018
**\<sarang\>** I also found a very minor change to make in the existing CLSAG test code
**\<sarang\>** Finally, suraeNoether and I have been doing more security model stuff
**\<sarang\>** Any questions on these items from anyone?
**\<koe\>** not directly for sarang, but at Isthmus regarding timelock; what is the prevalence of non-zero timelock for non-coinbase tx?
**\<Isthmus\>** Absurdly prevelant
**\<koe\>** whether or not to include encrypted time lock depends in part on how much use it actually gets
**\<koe\>** used
**\<sarang\>** Yeah, and I'm not formally advocating for it at this point; only curious about the implications
**\<Isthmus\>** I think our options are to remove the silly timelock field (It's just an arbitrary integer memo field currently) or encrypt it.
**\<koe\>** I like that it's a straightforward application of concepts already used in Monero
**\<sarang\>** Yeah, conceptually it's really neat
**\<Isthmus\>** Will we be the first privacy coin to roll it out?
**\<Isthmus\>** I expect that it will become industry standard
**\<sarang\>** Does Zcash offer such functionality?
**\<sarang\>** (I have not checked)
**\<sgp\_\>** no clue
**\<Isthmus\>** I don't think so, but not 100% confident
**\<ArticMine\>** ZCash has serious scaling issues
**\<sarang\>** Anyway, whether or not Zcash does it should not be the determining factor IMO :)
**\<sarang\>** Merely curious
**\<Isthmus\>** Oh wait. Zcash inherited nLockTime from Bitcoin
**\<Isthmus\>**
**\<Isthmus\>** I'mma fish out their information leaks too
**\<Isthmus\>** And OP\_CLTV
**\<sarang\>** If implemented, it would make the most sense to bundle the timelock range proofs with the existing Bulletproofs
**\<sarang\>** So this means the sum of timelock-enabled inputs (all inputs, if mandatory) and outputs is restricted
**\<koe\>** for Triptych, what are the steps between now and considering it for replacing RingCT?
**\<sarang\>** Formal review, a determination about its effects on multisig (particularly on compute-limited hardware), a decision on Triptych vs something like RCT3
**\<sarang\>** I have not yet examined how easy it would be to include timelocks in RCT3 with their security model
**\<ArticMine\>** ^ ... and estimated recommended tx size for Triptych
**\<sarang\>** Also note that, as I think I mentioned last week, it would not make sense to deploy hidden timelocks with MLSAG due to the poor scaling
**\<sarang\>** (though technically possible)
**\<koe\>** agreed
**\<sarang\>** Anyway, I want to make sure others have time to speak as well
**\<sarang\>** Who else wishes to share research topics?
**\<Isthmus\>** Zebra network stack looks interesting, potential applications in Monero?
**\<sarang\>** I saw that yesterday!
**\<sarang\>** Blag post about it: https://www.zfnd.org/blog/a-new-network-stack-for-zcash/
**\<sgp\_\>** cool, will check out
**\<sarang\>** And a corresponding forum post (not much activity there yet): https://forum.zcashcommunity.com/t/a-new-network-stack-for-zcash/35870
**\<sarang\>** It's from Zcash Foundation research
**\<Isthmus\>** Monero maintains a single state across all the peers, right?
**\<sarang\>** That's a good question, and I don't know the answer
**\<sgp\_\>** ping vtnerd
**\<sarang\>** I had thought so, but not confident in that
**\<hyc\>** not even sure what that means. single state? what is included in that state?
**\<hyc\>** there is an aggregate state for bandwidth limiting
**\<hyc\>** but sync info is per-connection
**\<Isthmus\>** Oh so maybe we already take the Zebra approach?
**\<Isthmus\>** It seems pretty elegant.
**\<sarang\>** Isthmus: did you have other topics you wanted to bring up as well?
**\<hyc\>** "Unlike zcashd, which maintains a fixed number of outbound connections, we attempt to connect to as many peers as possible, subject to resource limits "
**\<hyc\>** this approach will be troublesome for them, since they use levelDB/rocksDB for storage
**\<hyc\>** lvelDB/rocksDB requires thousands of file descriptors for its storage.
**\<hyc\>** that competes with the demand for socket descriptors
**\<sarang\>** Interesting... worth bringing up as a question on the forum?
**\<sarang\>** One of the developers (Henry) opened the thread
**\<hyc\>** not from me. I have no interest in helping zcash project
**\<sarang\>** ok
**\<Isthmus\>** I'm trying to make the unlock time plot, but my laptop is struggling with the 1.5 GB data set
**\<hyc\>** they should have already known by now that their DB choice is inappropriate for a network service that uses lots of connections, but it seems they haven't discovered that yet
**\<sarang\>** Isthmus: no rush!
**\<sarang\>** In the meantime, koe: did you wish to address anything in particular?
**\<koe\>** yes muahaha
**\<koe\>** not technically research, my roadmap has been cleaned up a bit; in particular I want to get opinions on item koe\_11, which would enable view-only wallets to know when owned outputs have been spent; also item koe\_9 which would allow all wallet implementations to more or less deprecate pre-RingCT transaction versions
**\<koe\>** https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf
**\<hyc\>** koe\_11 sounds like a high priority
**\<koe\>** also, sarang helped me work up a decentralized CoinJoin-esque protocol (temporarily named JoinMo), which is available as chapter 9 of current ZtM2 draft
**\<koe\>** https://www.pdf-archive.com/2020/01/29/zerotomoneromaster-v1-0-21/zerotomoneromaster-v1-0-21.pdf
**\<koe\>** chapter 10\*
**\<sarang\>** I like the JoinMo approach of using per-participant shared secrets to obscure the input-output mapping
**\<koe\>** also, rbrunner at one time investigated OpenBazaar integration, and ran into some roadblocks, so my 'research' has been engineering solutions to those problems, which should be available next week
**\<sarang\>** I'm giving extra scrutiny to the specifics around SAG/LSAG since the keys are per-output only
**\<sarang\>** I was thinking about the implications of using a separate keyset for inputs as well
**\<sarang\>** (keys = per-join participant keys, I mean)
**\<koe\>** however, OpenBazaar integration would likely entail a large update to the code-base, to optimize communication rounds
**\<koe\>** moreover, multisig in general should be updated to comply with suraeNoether's paper on the subject
**\<sarang\>** Yes
**\<Isthmus\>** Somewhat related to item 10, I'm still concerned about any blockchain observer being able to identify which transactions do not include any outputs to subaddresses.
**\<Isthmus\>** n3ptune and I will make a plot of subaddress adoption over time : -)
**\<Isthmus\>** But ideally that should not be possible.3
**\<sarang\>** Also yes :)
**\<sarang\>** It's been suggested before to standardize on some form of per-output keys for this purpose
**\<sarang\>** but it never gained traction
**\<sgp\_\>** koe: nice list! koe\_9 may be controversial since spending pre-rct would stand out more, no?
**\<atoc\>** Yeah looks like a nice list koe
**\<koe\>** it already stands out like a sore thumb
**\<koe\>** but that sort of problem will exist for RingCT as well, since spending ancient outputs is always somewhat unusual
**\<koe\>** and my suggestion is to start using pre-ringct outputs as decoys as well
**\<hyc\>** If we told everyone to sweep them to themselves, would that also be too obvious? you could assume that every txn with pre-RCT inputs is going back to its sender
**\<koe\>** so gamma select over entire site of outputs
**\<koe\>** set
**\<sgp\_\>** koe: do we currently only select rct randomly as decoys?
**\<koe\>** yes, and coinbase (not sure if pre-ringct coinbase are included)
**\<koe\>** coinbase are included as decoy in normal tx, which is where this idea comes from
**\<sgp\_\>** then this actually makes spending pre-rct slightly less suspicious, no?
**\<sarang\>** And the handling of coinbase outputs is by no means solved
**\<Isthmus\>** This is 80% a joke: We implement Koe\_9 and sgp\_coinbase\_only rings, \*but\* require each and every one to include N coinbases and M pre-ringCT transactions, for fixed consensus parameters N and M
**\<sarang\>** sgp\_: the distribution tail falls fast
**\<sgp\_\>** sarang: indeed, but it's near-zero better, not near-zero worse I think
**\<sarang\>** Yes, but does provide slightly more information (amount)
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/R26YQwiJ/image.png
**\<Isthmus\>** ^ which is hilarious, because all of these would hypothetically unlock at HEIGHT 2 and HEIGHT 12 back in 2014, IIRC what mooo said
**\<sarang\>** Due to the non-standard handling of that field, you mean?
**\<sarang\>** (which should be standardized anyway)
**\<sgp\_\>** Isthmus: hmm, I would need to see a lot more info on how many people actually spend pre-rct (suspected) compared to coinbase. My intuition leans no
**\<ArticMine\>** So include a single pre ring CT fake if the real output is not pre ring ct
**\<Isthmus\>** @sarang: Yes, currently, 3 things are being put in the unlock field:
**\<Isthmus\>** https://www.irccloud.com/pastebin/0Y87gTTq/
**\<Isthmus\>** Argh sorry
**\<Isthmus\>** Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks"
**\<Isthmus\>** Large integers like "1980000", presumably to be interpreted as block heights
**\<Isthmus\>** Very large integers like "1578561720", presumably to be interpreted as unix timestamps
**\<sarang\>** yup
**\<atoc\>** I am working on a first version implementation of xmr-btc atomic swap in Rust
**\<atoc\>** more info here: https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf
**\<sarang\>** atoc: did you identify a suitable zkp?
**\<sarang\>** Aside from things like the handling of non-compliant participants etc., the zkp of hash/log preimage was not specified
**\<atoc\>** the paper proposes two transactions for each token
**\<sarang\>** yep
**\<atoc\>** is there is a zkp not specified I will look at it. So far I have just gotten some initial stuff implemented
**\<atoc\>** however I have not gotten to the swap part yet
**\<atoc\>** for the implementation, I have read through the paper and it seems sounds
**\<atoc\>** sound\*
**\<sarang\>** Yeah, you'll notice there's a requirement for a particular proof that a hash preimage and discrete log preimage are equal in equal knowledge
**\<sarang\>** Something trustless like Bulletproofs could be used for this, with a suitable circuit
**\<atoc\>** I see
**\<sarang\>** The BP paper had data on such a circuit, but I was specifically told it was for testing only and was not yet suitable for any kind of deployment
**\<atoc\>** I will take a look at that
**\<atoc\>** We will need it. Perhaps we can see if that circuit works okay, and if not hopefully we can look at ways to improve.
**\<sarang\>** koe: thanks for that roadmap writeup; it's nice to see many suggestions put together in one place
**\<sarang\>** It might be useful to open research-lab issues for those that require ongoing discussion
**\<sgp\_\>** I still advocate for those two mining pool-related proposals btw :)
**\<atoc\>** sarang I send you a link to my repo once I push some changes
**\<sarang\>** even though most discussion happens on IRC
**\<atoc\>** I will send\*
**\<sarang\>** Thanks atoc
**\<atoc\>** You can take a look and I would like to get your feedback on it
**\<sarang\>** Happy to help
**\<sarang\>** Thanks for taking a look at that
**\<atoc\>** (y)
**\<koe\>** sure I can put on research github; was just wondering if koe\_11 should go on main repo's issues
**\<atoc\>** Np, it seems interesting. This week I was just l familiarizing myself with different atomic swap techniques i.e off-chain and on-chain
**\<atoc\>** And looking at the dalek library in Rust
**\<sarang\>** koe: I'd say anything that requires ongoing unsolved research is definitely suitable for research-lab
**\<sarang\>** But I don't dictate the scope of issues!
**\<sarang\>** OK, we have about 10 minutes left (there's another meeting taking place at 19:00 UTC for the Konferenco)
**\<koe\>** ok can put them up there
**\<sarang\>** Any research topics that have not yet been brought up, and should be?
**\<atoc\>** sarang btw have you considered publishing your list?
**\<sarang\>** Of topics I am personally working on? Not really, it's more to help organize my own work
**\<atoc\>** The private list that you had of research topics that need attention.
**\<sarang\>** I should open issues for them as well
**\<sarang\>** TBH github issues for research are not used as well as they could be
**\<atoc\>** Yeah I think it would be could to have a public list to look through as important topics for Monero that need attention
**\<sarang\>** Since so much of the discussion happens on IRC in real time
**\<atoc\>** yes indeed
**\<sarang\>** But at least those issues could be used as a central posting location
**\<atoc\>** I currently go back to the logs, but that list was helpful.
**\<sarang\>** I don't want people to have to scour IRC logs
**\<sarang\>** Sure, I'll make some issues
**\<sarang\>** We should clear out old issues as well, or request updates
**\<nioc\>** peanut gallery here. Now that suraeNoether 's matching project is complete (?) or nearly so, what is the plan to use it going forward ?
**\<atoc\>** 'scouring IRC logs' - story of my life :')
**\<sarang\>** nioc: good question for suraeNoether!
**\<sarang\>** He has also been working on LRS security models lately
**\<sarang\>** (which are a blocker for CLSAG review)
**\<sarang\>** OK, let's move to ACTION ITEMS for the time being (discussion can of course continue after we formally adjourn)
**\<sarang\>** I am writing up some material on transaction proofs/assertions, and writing up new code for a proposed InProofV2 and OutProofV2
**\<sarang\>** As well as security model updates, some work on proof rewinding for data storage, and some odds and ends
**\<sarang\>** Anyone else?
**\<atoc\>** my action item: mkW my private .git repo (of atomic swap implemntation) public on Githuv
**\<sarang\>** neat
**\<atoc\>** Github\*
**\<koe\>** my action items: multisig and escrowed-marketplace protocol writeup, possibly start bulletproof study if time permits
**\<sarang\>** BPs for the ZtM writeup?
**\<Isthmus\>** I want to make a website where you can type in a stealth address (or list of them) and see what future transactions have used them as ring members
**\<Isthmus\>** But need a little bit more backend work before that is ready
**\<koe\>** at the very least studying it
**\<Isthmus\>** I think the concerning part will be seeing the outputs that have been used in no subsequent rings, and thus have a known spend state and no plausible deniable for spendedness
**\<sarang\>** Let me know if you have any particular questions that I may be able to answer
**\<koe\>** of course :)
**\<sarang\>** Any other action items, or final comments before we adjourn?
**\<sarang\>** (from anyone)
**\<koe\>** actually spoiled my writeup from several months ago in the latest ztm2 draft whoops
**\<sarang\>** It's great to see so much research lately into so many different areas of interest from so many people :D
**\<sarang\>** Gets tough to keep up with everything
**\<sarang\>** Which is a great problem to have, in some sense
**\<sarang\>** Anyway, thanks to everyone for attending; we are now adjourned!

200
_posts/2020-02-05-mrl-meeting.md Normal file
View File

@ -0,0 +1,200 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-02-05
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, let's get started
**\<sarang\>** Logs from this meeting will be posted to the agenda issue shortly after the meeting
**\<sarang\>** First, GREETINGS
**\<sarang\>** hello
**\<sgp\_\>** hello
**\<suraeNoether\>** good mroning
**\<UkoeHB\_\>** hiya
**\<sarang\>** On to ROUNDTABLE, where anyone is free to share interesting research
**\<sarang\>** I'll go first, since I have a small assortment of things
**\<sarang\>** I worked up code and examples for doing hidden data storage within Bulletproofs and Triptych, suitable only for the prover
**\<Isthmus\>** I,m kinda here, but on a conference call
**\<sarang\>** Several ongoing projects/issues have been moved to monero-project/research-lab issues for comment and discussion
**\<sarang\>** The CLSAG code on my monero fork (clsag-plumbing branch) has been cleaned up; thanks to UkoeHB\_ for helpful suggestions and comments
**\<sarang\>** It includes, among other things, hash function domain separation that we hope to roll out elsewhere for a more robust overall codebase
**\<sarang\>** There is also CLSAG Python sample code showing how to do signer index extraction in a clever way, which I assume UkoeHB\_ may wish to discuss when he shares
**\<sarang\>** I've written up material for ZtM about transaction proofs/assertions
**\<sarang\>** And have worked up some new C++ code that updates transaction in/out proofs to have correct Schnorr challenges
**\<sarang\>** (still need to write tests for this)
**\<sarang\>** That's my update; any particular questions before the baton is passed?
**\<suraeNoether\>** quick question: iirc you had done work on encrypted timelocks
**\<sarang\>** yes
**\<suraeNoether\>** i've been chatting with both isthmus and TheCharlatan about them
**\<suraeNoether\>** do you have any notes prepared any place for later reading?
**\<sarang\>** On what in particular?
**\<suraeNoether\>** alternatively: can we schedule a discussion in this room that will end up in the logs for later this week?
**\<sarang\>** Sure
**\<sarang\>** Let's table for now, and address at the end
**\<suraeNoether\>** if we implement them regardless of if we are using mlsag, clsag, or triptych, there's going to be a cost. i want to see how it's all going to fit into future monero dev
**\<suraeNoether\>** word, word, i can go next
**\<sarang\>** OK, go ahead suraeNoether
**\<suraeNoether\>** last week i spent a lot of time on CLSAG and linkable ring signatures security definitions
**\<suraeNoether\>** there are a lot of definitions out there and they don't all relate to each other in a clean taxonomy, and it wasn't clear which ones we needed to use, and so on
**\<suraeNoether\>** so i started writing this rather large technical note summarizing all this with the intention of writing a second paper about it, but sarang and i have decided to merge the two into a new draft
**\<suraeNoether\>** the reason is that even definitions of unforgeability miss absolutely critical stuff becuase they are taken from "ring signatures" and mapped over to "linkable ring signatures" wholesale without regard for linking properties
**\<suraeNoether\>** so now the paper will be proposing a new definition of unforgeability specifically for linkable ring signatures that subsumes more than one security definition, and this is going to set the standard for a few years on how unforgeability is considered for all applications of linkable ring signatures.
**\<suraeNoether\>** this is good news(tm) for MRL
**\<Isthmus\>** sweet
**\<UkoeHB\_\>** congrats :)
**\<suraeNoether\>** thanks :D
**\<sarang\>** It makes the preprint all the more valuable
**\<suraeNoether\>** In addition to that, I have been preparing my talk for the Blockchain Tech Symposium at the Fields Institute in two weeks, and debugging my matching code.
**\<suraeNoether\>** i'm extremely grateful to the peer reviewer who "gently" pointed us towards the backes' paper actually
**\<sarang\>** Having both improvements to security models \_and\_ a new construction seems to be the gold standard these days
**\<suraeNoether\>** they did us more of a favor than maybe they realized
**\<suraeNoether\>** my work for the week will include finishing up this new draft of CLSAG, and to begin large-scale data collection on matching
**\<sarang\>** Thanks suraeNoether
**\<sarang\>** Any questions for suraeNoether?
**\<UkoeHB\_\>** if you want more CLSAG work, it's possible to increase the number of linkable keys up to the total number of pub keys considered :p
**\<sarang\>** Sure, but that's not useful for our particular application
**\<sarang\>** which is why we didn't consider it
**\<UkoeHB\_\>** I believe there was an earlier question from nioc about matching
**\<UkoeHB\_\>** for suraeNoether
**\<nioc\>**<2A> my question is, what is the status of the matching project and how will is be used going forward to help select an appropriate ringsize?
**\<sarang\>** ^ was the question
**\<suraeNoether\>** ah, great question: the matching project is \*what appears to be\* a single-line bug away from correctly generating simulated ledgers. it already appears to generate correct confusion matrices; once this bug is cleared up, it's a matter of executing a big block of code for a large period of time to get all the sample data, and then analyzing the data that's dumped to file.
**\<suraeNoether\>** so... if this bug, just like all the others, is a hydra, then I don't have a good answer, but i suspect i've narrowed down the problems to the source
**\<UkoeHB\_\>** Is the purpose of the matching project to produce the ledgers?
**\<suraeNoether\>** there are several purposes, but here's the main thing
**\<suraeNoether\>** we want to estimate how well an adversary can do at finding the "real" history of a monero ledger, given some hints (like it's a KYC exchange)
**\<suraeNoether\>** i have a method of computing a maximum likelihood estimate of the real history given some obscured ledger, and all that code works
**\<suraeNoether\>** and i have a method of taking an estimate and comparing it to the ground truth, producing a confusion matrix, and all that code works
**\<suraeNoether\>** i have a simulator that generates simulated ledgers, and the vast majority of that simulator is working just fine, too
**\<suraeNoether\>** the origin of the project came from the idea of developing a game-theoretic description of traceability on the monero ledger: you hand me an obscured ledger and some hints, I hand back to you my best guess, and then success is judged by you comparing the best guess to the ground truth you kept from me the whole time
**\<suraeNoether\>** so, the hope is: graph performance against ring size, and see if getting larger than 11 is a waste of space/time or not
**\<suraeNoether\>** in the meantime, we hope to also get good data for zcash-style ledgers, so that we can actually rigorously compare the two ledgers against each other, instead of tweeting at each other about fragility
**\<suraeNoether\>** but that last bit is farrrrr down the line
**\<Isthmus\>** Oh yea, I just remembered that ginger and I talked about generating synthetic blockchains forever ago https://github.com/insight-decentralized-consensus-lab/CryptoNote-Blockchain-GAN/issues/1
\<
**\<sarang\>** OK, any follow-up questions on this?
**\<suraeNoether\>** unfortunately, i've not worked on matching since mid-January because CLSAG's security models are critically important
**\<sarang\>** and CLSAG needs to get out the door
**\<sarang\>** Anything else to share, suraeNoether?
**\<sarang\>** Does anyone else wish to share relevant or interesting research?
**\<Isthmus\>** I'm taking a break from blockchain logs analysis to do some chat log analysis, analyzing recurring logical fallacies in this space
**\<suraeNoether\>** Nope
**\<suraeNoether\>** isthmus lol really?
**\<sarang\>** ?
**\<Isthmus\>** Yeah, actually doing a formal analysis
**\<suraeNoether\>** Isthmus: if you are, i have a friend to hook you up with at the university of exeter
**\<sarang\>** This channel in particular?
**\<sarang\>** Or more broadly in cryptography?
**\<Isthmus\>** Somewhat broady
**\<Isthmus\>** There's 7 common ones that show up in -lab
**\<sarang\>** go on...
**\<Isthmus\>** But they break down into combinations of red herrings and something that is \*similar\* to the slippery slope argument, but not quite the same and I'm still nailing down its technical logical structure
**\<suraeNoether\>** dude, please elaborate
**\<Isthmus\>** Like when we're debating fixing a tractable privacy leak, and somebody points out that there are other privacy leaks
**\<UkoeHB\_\>** :O
**\<suraeNoether\>** ah yeah
**\<suraeNoether\>** or comparing everything to 50% attack costs
**\<Isthmus\>** Another one is the hashrate code control fallacy
**\<suraeNoether\>** ?
**\<Isthmus\>** Confusing a 51% attack on longest chain with a 51% attack on the code
**\<Isthmus\>** This came up a few weeks ago actually
**\<suraeNoether\>** aaaah
**\<suraeNoether\>** i smell some medium articles
**\<Isthmus\>** Like why should we bother working on the protocol and code, when one day, somebody might run their own version on a bunch of their own miners
**\<sarang\>** Based on what you've analyzed so far, any particular recommendations to avoid such flaws in discussion/thinking?
**\<Isthmus\>** That one can be disproven by contradiction
**\<Isthmus\>** If 50% of BTC hashrate moved to BCH, does that make BCH the official bitcoin?
**\<suraeNoether\>** "why should we patch little leaks in info here and there" styled privacy nihilism/despair
**\<Isthmus\>** Oh shit, I gotta be in a meatspace meeting
**\<Isthmus\>** ciao!
**\<sarang\>** -\_\_-
**\<sarang\>** Very interesting stuff
**\<Isthmus\>** Erm, not by contradiction. I mean by example demonstrating absurdity
**\<sarang\>** We have plenty of time left... does anyone else wish to share anything?
**\<UkoeHB\_\>** lol
**\<suraeNoether\>** lol "i'm going to use machine learning to watch all of your conversations and find out who repeats fallacies most zealously BAIII GOTTA GO GRAB A FREE SLIZE OF 'ZZA FROM THE CORPORATE OVERLORDS" amiright
**\<UkoeHB\_\>** Here's mine. Worked on write-ups of different ideas -\> now Research repo Issues, with good feedback from sarang improving viewspent approach. TxTangle (aka my monero coinjoin protocol) is mostly done and just needs questions answered about network-layer anonymity. Current draft of ZtM2 is here https://www.pdf-archive.com/2020/02/05/zerotomoneromaster-v1-0-23/zerotomoneromaster-v1-0-23.pdf and current
**\<UkoeHB\_\>** ‘koe’s Ideas’ is here https://www.pdf-archive.com/2020/02/05/moneroideaskoe020520/moneroideaskoe020520.pdf
**\<sarang\>** Yeah, the original view/spent idea was broken, but there's a better approach
**\<sarang\>** It ties in with the CLSAG index extraction that I mentioned earlier
**\<sarang\>** If the signer generates all non-signing scalars via a PRNG `s\_i := H(seed,i)` (with appropropriate seed data), then it can be asserted privately what the signing index is
**\<sarang\>** It removes the need to add anything to the chain, and hence is good for indistinguishability
**\<sarang\>** I dig it, provided the UX is sufficient for reasonable use cases
**\<UkoeHB\_\>** yeah if view key can regenerate those scalars, it can know when an output has been spent with certainty
**\<UkoeHB\_\>** of course, it only works if tx author generates scalars like that
**\<sarang\>** The problem is still that it's opt-in, so even an accidental use of a non-participating wallet ruins the account balance computation for good
**\<sarang\>** So you'd have to be super-clear about presenting that to the user
**\<sgp\_\>** hmm
**\<sarang\>** Of course, a wallet could be doing that right now for all we know
**\<sarang\>** it's non-consensus and can't be detected if done properly anyway
**\<UkoeHB\_\>** it does leave open questions about data stored by nodes, since signature scalars are pruned; perhaps only full nodes, or view-spent enabled nodes can be used
**\<sarang\>** IMO that's a completely reasonable trade-off
**\<sgp\_\>** sounds reasonable to me too
**\<UkoeHB\_\>** it also may greatly increase data transmitted to view-only wallets by remote nodes
**\<sarang\>** Bloating the network for optional functionality benefitting only a single user seems unnecessary
**\<sarang\>** But this approach means you can run a full node (good for the network) and have the functionality for your wallets safely
**\<sgp\_\>** UkoeHB\_: I think that's a good thing to point out but probably isn't a showstopper
**\<UkoeHB\_\>** might need to receive a gigabyte of data to read through a year's worth of tx
**\<suraeNoether\>** hmmm
**\<suraeNoether\>** i'm a little worried about this in the following sense
**\<sgp\_\>** I still think that is okay for view-only wallets
**\<suraeNoether\>** you are selecting the non-signing scalars deterministically from a PRNG
**\<sgp\_\>** anyone using them for critical stuff, or viewing multiple wallets, should run their own node
**\<suraeNoether\>** one thing we all know about schnorr signatures is that if nonces are selected deterministically, it's possible to extract the private keys
**\<suraeNoether\>** at least, under certain constraints
**\<sarang\>** suraeNoether: yes, which is why seed selection is very important
**\<suraeNoether\>** so my question is
**\<sarang\>** UkoeHB\_ and I discussed this a bit already earlier
**\<suraeNoether\>** if the seed is chosen from a high entropy distribution and kept secret, it's computationally hard to detect that these are computed deterministically
**\<suraeNoether\>** i would prefer a method that is more than computationally hard
**\<sarang\>** Presumably the seed is a combination of the view secret key, the index, the key image, etc.
**\<sarang\>** suraeNoether: how would that even work?
**\<sarang\>** Data extraction requires that only the designated parties be able to construct the "expected" output value
**\<suraeNoether\>** pfeh, we use PRNGs because statistical RNGs don't really exist :P so ... it wouldn't
**\<sarang\>** Well, right now we operate on the assumption that the user has access to something behaving as an RNG
**\<sarang\>** this moves to an honest-to-goodness PRNG
**\<sarang\>** (and has to)
**\<sarang\>** You can't do data extraction with a true RNG AFAICT
**\<suraeNoether\>** that... is... true.
**\<sarang\>** Anyway, this is an interesting topic that could be useful for a future release
**\<sarang\>** but has subtle aspects to seed selection and UX that need further review
**\<sarang\>** Let's move on, for the sake of time
**\<sarang\>** Any other topics you wish to share, UkoeHB\_?
**\<UkoeHB\_\>** well, I hope people can leave feedback on the repo issues
**\<sarang\>** Yes, please do
**\<sarang\>** Much easier than only doing IRC comments =p
**\<UkoeHB\_\>** sorted TLV is probably most important for next hardfork
**\<sarang\>** TBH that's probably going to be better for -dev discussion
**\<sarang\>** More of an engineering question than a math question :)
**\<UkoeHB\_\>** true
**\<sarang\>** I'd bring it up at a dev meeting, or just in -dev whenever
**\<sarang\>** Get a sense of the work involved
**\<UkoeHB\_\>** ok
**\<sarang\>** I know people have brought up tx\_extra parsing before, and it's a hot topic
**\<sarang\>** Does anyone else wish to discuss other research topics?
**\<UkoeHB\_\>** ah, CLSAG section was added to ZtM2 for anyone curious
**\<sarang\>** excellent
**\<suraeNoether\>** uh i saw vtnerd's push on dandelion++
**\<sarang\>** Yes
**\<sarang\>** Most excellent
**\<sarang\>** It's on my list to review later this week
**\<sarang\>** Speaking of which
**\<sarang\>** Let's briefly move to ACTION ITEMS to respect everyone's time
**\<sarang\>** I'll be reviewing the D++ PR, working through some additional transaction assertion/proof stuff, updating sublinear tx protocol MPCs, and writing up examples of RCT3 hidden data storage
**\<suraeNoether\>** yes. Mine: Finish CLSAG, start collecting matching data. Also, of primary importance: provide updates twice or three times a day in here until both of these are finished.
**\<sarang\>** As well as getting tests written for the new tx in/out proofs
**\<suraeNoether\>** i'll be reviewing the D++ pr also once those are both off my plate
**\<sarang\>** Yes, looking forward to the CLSAG stuff (will review when ready)
**\<sarang\>** Anyone else have action items planned for the week?
**\<UkoeHB\_\>** To do: focus on multisig all week, hopefully finish txtangle (need a network anonymity expert for advice, any takers?)
**\<sarang\>** The most knowledgeable person is probably vtnerd
**\<sarang\>** I hear if you say his name 3 times, he gets 3 separate notifications...
**\<sarang\>** =p
**\<sarang\>** Any last-minute items, questions, etc. before we formally wrap up?
**\<sarang\>** (I'm happy to discuss timelocks after we adjourn)
**\<sarang\>** Going once...
**\<sarang\>** twice...
**\<sarang\>** Adjourned! Thanks to everyone for attending; logs will be posted shortly on the agenda issue

116
_posts/2020-02-12-mrl-meeting.md Normal file
View File

@ -0,0 +1,116 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-02-12
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Greetings!
**\<ArticMine\>** Hi
**\<UkoeHB\_\>** Hiya
**\<n3ptune\>** Hello
**\<UkoeHB\_\>** Thanks selsta I'll look
**\<sarang\>** I suppose we can move to roundtable discussion
**\<sarang\>** Who wishes to share interesting research?
**\<sgp\_\>** hello
**\<n3ptune\>** Something quick from NRL
**\<n3ptune\>** We've been looking at some results regarding the extra field in transactions. We have one thing to share today
**\<n3ptune\>** Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated:
**\<n3ptune\>** https://usercontent.irccloud-cdn.com/file/Xf1uZRsZ/image.png
**\<n3ptune\>** (Sorry there is an uncorrected typo: "Unencrypted Included x Encrypted Absent" should be 232980 (not 232972) and "Unencrypted Absent x Encrypted Included" should be 1904765)
**\<sarang\>** ^ moneromooo etc.
**\<UkoeHB\_\>** It's actually not 'mandatory', just part of the core wallet's behavior
**\<UkoeHB\_\>** As jtgrassie liked to insist :p
**\<sarang\>** Nothing stops a wallet from simply including a fixed default value either
**\<sarang\>** (can't enforce "uniformly random" in that way)
**\<sarang\>** Once again touches on the idea of extra parsing/enforcement
**\<sarang\>** Are there other indications of what non-standard software it might be?
**\<sgp\_\>** 17% is a good amount that didn't update properly
**\<sgp\_\>** do they save slightly on fees?
**\<n3ptune\>** That's a good question, we didn't look into the transactions but there may be other things going on that make more of a fingerprint
**\<sarang\>** Thanks n3ptune
**\<n3ptune\>** Thanks! Just sharing these numbers today
**\<sgp\_\>** if the fees are lower, I can see someone setting it up this way if they process many transactions
**\<moneromooo\>** Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ?
**\<n3ptune\>** I can check
**\<UkoeHB\_\>** n3ptune: the core wallet only creates encrypted payment IDs for all 2-output tx, would you mind looking into the distinction (proportion encrypted IDs with 2-output and \>2 output)\>
**\<UkoeHB\_\>** moneromooo: was the dummy encrypted payment ID also since 1.98e6?
**\<n3ptune\>** Another good question
**\<moneromooo\>** I think before.
**\<moneromooo\>** It was merged late january 2019.
**\<moneromooo\>** Yes, it was included in the release for that height.
**\<Isthmus\>** I don't think we looked at long PID
**\<Isthmus\>** Sorry, here is the updated figure
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/t5ozuruh/image.png
**\<n3ptune\>** ? Long PID = Unencrypted PID, yes
**\<moneromooo\>** Yes.
**\<Isthmus\>** Oh, I was thinking integrated
**\<Isthmus\>** Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning
**\<Isthmus\>** But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- )
**\<sarang\>** How ominous
**\<UkoeHB\_\>** it might just mean more significant implementations exist than just core, which might be good news also
**\<sarang\>** Well, not if the result is fingerprinting
**\<UkoeHB\_\>** n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period)
**\<n3ptune\>** The numbers should be for non-coinbase only
**\<sarang\>** Well, in the interest of time, shall we continue? Hopefully we can get more detailed data, which can help any future decisions about parsing
**\<sarang\>** Thanks for the data Isthmus and n3ptune
**\<n3ptune\>** Thx, I'll check out those questions
**\<sarang\>** Other research to discuss or share?
**\<sarang\>** UkoeHB \_ ?
**\<sarang\>** suraeNoether ?
**\<sarang\>** OK, I can discuss a few short items
**\<UkoeHB\_\>** ok, I sketched out a light node proposal https://github.com/monero-project/research-lab/issues/69 pls leave your thoughts there if interested
**\<sarang\>** Ah ok, nvm
**\<sarang\>** go ahead UkoeHB\_
**\<UkoeHB\_\>** ZtM2 I got through multisig and the draft of that chapter is done, started working on escrowed marketplace chapter which will be done by next meeting https://www.pdf-archive.com/2020/02/12/zerotomoneromaster-v1-0-25/zerotomoneromaster-v1-0-25.pdf
**\<UkoeHB\_\>** thats all from me
**\<Isthmus\>** @UkoeHB\_ just scoped that proposal last night, looks like great stuff
**\<sarang\>** Looks to be similar to SPV structure?
**\<UkoeHB\_\>** possibly, idk anything about SPV
**\<sarang\>** I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych
**\<sarang\>** Finished code and tests for new transaction proofs
**\<sarang\>** did some Dandelion++ review
**\<gingeropolous\>** yay triptych!
**\<sarang\>** Wrote some code to demo spend/non-spend status proofs that have been discussed previously
**\<sarang\>** and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol
**\<ArticMine\>** Any size indications for triptych?
**\<sarang\>** Individual transactions? Sure, that's been available for some time
**\<sarang\>** https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
**\<sarang\>** Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that
**\<sarang\>** since different tx protocols imply different tradeoffs as I/O structure changes
**\<ArticMine\>** It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed
**\<ArticMine\>** Which is very reasonable given the mixin privacy gains
**\<UkoeHB\_\>** why increase?
**\<sarang\>** It depends on what protocol (if any) is chosen, what parameters used, etc.
**\<UkoeHB\_\>** ah i see, for 1024 ring size
**\<ArticMine\>** I am saying with N = 512 or 1024
**\<gingeropolous\>** what are the hurdles for tryptich? besides me wanting to spell it wrong all the time
**\<ArticMine\>** If this goes through, by the time it makes it to the main chain the drop in block reward would easily cover the fee increase
**\<ArticMine\>** If we increase the penalty free block weight to 400000 bytes
**\<sarang\>** gingeropolous: no peer review yet
**\<sarang\>** I also need to know the practical drawbacks to the more complex multisig operations
**\<sarang\>** especially on lower-powered devices
**\<sarang\>** They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols
**\<ArticMine\>** We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth
**\<gingeropolous\>** ugh. what, for those silly hardware wallets?
**\<sarang\>** Well, anything that would need to participate in multisig
**\<sarang\>** The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc.
**\<UkoeHB\_\>** would multi-tryptich work with any kind of join protocol?
**\<sarang\>** Unclear. It's still in the early stages
**\<UkoeHB\_\>** before this meeting gets wrapped up, I am curious about the state of discussion around Monero's difficulty algorithm; zawy12 seems to have done a lot of research on the topic of difficulty algos https://github.com/zawy12/difficulty-algorithms/issues/50
**\<UkoeHB\_\>** and suraeNoether was at one point doing research on that area
**\<UkoeHB\_\>** apparently Monero's algorithm is quite bad, relatively speaking
**\<sarang\>** Interesting; I had seen some of their earlier work, but not this summary
**\<sarang\>** The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance
**\<sarang\>** (which isn't really part of the design choice)
**\<sarang\>** Worth a read, now that we have the link
**\<sarang\>** UkoeHB\_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus?
**\<UkoeHB\_\>** I feel Ive made my case for it, although Isthmus says they are working on a big comprehensive report so at that time I may recapitulate
**\<sarang\>** Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree
**\<sarang\>** It may come down to questions of efficiency and "someone needs to write it", but who knows
**\<UkoeHB\_\>** enforcing it should be less than 100 lines of code IMO
**\<sarang\>** Sounds like someone is volunteering :D
**\<sarang\>** Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning?
**\<sarang\>** Righto; thanks for attending, everyone

166
_posts/2020-02-19-mrl-meeting.md Normal file
View File

@ -0,0 +1,166 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-02-19
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, let's get started with the meeting
**\<sarang\>** GREETINGS
**\<sgp\_\>** hello :)
**\<n3ptune\>** Hello
**\<needmonero90\>** I caught the meeting!
**\<needmonero90\>** I would like to note that the meetings are not listed in the calendar
**\<needmonero90\>** idk if thats intentional
**\<sarang\>** Which calendar?
**\<UkoeHB\_\>** Hi
**\<sarang\>** And how are meetings applied to it?
**\<ArticMine\>** Hi
**\<sarang\>** Meeting times/agendas are always listed as meta repo github issues
**\<sarang\>** Anyway, does anyone wish to begin the ROUNDTABLE with research topics of interest?
**\<UkoeHB\_\>** Yes
**\<sarang\>** Take it away UkoeHB\_
**\<UkoeHB\_\>** I finished designing an escrowed marketplace 'protocol' which hopefully solves issues encountered by rbrunner in his openbazaar integration analysis. Also, multisig and txtangle have been finalized.
**\<UkoeHB\_\>** https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf
**\<sarang\>** Neat
**\<UkoeHB\_\>** Finally, I had an idea for reducing minimum fee variability, and likewise for putting antispam directly in the protocol instead of relying on minimum fee
**\<sarang\>** Are you seeking analysis on those?
**\<UkoeHB\_\>** Which is issue #70
**\<UkoeHB\_\>** They are open for comments any time anywhere
**\<UkoeHB\_\>** Ah and sarang provided a draft for a tx knowledge proof chapter
**\<sarang\>** aye
**\<UkoeHB\_\>** (not really my research :p)
**\<sarang\>** Heh, it's more of a summary of what's in the codebase (and some changes)
**\<sarang\>** I look forward to reading the update draft you linked
**\<UkoeHB\_\>** A number of topics here are lonely and want attention btw https://github.com/monero-project/research-lab/issues
**\<UkoeHB\_\>** \end
**\<sarang\>** Thanks UkoeHB\_
**\<sarang\>** Any questions or comments on those topics from anyone?
**\<ArticMine\>** Yes
**\<sarang\>** Please go ahead!
**\<ArticMine\>** I have taken a look at issue 70
**\<ArticMine\>** It actually has serious implications
**\<ArticMine\>** When the LT medium increases substantially
**\<ArticMine\>** I do have an idea for a solution
**\<ArticMine\>** Very preliminary at this stage
**\<ArticMine\>** As for an interim fix
**\<ArticMine\>** The est is to pay the high or at least normal fee for escrows that are expected to last past the next hard fork
**\<ArticMine\>** I will have comments on the issue in the next two weeks
**\<ArticMine\>** end
**\<sarang\>** Thanks ArticMine
**\<sarang\>** Any other questions/comments from the topics presented by UkoeHB\_?
**\<sarang\>** Righto
**\<sarang\>** I'll share a few things
**\<sarang\>** First, the Stanford Blockchain Conference is happening right now (and the next couple of days), and has streaming available: https://cbr.stanford.edu/sbc20/
**\<sarang\>** Second, I did some math/code related to multiparty stuff for next-gen protocols
**\<sarang\>** Third, I worked on code and write-ups for transaction proofs, both for an updated PR and for inclusion in Zero to Monero for better documentation
**\<sarang\>** Fourth, I used chain data from n3ptune and friends to do better estimates of the cumulative effects of next-gen protocols
**\<sarang\>** both in chain growth and verification time
**\<sarang\>** Major caveat: these assume the same input/output distribution as the current chain, and are \_estimates\_only\_
**\<sarang\>** and apply to post-bulletproof chain data only
**\<sarang\>** https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png
**\<sarang\>** ^ this link shows the total chain growth estimates for various protocols with varying ring size
**\<sarang\>** namely, from 16 to 1024 in powers of 2 (lines for visual aid only)
**\<UkoeHB\_\>** Sarang would you mind adding an indicator for MLSAG and CLSAG at the 11 ring size 'point'? For reference
**\<sarang\>** Sure, let me grab that data from my spreadsheet
**\<sarang\>** hold please
**\<UkoeHB\_\>** Or the super steep slope from 11 to 20 lol that goes off that chart
**\<sarang\>** Heh, I had that data but didn't include it since it's crazy linear
**\<sarang\>** I'm running the N=11 code for MLSAG/CLSAG, which I don't have handy
**\<sarang\>** Anyway, I'll pull up the time data while we wait
**\<sarang\>** https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png
**\<sarang\>** ^ verification time estimate for \_group\_operations\_only\_ at varying ring sizes
**\<UkoeHB\_\>** I think it's interesting that all these protocols/signature schemes are similar size on the small end
**\<sarang\>** All the verification times are linear (up to a logarithmic term due to multiexp)
**\<UkoeHB\_\>** Where is tryptich multi hiding?
**\<sarang\>** It's underneath Triptych-single
**\<sarang\>** They're essentially indistinguishable
**\<selsta\>** Does Triptych single have advantages over multi?
**\<sarang\>** RCT3-multi suffers due to input padding requirements that still have a linear verification effect
**\<sarang\>** selsta: a complete soundness proof :)
**\<sarang\>** Update on MLSAG/CLSAG size estimates...
**\<UkoeHB\_\>** Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable
**\<sarang\>** At N=11, MLSAG for that chain range is 7.84 GB, while CLSAG is 5.84 GB
**\<sarang\>** (the actual size of that chain range is 7.9 GB)
**\<sarang\>** https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png
**\<sarang\>** ^ same time data, zoomed in
**\<UkoeHB\_\>** Perfect thanks :) are time estimates for CLSAG/MLSAG available?
**\<sarang\>** Heh, just writing that out
**\<sarang\>** I have very early estimates on that, which are tricky since multiexp doesn't apply, and hashing is nontrivial
**\<sarang\>** MLSAG N=11 estimate is 29.9 hours for that chain range (but I have \_not\_ double-checked it)
**\<ArticMine\>** What hardware was used for the verification time calculations?
**\<sarang\>** It's a single core on a 2.1 GHz Opteron machine, with a bonkers amount of RAM
**\<sarang\>** I would rely on the timing data only for comparisons, not absolute values
**\<ArticMine\>** age of CPU?
**\<sarang\>** I am still in the process of getting CLSAG data, which requires additional test code
**\<sarang\>** It's a gen-3 Opteron, if that's what you mean
**\<UkoeHB\_\>** Is there a way others could run the same tests?
**\<sarang\>** Again, only estimates using performance test code
**\<sarang\>** For next-gen protocols, it's quite easy
**\<ArticMine\>** Yes great it does give an idea thanks
**\<sarang\>** Well, somewhat easy
**\<sarang\>** You need to get multiexp performance timing data and use a linear interpolation that you plug into the simulator
**\<sarang\>** For MSLAG/CLSAG you need to run more operation performance data
**\<sarang\>** This is the simulator, which is still WIP: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png
**\<sarang\>** But again, it's tricky to do comparisons between MLSAG/CLSAG and the next-gens
**\<Isthmus\>** (drive by data)
**\<sarang\>** Wow, that's quite low
**\<Isthmus\>** Oh yeah, the numbers are one thing. But moreso, we should all be more alarmed that analyzing something like this is possible for an outside observer
**\<Isthmus\>** ;-)
**\<sarang\>** Yep, and has certainly been a topic of interest!
**\<Isthmus\>** It's a privacy risk to use subaddresses right now...
**\<Isthmus\>** Anyways, I gotta bounce, sorry to spam n run
**\<sarang\>** OK thanks for sharing the data Isthmus
**\<sarang\>** Another good reminder that I/O structure reveals some information about subaddress use
**\<sarang\>** Since Isthmus had to leave, were there other questions/comments on the data that I shared above?
**\<sarang\>** UkoeHB\_: if you want to run tests as well, let me know after the meeting and I can let you know how to get the numbers you'll need
**\<UkoeHB\_\>** My computer is quite weak, was just asking for viewers :)
**\<sgp\_\>** sarang: can you remind us on the plans to fix this subaddress thing?
**\<sarang\>** ah ok
**\<sarang\>** Requiring separate tx keys per output is a good idea, but IIRC didn't have a huge amount of support when last brought up
**\<sarang\>** FWIW the size data that I presented for next-gens assumes a separate tx key per output
**\<UkoeHB\_\>** Is that necessary for the protocols?
**\<sarang\>** For the proving systems, you mean? No, not at all
**\<sarang\>** They don't care how you get signing keys
**\<UkoeHB\_\>** Can you estimate the amount of additional pub key data? Num outs \* 32 and num tx \* 32?
**\<sgp\_\>** sarang: why did it not get support now? complexity? size? verification time?
**\<sarang\>** My numbers for MLSAG/CLSAG include separate tx keys too!
**\<sarang\>** Also: n3ptune's dataset includes the pubkey counts
**\<sarang\>** So I could run that separately for a more direct count
**\<UkoeHB\_\>** With only 3% subaddress adoption, the difference is likely on the order of 100MB
**\<UkoeHB\_\>** Or 2% of total size I think
**\<sarang\>** that's probably a good order-of-magnitude estimate
**\<sarang\>** But IIRC scanning requires checking all pubkeys
**\<sarang\>** So either there needs to be a specified correlation, or there's added complexity in scanning
**\<UkoeHB\_\>** I think it costs ~1GB for 30mill pub keys btw
**\<sarang\>** I think moneromooo had a better idea of the impacts, when it was brought up earlier
**\<sarang\>** FWIW I think it's a good idea unless it's very compelling not to due to complexity
**\<sarang\>** OK, we're running up to the one-hour mark...
**\<sgp\_\>** obviously without this change, the impacts are quite negative for network privacy........
**\<sarang\>** It's differentiated data, but it doesn't leak \_which\_ outputs are subaddress-destined
**\<sarang\>** (not that I'm saying that's a good reason to keep the current approach)
**\<UkoeHB\_\>** It's quite a lot of unused data, I'm a bit skeptical
**\<sgp\_\>** just reveals "one of this outputs goes to a subaddres?"
**\<sarang\>** UkoeHB\_:?
**\<UkoeHB\_\>** A lot of dummy data
**\<sarang\>** sgp\_: it reveals the number of subaddress outputs
**\<UkoeHB\_\>** sarang all it reveals is at least one of the outputs must be to a subaddress
**\<sarang\>** Doesn't it reveal the total number of sub outs?
**\<UkoeHB\_\>** No
**\<sarang\>** orly
**\<UkoeHB\_\>** How would it?
**\<UkoeHB\_\>** Number of additional pub keys always equals number of outs
**\<UkoeHB\_\>** Even if nonsubaddress
**\<UkoeHB\_\>** How is the CLSAG paper going?
**\<sarang\>** Hmm, for some reason I thought otherwise; noted
**\<sarang\>** I'm still waiting for suraeNoether
**\<sarang\>** He wanted to continue working on his ideas for the security model
**\<sarang\>** So unfortunately I am not the one to ask
**\<sarang\>** OK, is there anything else of interest to share?
**\<sarang\>** (Would be a good idea to continue discussing this after meeting, or on an issue, to keep it alive)
**\<sgp\_\>** definitely need an issue for it
**\<sarang\>** All righty then; thanks to everyone for attending today
**\<sarang\>** We are adjourned!

197
_posts/2020-02-26-mrl-meeting.md Normal file
View File

@ -0,0 +1,197 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-02-26
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Hello all, and welcome to the weekly research meeting
**\<sarang\>** First, GREETINGS
**\<sarang\>** Hi
**\<UkoeHB\_\>** hi
**\<ArticMine\>** hi
**\<sarang\>** \*others
**\<cankerwort\>** Peanut gallery quickly checking in to ask what the latest is on return addresses. Last I remember there was an idea to include a subaddress in the tx as a return address. Is that still being being considered?
**\<sarang\>** It's always possible to include in tx\_extra, which is not consensus
**\<sarang\>** and there was a space-minimizing proposal as well
**\<sarang\>** AFAIK no one has coded such a thing yet
**\<sarang\>** As always, there's a consideration of how optional behavior is bad for indistinguishability
**\<sarang\>** Let's go ahead and start the ROUNDTABLE
**\<sarang\>** Does anyone have research topics of interest to share?
**\<sarang\>** I'll go ahead, then
**\<sarang\>** First, the Stanford Blockchain Conference was held this past week
**\<sarang\>** Here is a link to the schedule and recordings of talks for each day: https://cbr.stanford.edu/sbc20/
**\<sarang\>** Second, a small PR on hash function domain separation was updated, and could always use extra eyes for review: https://github.com/monero-project/monero/pull/6338
**\<sarang\>** Third, I made some updates to the structure of CLSAG signature verification code... by reducing the modularity of the signature verification routine to specifically include some commitment offsets, I was able to shave about 5% off the verification time
**\<sarang\>** See this branch for details: https://github.com/SarangNoether/monero/tree/clsag-optimized
**\<Isthmus\>** Any particular talks that you recommend from SBC?n
**\<sgp\_\>** hello everyone, catching up on the chat so far
**\<sarang\>** Florian's talk about Monero and Zcash side-channel analysis on Wednesday's stream is very good
**\<sarang\>** All of session 4 on Wednesday is interesting
**\<sarang\>** As is session 5 on Thursday
**\<sarang\>** Fourth, I worked on similar improvements for MLSAG... however, this is trickier, since verification requires particular byte-representation hash inputs for backwards compatibility
**\<sarang\>** The results for that aren't great: https://github.com/SarangNoether/monero/tree/mlsag-optimized
**\<Isthmus\>** Ah I loved that paper
**\<sarang\>** Yeah, kudos to Florian and collaborators for great work and responsible disclosure
**\<sarang\>** Finally, another researcher contacted me with an idea for atomic swaps that might remove the need for a SHA-256 preimage proof
**\<sarang\>** We're still working out the details, but it's an intriguing idea for which the necessary building blocks already exist
**\<sarang\>** More information as we work on it!
**\<UkoeHB\_\>** interesting, haven't heard from atoc in a while who was looking into that
**\<sarang\>** Yeah... I don't want to provide more information until the researcher and I have discussed it (as a courtesy to them)
**\<sarang\>** sorry
**\<Isthmus\>** Respecting privacy is good ;- )
**\<sarang\>** Anyway, those are my updates! Mostly code updates and testing
**\<sarang\>** Does anyone else wish to share research of interest?
**\<UkoeHB\_\>** thanks to sarang 's initial draft, tx knowledge proofs chapter is done (wip tag is off) for ztm2
**\<UkoeHB\_\>** https://www.pdf-archive.com/2020/02/26/zerotomoneromaster-v1-0-30/zerotomoneromaster-v1-0-30.pdf
**\<UkoeHB\_\>** chapter 9
**\<Isthmus\>** Nice!
**\<Isthmus\>** "An Axiomatic Approach to Block Rewards" https://arxiv.org/pdf/1909.10645.pdf
**\<UkoeHB\_\>** sgp\_ may be interested in section 9.3 for audits
**\<UkoeHB\_\>** reader beware various things arent implemented and are just theoretical
**\<sarang\>** Yeah, the idea for a general audit framework is super interesting to me
**\<sarang\>** and could be useful to reduce confusion about what proof types provide what information
**\<sarang\>** Right now, it's sort of ad-hoc
**\<cankerwort\>** ZtoM will contain unimplemented features and ideas from the roadmap?
**\<sarang\>** Isthmus: that paper is on my literature review list!
**\<UkoeHB\_\>** also made some updates/fixes to minimum fee change idea https://github.com/monero-project/research-lab/issues/70 @ArticMine
**\<sgp\_\>** thanks for sharing! I will see if I can get feedback on it
**\<UkoeHB\_\>** cankerwort part 2 'extensions' contains unimplemented features; saying they are roadmap is quite ambitious
**\<sarang\>** One thing to note about the audit idea from UkoeHB\_ is that it requires proofs applying to \_all\_ transactions for which a given output appears in rings
**\<sarang\>** which I suspect may require substantial engineering effort (as a guess)
**\<UkoeHB\_\>** also proofs for every single tx in the chain
**\<UkoeHB\_\>** for each normal address you own
**\<sarang\>** but the benefits of this approach are worth investigation
**\<sarang\>** IMO
**\<UkoeHB\_\>** audits arent trivial for sure
**\<cankerwort\>** Should be called "ZtoM... and beyond!"
**\<UkoeHB\_\>** lol yeah
**\<sgp\_\>** I'm familiar with some people who do Monero audits for businesses so I'll try and get their feedback
**\<sarang\>** UkoeHB\_: fortunately the proofs are all off-chain anyway
**\<sarang\>** So efficiency is much less of a consideration
**\<UkoeHB\_\>** Id refrain from expecting anything in ZtM that isnt implemented to actually get implemented. They are just ideas
**\<sarang\>** UkoeHB\_ and I had discussed this very topic earlier... about the intended purpose of ZtM
**\<sarang\>** e.g. protocol spec, or something else
**\<Isthmus\>** I think that flavoring it with the latest ideas and discussions will convey the lively R & D, provide helpful context, and leave an important historical record
**\<Isthmus\>** In 10 years I want to sit down and nostalgically re-read the old "future work" sections
**\<sarang\>** heh
**\<sarang\>** Anything else to share UkoeHB\_?
**\<sarang\>** (just to keep the meeting on track)
**\<UkoeHB\_\>** dont think so
**\<sarang\>** Cool, thanks for the update
**\<sarang\>** Isthmus: you had chimed in earlier
**\<sarang\>** Did you wish to continue with anything else?
**\<Isthmus\>** Life has been hectic, so haven't had many Monero moments lately.
**\<Isthmus\>** However
**\<Isthmus\>** n3ptune was doing some data QC/QA and noticed that in a recent preliminary figure I had missed 100 recent transactions with no payment id (encrypted nor unencrypted)
**\<Isthmus\>** But that's a minor difference
**\<sarang\>** How recent is "recent"?
**\<sarang\>** If you recall
**\<Isthmus\>** Probably this version, but idk
**\<Isthmus\>** It's only like a 0.5% change over the previously presented data
**\<Isthmus\>** I've been working on a little design thought experiment, but it's still rough and maybe more -lounge appropriate
**\<Isthmus\>** Otherwise, nothing else to report, that I can think of
**\<sarang\>** Got it, thanks
**\<sarang\>** I know suraeNoether said he was unavailable, but would provide an update later today on his recent work
**\<sarang\>** He's been working on some interesting updates to linkable ring signature security models
**\<sarang\>** I've been reviewing those as well
**\<sarang\>** Does anyone else wish to share ongoing research?
**\<sarang\>** Either specific to something mentioned here, or more generally
**\<sarang\>** If not, we can move on to QUESTIONS
**\<sarang\>** OK, looks like no questions so far
**\<sarang\>** Let's move to ACTION ITEMS before closing the meeting
**\<ArticMine\>** Feasibility of child pas for parent in Monero (child has parent as one of the mixins)
**\<sarang\>** ?
**\<ArticMine\>** pays
**\<sarang\>** Can you elaborate, ArticMine ?
**\<ArticMine\>** In Bitcoin a tx in the tx pool has to low a fee
**\<sarang\>** "has to low a fee"?
**\<ArticMine\>** A second tx is sent using the tx with to low a fee as an input
**\<sarang\>** Sorry, I'm not following
**\<sarang\>** ah
**\<ArticMine\>** The miner miones both txs in a block
**\<ArticMine\>** In the Monero case the child has the tx output of the parent as one of the mixins
**\<ArticMine\>** can be real or fake
**\<sarang\>** What is the specific question you're getting to?
**\<Isthmus\>** Interesting interesting
**\<ArticMine\>** Can this e done in Monero
**\<ArticMine\>** be
**\<UkoeHB\_\>** oh is it about what can be done if a tx is stuck since its fee is too low?
**\<UkoeHB\_\>** e.g. make a new tx with more fee for it
**\<ArticMine\>** Yes this can e part of the toolkit
**\<ArticMine\>** be
**\<ArticMine\>** but in addition to what I am looking at with the fees, etc
**\<UkoeHB\_\>** we do have 10block lock time atm, so tx spending other tx output doesn't quite work, though there could be new rules around 'in the same block'
**\<Isthmus\>** I actually think this seems very plausible
**\<Isthmus\>** You wouldn't mine only the bump
**\<Isthmus\>** And once the transaction is mined, the bump is unnecessary
**\<Isthmus\>** The bump transaction should have exactly 2 outputs: a plaintext fee and an encrypted change output
**\<Isthmus\>** And reference the first transaction by hash
**\<UkoeHB\_\>** yeah
**\<sarang\>** hmm
**\<UkoeHB\_\>** Im wondering why not just remake the same tx
**\<UkoeHB\_\>** with more fee
**\<ArticMine\>** because of multi sig
**\<UkoeHB\_\>** ah yeah
**\<sarang\>** Huh, that's a very interesting question
**\<Isthmus\>** Oh, and only 1 bump per transaction
**\<Isthmus\>** You can broadcast more if you want, obviously
**\<Isthmus\>** But only one bump can be claimed by the miner
**\<Isthmus\>** So if you bump with 0.2 XMR then change your mind and send a 0.5 XMR bump, a miner would just ignore the smaller bump
**\<ArticMine\>** Yes
**\<ArticMine\>** but anyone can do the bump in Monero unlike Bitcoin
**\<cankerwort\>** Why "becauae of multisig"?
**\<Isthmus\>** You could design it either way: allow anybody to bump, or require a signature from the original sender to bump
**\<Isthmus\>** (one of the original senders)
**\<UkoeHB\_\>** sounds like it's possible, although would require protocol level changes (new transaction type, etc)
**\<midipoet\>** wouldn't being able to do that (child pays for parent) drastically decrease the overall cost of the chain reaction attack?
**\<ArticMine\>** You include the parent as one of the mixins
**\<Isthmus\>** @UkoeHB\_ I'm only here for the protocol level changes :- P
**\<cankerwort\>** Also the big bang attack presumably
**\<ArticMine\>** The miner does know if the parent is real or not
**\<UkoeHB\_\>** ArticMine I don't know if the parent needs to be a mixin, just include the parent tx hash as part of bump tx, an additional data field
**\<ArticMine\>** That does not mine the parent
**\<UkoeHB\_\>** It would be a new tx type
**\<UkoeHB\_\>** 'bump tx'
**\<ArticMine\>** Not really
**\<UkoeHB\_\>** RCTTypeBumpIt
**\<Isthmus\>** heh
**\<sarang\>** lol
**\<ArticMine\>** The point of child pays for parent is that in order to mine the child one has to mine the parent
**\<sarang\>** right
**\<sarang\>** But that seems straightforward to enforce, no?
**\<ArticMine\>** In Bitcoin that means spending the output of the parent in the child
**\<UkoeHB\_\>** I think you might get into weird 0-conf territory if can spend an output with 0-block lock time
**\<Isthmus\>** @cankerwort yeah, though as long as the bump density [XMR per kB] is higher than transaction density [XMR per kB] then they would effectively take up less space (be less effective) for a big bang attack
**\<UkoeHB\_\>** the 10block lock is there for a reason afaik
**\<UkoeHB\_\>** just willy nilly
**\<ArticMine\>** in Monero it means including it in the ring real or fake. The miner does no know
**\<Isthmus\>** Yeah, I think the "bump" transaction needs to be a new type with exactly [fee delta + change] outputs and a new field referencing the transaction hash of the transaction to be accelerated
**\<Isthmus\>** And everything is subject to the 10-block lock
**\<UkoeHB\_\>** or you could make it an optional field in normal tx type, to reduce complexity
**\<ArticMine\>** Both are mined in the same block so there is no issue with orphans
**\<sarang\>** UkoeHB\_: not in extra, right?
**\<sarang\>** for parsing etc.
**\<UkoeHB\_\>** no, unless we start enforcing it
**\<sarang\>** aye
**\<UkoeHB\_\>** interesting idea articmine
**\<cankerwort\>** Surely the delta could be as small as you like though? So it could be used to make big bang attack cheaper
**\<UkoeHB\_\>** big bang is about total block weight
**\<UkoeHB\_\>** still have to pay fee for bump tx too
**\<cankerwort\>** Ie you are adding 2 transactions for one fee?
**\<Isthmus\>** The fee in the bump has to cover both the weight of the bump itself and the original transaction
**\<cankerwort\>** Ah
**\<Isthmus\>** So if I have a 5 kB txn and a 2 kB bump, then the total fee has to incentivize the miner to include 7 kB
**\<ArticMine\>** Yes enough to provide an incentive the miner
**\<ArticMine\>** That is the point of child pas for parent also in Bitcoin
**\<sarang\>** Quick note that we should try to finish up soon, since Konferenco has a meeting in a few minutes
**\<ArticMine\>** pays
**\<sarang\>** May we quickly review action items, and then continue discussion?
**\<ArticMine\>** Yes of course
**\<sarang\>** I'll be working on some review for vtnerd's 64-bit operation code
**\<sarang\>** as well as some Triptych coding for timing purposes
**\<sarang\>** Others?
**\<sarang\>** OK, then let's formally adjourn for log posting purposes... please continue discussion!
**\<sarang\>** Thanks to everyone for attending

113
_posts/2020-03-04-mrl-meeting.md Normal file
View File

@ -0,0 +1,113 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-03-04
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** Let's start the meeting!
**\<sarang\>** First, GREETINGS
**\<sarang\>** hello
**\<sgp\_\>** hi
**\<sgp\_\>** [meta] I added the MRL meetings with reminders to the Google Calendar I have if you are ok using Google: https://calendar.google.com/calendar/embed?src=itmaraubkfoe4aq2oquoaogsuk%40group.calendar.google.com&ctz=UTC
**\<sarang\>** Does using that link leak any information to you? (presumably it leaks IP information to Google)
**\<sgp\_\>** not to me, just Google
**\<sarang\>** roger
**\<sarang\>** OK, continuing on
**\<sarang\>** Next up is the ROUNDTABLE
**\<UkoeHB\_\>** hi
**\<sarang\>** I've been getting the multi-input version of Triptych updated for posting to the IACR preprint archive
**\<sarang\>** as well as minor edits to the original preprint as I come across them
**\<sarang\>** Posting to IACR (with suitable caveats about non-standard cryptographic hardness assumptions) can increase the visibility of the idea, and hopefully encourage feedback
**\<sarang\>** It's pretty slow going, but progressing well
**\<sarang\>** Any particular questions on that before I pass the baton?
**\<sarang\>** OK, next up!
**\<sarang\>** Does anyone else have research of interest to share and discuss?
**\<Isthmus\>** Yo
**\<sarang\>** Hello Isthmus
**\<sarang\>** Did you wish to share anything, or just observing?
**\<Isthmus\>** I’ve been pretty busy in meatspace, sadly no time for data spelunking
**\<sarang\>** OK, no problem! Simply checking
**\<sarang\>** It's a fairly quiet day today anyway
**\<sarang\>** UkoeHB\_?
**\<sarang\>** suraeNoether?
**\<sarang\>** Others?
**\<Isthmus\>** Oh yes, actually
**\<sarang\>** ah ok
**\<sarang\>** carry on Isthmus
**\<Isthmus\>** Wait there’s too much traffic for voiced text, let me look back pewter in four minutes
**\<sarang\>** roger
**\<sarang\>** Someone else, then?
**\<UkoeHB\_\>** need about 10mins
**\<sarang\>** OK, in that case, let's pause the meeting for 10 minutes or so; I show the time is 18:12, so let's reconvene at 18:22 or so
**\<sgp\_\>** sarang: want to talk about Triptych naming at some point?
**\<sarang\>** That seems like a suitably off-topic idea during this break =p
**\<sarang\>** Right now, the multi-input Triptych preprint uses the name "Triptych-2"
**\<sarang\>** this is boring and not descriptive
**\<sarang\>** I am open to better naming ideas
**\<sarang\>** Note that I can revise the older paper if that's helpful (this has been done to add features and fix errors)
**\<hyc\>** what part of the original "triptych" is triple?
**\<sarang\>** The benefits of Triptych-2 are using a single proof for all spends (instead of separate proofs with commitment offsets), and handling balance assertions directly within the proof
**\<sgp\_\>** I originally recommended Triptyzk as a half joke, but part of me thinks it's a good idea
**\<hyc\>** Polyptych
**\<sarang\>** The idea was that the three parts to Triptych are signing keys, commitment keys, and linking tags
**\<sarang\>** Heh, a polyptic sounds like something a surgeon would remove :/
**\<UkoeHB\_\>** lmao
**\<sarang\>** FWIW there's basically no change to the SHVZK property or proof between the two versions
**\<sarang\>** They're almost identical
**\<sgp\_\>** that's partially why adding "zk" now makes no sense. It's more about proactively naming for the Twitter trolls/idiots
**\<UkoeHB\_\>** B-Triptych and E-Triptych for basic and extended
**\<sarang\>** Triptych Classic and New Triptych
**\<hyc\>** Triptych and Antikythera :P
**\<sarang\>** Just what we need; something equally hard to pronounce =p
**\<moneromooo\>** Technology so old nobody remembers how it works.
**\<hyc\>** yes... and indecipherable, and considered too advanced for its time
**\<kinghat\>** i havent been paying that close attention but have we "shelved" CLSAG?
**\<sarang\>** suraeNoether just told me he's now happy with the revised security model for CLSAG
**\<sarang\>** Nothing has changed with the algorithms themselves, apart from a small change to hash function inputs
**\<UkoeHB\_\>** it sounded like suraeNoether was considering advocating to skip CLSAG and go directly to next-gen in a year or two
**\<sarang\>** I disagree
**\<sarang\>** CLSAG is a straightforward change that's well understood
**\<kinghat\>**
**\<sarang\>** Anyway, he made very recent updates that I'll review (more on this during ACTION ITEMS) for IACR posting
**\<sarang\>** Anyway
**\<sarang\>** UkoeHB\_ and Isthmus both wanted to share some work
**\<selsta\>** Will CSLAG require a paid review?
**\<sarang\>** Nothing "requires" paid review
**\<selsta\>** for you to be comfortable with it
**\<sarang\>** But it's probably a good idea :)
**\<sarang\>** I'm very comfortable with the math
**\<Isthmus\>** Hm, upon more consideration, discussing it today might be the wrong order of operations
**\<Isthmus\>** Nothing pressing or dangerous
**\<sarang\>** The total estimate for math+code review by Teserakt was ~$15000 USD, which is quite reasonable IMO
**\<sarang\>** Isthmus: how so?
**\<sarang\>** Now you have everyone intrigued
**\<UkoeHB\_\>** happy to announce a final proofreading draft of ZtM2 is ready. Note that I decided not to go into Bulletproofs since it's frankly way too much detailed math to be worth it. Anyone who wants to learn bulletproofs should just read the original paper. https://www.pdf-archive.com/2020/03/04/zerotomoneromaster-v1-1-0/zerotomoneromaster-v1-1-0.pdf
**\<Isthmus\>** A poorly-framed thought experiment is worse than no thought experiment at all
**\<sarang\>** UkoeHB\_: great!
**\<sarang\>** Will this be renamed to 2.0 after review?
**\<sarang\>** Or will the title be incremented to "One to Monero" :D:D:D
**\<UkoeHB\_\>** Ill make a reddit post asking for proofreaders, and if anyone knows someone who wants to proofread go ahead and pass it around. Not much is likely to change between now and publication in ~1.5-2months. The proofreading period is 3 weeks.
**\<UkoeHB\_\>** I think Ill just remove the version number
**\<UkoeHB\_\>** maybe
**\<midipoet\>** UkoeHB\_: fair play
**\<sarang\>** Name them based on the most recent Monero version name?
**\<sarang\>** Anyway, great to hear the update is nearing completion
**\<hyc\>** Zero to Monero, Hero Edition
**\<UkoeHB\_\>** yes I want to meet the hero who reads the whole thing :)
**\<hyc\>** the more -ero suffixes in the title, the better :P
**\<sarang\>** Does anyone else wish to share research of interest?
**\<sarang\>** OK, we can move on to ACTION ITEMS, then
**\<sarang\>** I am completing the Triptych-2/NewTriptych/E-Triptych/etc. preprint for IACR posting
**\<sarang\>** and reviewing the (hopefully final) changes to CLSAG that I received from suraeNoether
**\<sarang\>** Anyone else?
**\<UkoeHB\_\>** proofreading, and listening to proofreader feedback if and when it appears; starting now will probably spend a lot less time with Monero as this project wraps up
**\<sarang\>** I think a reddit post is a great idea to encourage readers to take a look
**\<sarang\>** ZtM is such a valuable resource
**\<sarang\>** Short meeting today! But that's fine
**\<sarang\>** Any other questions, comments, etc. as we wrap up?
**\<sarang\>** All right! Let's adjourn
**\<sarang\>** Thanks to everyone for attending
**\<sarang\>** Logs will be posted shortly to the GitHub issue

177
_posts/2020-03-11-mrl-meeting.md Normal file
View File

@ -0,0 +1,177 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-03-11
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, let's begin the meeting!
**\<sarang\>** Agenda is here: https://github.com/monero-project/meta/issues/445
**\<sarang\>** Logs will be posted there after the meeting
**\<suraeNoether\>** good morning
**\<sarang\>** First on the list, GREETINGS
**\<sarang\>** hi
**\<sarang\>** Note that because of a recent time change for the United States and elsewhere, these meetings will take place at 17:00 UTC instead of 18:00 UTC
**\<ArticMine\>** hi
**\<Isthmus\>** heya sarang and artic
**\<sarang\>** I suppose we can move on to ROUNDTABLE
**\<sarang\>** Who wishes to share research topics of interest?
**\<vtnerd\>** hi
**\<UkoeHB\_\>** Hi
**\<suraeNoether\>** well
**\<suraeNoether\>** i want to give a brief two-part update
**\<sarang\>** Go ahead suraeNoether!
**\<suraeNoether\>** firstly, personally: i'm going to have to take a break from monero for a few weeks while i get this medical stuff figured out. importantly: i'm not stopping work. I just don't know how much time i can actually contribute practically.
**\<sarang\>** Oof, sorry to hear this. I hope everything goes well for you suraeNoether
**\<ArticMine\>** sorry to hear this. I hope all goes well
**\<suraeNoether\>** secondly: my research into matching is a hydra where fixing one bug is revealing handfuls of more bugs, and i'm getting super frustrated with it. this is particularly important work for a few reasons, but for right now i don't anticipate movement any time soon. one of the reasons that this has become so frustrating to me is that certain threats to monero that are going to become more likely over the
**\<suraeNoether\>** next several years to be presenting themselves that make the answers that lie within this work \*lower priority\* than other things. i mean this very specifically in the following sense
**\<suraeNoether\>** everyone should know that our anonymity reduces to something like the one-more decisional diffie hellman problem, and our unforgeability reduces to something like one-more discrete logarithm
**\<suraeNoether\>** both of these are known to not be hard for quantum adversaries, and while quantum computers are not yet practical...
**\<suraeNoether\>** it doesn't matter what ring size we use if china goes "manhattan project" on quantum computers and turns their resulting computing power on de-anonymizing privacy coins in secret.
**\<suraeNoether\>** my work on matching would give us answers to questions like "how large should ring sizes be \*assuming the underlying problem that our anonymity rests upon is hard to solve\*" but we know that this problem is only going to be hard over the short term
**\<sarang\>** FWIW such a "quantum adversary" could wreak havoc on basically the entire global internet
**\<suraeNoether\>** indeed ^ but that's in fact exactly all the more reason to become resistant to a quantum adversary sooner rather than later
**\<UkoeHB\_\>** How realistic is a quantum adversary?
**\<ArticMine\>** ^ I agree
**\<suraeNoether\>** if it takes 3 years to migrate to a quantum-secure system, and we hope something like clsag or triptych has a 3 year shelf life, then we should be looking at what will be practical 6 years from now
**\<sarang\>** In the shorter term, understanding the effects of ring size on matching-type analysis is useful for knowing how large to make ring size for a next-gen protocol
**\<Isthmus\>** Uhm
**\<Isthmus\>** Would an adversary with a quantum computer break ring signatures or just decrypt the transactions?
**\<suraeNoether\>** both: they can compute the discrete log of every one-time key and then they just own all of monero
**\<Isthmus\>** Yeah, I'd just do that.
**\<suraeNoether\>** yeah
**\<suraeNoether\>** so like
**\<sarang\>** Once you have key discrete logs, you can check key images
**\<suraeNoether\>** matching: important. investigating quantum-secure schemes: higher priority, even over a relatively short 3-year term
**\<suraeNoether\>** so every time i kill a bug in my matching code, i become more painfully aware: i'm fighting the wrong hydra
**\<sarang\>** I still think it's very valuable
**\<Isthmus\>** Yeah, we've been doing some quantum vs crypto experiments at Insight lately
**\<suraeNoether\>** long story short, i'm prsently working on a summary-of-knowledge of quantum-resistant RingCT-type protocols, 3 of which have been proposed in the past 3 years
**\<sarang\>** Otherwise, "bigger rings are better" is a qualitative statement
**\<suraeNoether\>** just for community education reasons
**\<suraeNoether\>** sarang: absolutely agreed
**\<sarang\>** My recent work on Triptych-2 and chain simulations shows, as expected, that ring size has a large effect on verification complexity
**\<UkoeHB\_\>** Can you also evaluate how realistic a quantum adversary is? I recall general skepticism of them ever materializing
**\<sarang\>** So choosing the smallest rings that do the job is important
**\<suraeNoether\>** UkoeHB\_: yeah, so basically here's a qualitative answer to that question
**\<Isthmus\>** We're already working on 5 [actual] qbits
**\<Isthmus\>** (Insight working on IBM equipment)
**\<Isthmus\>** Expecting this to scale in the next few years
**\<suraeNoether\>** you may recall the sensationalist headlines a few months ago: https://www.eurekalert.org/pub\_releases/2020-02/aps-teo022720.php
**\<suraeNoether\>** quantum supremacy is probably a bad term but
**\<suraeNoether\>** before these researchers did what they did, the \*fastest way to figure out what a quantum computer can do\* would be to \*simulate it on a classical computer\*
**\<sarang\>** Quantum supremacy is a poor metric for usefulness IMO
**\<sarang\>** Such problems are typically highly contrived
**\<suraeNoether\>** because of these guys' work, that is no longer the case: there now exist quantum computers that cannot be simulated more quickly than they can operate. this is a critical benchmark for scaling quantum
**\<Isthmus\>** @surae should I just loop in my quantum/crypto engineer for a few weeks, so you can focus on the matching hydra?
**\<Isthmus\>** They're already looking into the schemes, and would probably be happy to work on Monero
**\<suraeNoether\>** google's bristlecone has 72 qubits running
**\<suraeNoether\>** isthmus: let's set up a call for later this week
**\<vtnerd\>** well I have to say it ... quantum computers are BS, they just spin hyperbole but go nowhere. There was a discussion about this on metzdowd
**\<Isthmus\>** Given retroactive denonymization doesn't really matter if they're 5 or 15 years off, we gotta hustle to protect Monero users in 2020
**\<suraeNoether\>** do you mean like computers based on quantum principles will never work, vtnerd? can you clarify?
**\<suraeNoether\>** isthmus ^ bingo
**\<vtnerd\>** someone discussed the progress made on metzdowd. Its been very little over 25+ years
**\<vtnerd\>** the researchers have alwasy been just on the edge of making it a reality
**\<suraeNoether\>** okay well
**\<suraeNoether\>** the researchers into QC i've spoken with disagree
**\<suraeNoether\>** and that's an appeal to authority
**\<vtnerd\>** admitedly this isn't my expertise, but theres time tradeoffs investigating these QC resitistent systems
**\<suraeNoether\>** but i think it's absolutely silly to say that very little progress has occurred over 25 years, and it's even sillier to assume that no progress will be made ala cold fusion, and i think it's even sillier to propose that we, say, avoid quantum-secure implementations rather than looking into the costs and benefits and time horizons of implementing them
**\<vtnerd\>** and the one thing thats bizarre, is when someone builds a QC system, we basically ahve to reboot on general purpose computing projects, no? Like one year out are they even cracking crypto?
**\<suraeNoether\>** well, i don't want to take more time on this: my update is that i have to step back from monero for awhile, and i'm looking into RLWE-based ring signatures
**\<Isthmus\>** Y'all know the tech cycle. Many-year winters leads to the most exciting explosions. AI, crypto, quantum... the pattern repeats
**\<suraeNoether\>** i'll still be presenting at meetings and coming by and stuff
**\<suraeNoether\>** for folks who are interested, the wikipedia article on the timeline of quantum computing has lots of good info
**\<sarang\>** OK thanks suraeNoether
**\<sarang\>** I have a few things to share
**\<sarang\>** First, CLSAG
**\<sarang\>** I've completed review of suraeNoether's security model updates
**\<sarang\>** suraeNoether: I've left several Overleaf review comments for you
**\<sarang\>** Along with that, I migrated some recent CLSAG verification optimization code to moneromooo's branch, along with relevant unit and performance tests
**\<sarang\>** Saves about 5% on verification, which seemed worth it
**\<sarang\>** Relating to Triptych: I made a minor update to the original Triptych-1 preprint for readability, but also completed the Triptych-2 preprint
**\<sarang\>** Here is a link to the Triptych-2 preprint on Overleaf: https://www.overleaf.com/read/ynfkhykjfvrd
**\<sarang\>** I'd appreciate any review on it prior to posting to the IACR archive
**\<sarang\>** Unrelated to these, I've been catching up with literature review
**\<sarang\>** and, as a program committee member for the IEEE S&B conference, I'm reviewing submissions
**\<suraeNoether\>** i'll take a look at your comments and read through triptych 2: electric bugaloo
**\<sarang\>** Thanks suraeNoether
**\<sarang\>** IMO the CLSAG review is top priority
**\<selsta\>** Did you contact Teserakt?
**\<sarang\>** I'd like to wait on confirming a schedule until we have this paper done
**\<sarang\>** Otherwise we risk losing the availability again due to delays
**\<sarang\>** Anyone who wants to review the CLSAG optimizations can see this branch: https://github.com/SarangNoether/monero/commits/clsag-mooo
**\<sarang\>** Finally, my funding proposal needs feedback on GitLab before it's decided whether to open it: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/131
**\<sarang\>** That's all for me today
**\<sarang\>** Does anyone else wish to present, or have questions?
**\<suraeNoether\>** i propose that we fund sarang
**\<suraeNoether\>** but no
**\<suraeNoether\>** no questions
**\<Isthmus\>** I propose that we fund surae
**\<sarang\>** Heh, then leave a reaction or comment on gitlab!
**\<Isthmus\>** I've been wrestling with a weird conundrum
**\<sarang\>** Go on
**\<Isthmus\>** I'm thinking about modifying my wallet to only select decoys from transactions generated by the core wallet
**\<Isthmus\>** But then that in and of itself becomes a subtle heuristic
**\<sarang\>** Ah, so using fingerprinting to pick the most "standard" decoys?
**\<Isthmus\>** Not "most"
**\<Isthmus\>** Something either looks like the core wallet, or provably isn't
**\<sarang\>** Heh, yeah, it kicks the fingerprinting can slightly down the road
**\<Isthmus\>** I guess if almost everybody used only outputs generated by the core wallet, then it wouldn't be a heuristic to fingerprint me
**\<Isthmus\>** \*outputs that cannot be proven to have not originated from the core wallet
**\<Isthmus\>** ^ to be very specific
**\<sarang\>** got it
**\<Isthmus\>** Eh, I dunno. Don't really have a solution. It was just funny that I worked on it for a it before realizing that it becomes its own heuristic xD
**\<Isthmus\>** Anyways, nothing much from me. I've had about 20 minutes per week for Monero lately
**\<Isthmus\>** But in May, we're gonna have some long talks and clean house
**\<sarang\>** ?
**\<Isthmus\>** Have 7 heuristics that have now partitioned out upwards of 20 different implementations.
**\<Isthmus\>** Most of which I've shared in MRL already
**\<UkoeHB\_\>** 20 sounds like a lot
**\<UkoeHB\_\>** monero is really doing well if there are 20
**\<Isthmus\>** That's unfiltered for time.
**\<Isthmus\>** Going to clean it to recent blocks and see what's in the wild \*now\*
**\<sarang\>** So some might be updates to the same implementations?
**\<Isthmus\>** It's at least 3 right now,
**\<Isthmus\>** Yeah, that's why I'm not really sweating the 20
**\<Isthmus\>** I think it's 3-5 in current era
**\<Isthmus\>** Which is pleasantly(?) surprising
**\<Isthmus\>** But yea, with absolutely no time to work on it now, hard to put together a full writeup
**\<Isthmus\>** But will definitely circle back in the next 2 months
**\<sarang\>** Sounds good!
**\<sarang\>** Anyone else wish to share any research?
**\<UkoeHB\_\>** hi, ztm2 proofreading draft is updated (with feedback from sarang about bulletproofs, and also the clawback formula regarding tx weights) https://www.pdf-archive.com/2020/03/11/zerotomoneromaster-v1-1-1/zerotomoneromaster-v1-1-1.pdf
**\<UkoeHB\_\>** 2 more weeks for proofreading
**\<sarang\>** Good feedback so far overall?
**\<UkoeHB\_\>** also, looked into next-gen tx key image generation for multisig (sarang has a solution for it), and it seems like inversion key images wont greatly disrupt multisig transaction flows (especially escrowed markets, which is a big deal)
**\<UkoeHB\_\>** Not much feedback so far
**\<UkoeHB\_\>** But it's 152 pages so not surprising
**\<UkoeHB\_\>** that's all from me
**\<sarang\>** OK, let's move on to ACTION ITEMS for the next week or so
**\<sarang\>** I'll await final word on my CLSAG review notes
**\<UkoeHB\_\>** wondering if ArticMine has progress on fees
**\<sarang\>** Continue working on Triptych
**\<Isthmus\>** Why did it switch from 02 to 20?
**\<Isthmus\>** oops
**\<ArticMine\>** Yes I do
**\<Isthmus\>** ignore that
**\<sarang\>** Go ahead ArticMine!
**\<ArticMine\>** I am looking at making the penalty free one also dynamic and using the long term median to control it
**\<ArticMine\>** Also slowing down the fall in the long term median to match the constraint on the rise
**\<sgp\_\>** just got caught up
**\<ArticMine\>** So it does not go from say 3000000 bytes 300000 bytes in one shot
**\<ArticMine\>** The new dynamic penalty free one would track the long term median at say 20 - 25% of the long term median
**\<Isthmus\>** Ooh interesting
**\<ArticMine\>** This will provide predictable fee over time
**\<sarang\>** Will you have a specific proposal for this, intended for a network upgrade?
**\<ArticMine\>** The models I am looking at is a sharp drop, followed by a fiat banking crisis that creates a very sharp rise
**\<ArticMine\>** Yes
**\<sarang\>** OK, any final thoughts or topics before we wrap up this hour?
**\<suraeNoether\>** be kind to each other
**\<suraeNoether\>** just be excellent
**\<suraeNoether\>** you animals
**\<sarang\>** All right, thanks to everyone for attending. Adjourned!

141
_posts/2020-03-25-mrl-meeting.md Normal file
View File

@ -0,0 +1,141 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-03-25
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<sarang\>** hi
**\<seddd\>**: o/
**\<UkoeHB\_\>** hi
**\<SerHack\>** hi
**\<sarang\>** Moving on, then, to ROUNDTABLE
**\<sarang\>** Who wishes to share research of interest?
**\<ArticMine\>** Hi
**\<sarang\>** I can share a few things
**\<sarang\>** I've completed some formal peer review for the IEEE S&B proceedings
**\<sarang\>** and worked on analysis for a linkable ring signature construction in IACR 2020/333
**\<sarang\>** it claimed to be more efficient than CLSAG
**\<sarang\>** However, the numbers assumed an insecure key image construction
**\<sarang\>** The authors have already posted a revision, but it doesn't include numbers or new security proofs for the modified construction
**\<sarang\>** Besides this, here's an update on some other projects...
**\<sarang\>** For CLSAG, I am still waiting on the final go-ahead from suraeNoether, who is a coauthor on the paper
**\<sarang\>** I finished code optimization and made a PR to moneromooo's branch, which has some nice verification speedups
**\<sarang\>** For Triptych-1, its preprint has been updated at IACR 2020/018
**\<sarang\>** An MPC construction for key images is completed, and multisig/join analysis is still underway
**\<sarang\>** For Triptych-2, its preprint has been posted at IACR 2020/312
**\<sarang\>** Multisig/join analysis is still underway
**\<sarang\>** That's all for me
**\<sarang\>** Any particular questions or comments?
**\<nioc\>** how much verification speeedup for CLSAG?
**\<seddd\>**: Do you need any more eyes on the CLSAG PR?
**\<sarang\>** It's around 4-5%
**\<nioc\>** nice
**\<sarang\>** seddd: That would be welcome, once moneromooo integrates the new changes into the branch
**\<seddd\>**: Ok, let me know, and I'll review
**\<sarang\>** that'd be great
**\<moneromooo\>** I did, I can push.
**\<sarang\>** Oh excellent
**\<ArticMine\>** 4-5% reduction in size? Verification time?
**\<sarang\>** The only real changes from the paper's description is a modification to the public parameters that go into the challenge hashes, which allows for the speedup to happen
**\<sarang\>** ArticMine: verification time
**\<sarang\>** I didn't bother with generation stuff, since that's less important
**\<sarang\>** Size is identical
**\<sarang\>** The PR includes new performance tests with better direct comparison to MLSAG, if that's useful to anyone
**\<seddd\>**: moneromooo: link?
**\<ArticMine\>** So is this the version that is going for audit?
**\<moneromooo\>** Not yet.
**\<sarang\>** Presumably, but that's up to the audit workgroup
**\<moneromooo\>** I'm rebasing it to master now, then will run tests, then push, then post a link.
**\<sarang\>** moneromooo: excellent, then the CI workflow will operate properly
**\<seddd\>**: awesome, many thanks
**\<sarang\>** Any other questions for me?
**\<sarang\>** Or does anyone else wish to share research topics?
**\<seddd\>**: Mb but it involves pow of another coin, not sure appropriate
**\<sarang\>** Perhaps suited for after the meeting
**\<seddd\>**: Definitely
**\<selsta\>** who is the audit workgroup? sgp?
**\<sarang\>** sgp\_ has been working to coordinate
**\<sarang\>** As far as the CLSAG paper goes, if I don't hear from suraeNoether, eventually I suppose we'll just have to release the revised version without him
**\<sarang\>** But I would prefer not to do that, since he's a coauthor
**\<seddd\>**: Is suraeNoether not around rn?
**\<sarang\>** He hasn't enabled public viewing on the overleaf version, and I don't have access rights to do that unfortunately
**\<sarang\>** No, he is not around right now AFAIK
**\<seddd\>**: k
**\<sarang\>** Well, to respect everyone's time, I suppose we can move to ACTION ITEMS
**\<UkoeHB\_\>** update from me: proofreading is extended to this weekend as comments are trickling in at the last moment :p; I have received several good feedbacks so far
**\<sarang\>** Ah ok, go ahead UkoeHB\_
**\<UkoeHB\_\>** current proofreading version is here https://www.pdf-archive.com/2020/03/22/zerotomoneromaster-v1-1-2/zerotomoneromaster-v1-1-2.pdf
**\<UkoeHB\_\>** that's all
**\<sarang\>** Great, thanks
**\<sarang\>** My action items are to complete my proofreading of Zero to Monero (it's been delayed; my apologies)
**\<sarang\>** and to work on some Triptych-2 MPC math
**\<sarang\>** Anyone else?
**\<hyc\>** "research only, not for production use" inb4 sumo releases it and claims to be first
**\<UkoeHB\_\>** oh right, I made a small update to Janus mitigation
**\<sarang\>** hyc: ?
**\<sgp\_\>** UkoeHB\_: cool,, what?
**\<seddd\>**: lul hyc
**\<hyc\>** sorry, catching up from a couple days ago
**\<UkoeHB\_\>** https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784
**\<seddd\>**: imagines sumo as yt commenter: "FIRST"
**\<sgp\_\>** UkoeHB\_: none of that is implemented correct?
**\<sarang\>** Off topic, folks!
**\<UkoeHB\_\>** correct
**\<seddd\>**: srry
**\<sarang\>** IIRC, the last time Janus mitigations were discussed in a dev meeting, there seemed to be mixed support
**\<UkoeHB\_\>** my action item is to go through all proofreading comments, and then this weekend finalize a for-publication version
**\<UkoeHB\_\>** sarang part of that seemed to be related to exactly how many pub keys and janus base keys it would require
**\<UkoeHB\_\>** full Janus mitigation would require: 1 Janus base key per transaction, #pub keys = #outputs for ALL transactions (not just tx with subaddresses as is the case now)
**\<sarang\>** yep
**\<seddd\>**: sounds like a lot of overhead, is that one of the main objections?
**\<UkoeHB\_\>** there is partial Janus mitigation, where normal addresses and subaddresses are split up; in other words, don't mitigate linking of normal addresses with subaddresses; that way only tx with subaddresses would need the janus base key
**\<UkoeHB\_\>** however, even with partial mitigation a lot more subaddress tx would be revealed as subaddress, as there are currently some optimizations that hide subaddress tx among normal tx
**\<UkoeHB\_\>** while with full migitation, normal address tx and subaddress tx would be universally indistinguishable
**\<UkoeHB\_\>** which iirc sarang was in favor of even outside of Janus
**\<seddd\>**: +1 for the latter
**\<sarang\>** Yeah, encouraging/enforcing indistinguishability is useful
**\<UkoeHB\_\>** the main objective is solving the Janus attack
**\<UkoeHB\_\>** which is currently undetectable
**\<sarang\>** yes
**\<seddd\>**: so what are the opposing arguments?
**\<sarang\>** Transaction size is increased
**\<sarang\>** that's a big counterargument
**\<sarang\>** (literally)
**\<seddd\>**: :)
**\<sarang\>** So as happens always, there's a tradeoff on complexity (in this case, size and protocol changes) and indistinguishability
**\<sarang\>** s/always/often
**\<sarang\>** Worth noting that with CLSAG, standard tx size already drops from ~2.5 kB to ~1.9 kB
**\<sarang\>** so there's some wiggle room
**\<seddd\>**: are there potentially more compact full Janis mitigations?
**\<sarang\>** Each added scalar/group element adds 32 bytes
**\<seddd\>**: Janus\*
**\<UkoeHB\_\>** this is the smallest known mitigation
**\<ArticMine\>** Tx size is increased by how much?
**\<UkoeHB\_\>** on average, about 2.2\*32 bytes per transaction
**\<UkoeHB\_\>** assuming 2.2 is the average output count
**\<UkoeHB\_\>** wait no, 32 + 1.2\*32
**\<UkoeHB\_\>** same thing lol
**\<seddd\>**: What about encoding the extra basepoint in smth like a lookup table, where base points are indexed by the first 8? bytes
**\<UkoeHB\_\>** actually a tiny bit less than that, taking into account current subaddress tx
**\<ArticMine\>** So 64 bytes for a typical tx
**\<UkoeHB\_\>** yeah basically
**\<ArticMine\>** So if the security issue is verified I do not see an issue here
**\<UkoeHB\_\>** seddd, the base key must be generated by transaction authors
**\<UkoeHB\_\>** under the current construction, not sure if there are any other ways to do it
**\<sarang\>** ArticMine: the math checks out on the fix
**\<seddd\>**: Ok so unknowable ahead, gotcha
**\<seddd\>**: will read more in the issue you linked
**\<sarang\>** Probably time to bring it up in dev meeting again
**\<UkoeHB\_\>** seddd there might be something to that (using a fixed janus base key of some kind), Ill ponder it a bit
**\<sarang\>** Any other action items to bring up?
**\<seddd\>**: UkoeHB\_ that's kind of what I was thinking, or a fixed set of usable bases
**\<seddd\>**: Happy to collaborate, this is an interesting problem
**\<sarang\>** for sure
**\<sarang\>** OK, let's go ahead and wrap things up for this meeting; discussions can of course continue after we adjourn
**\<sarang\>** Any last topics of general interest for the meeting?
**\<sarang\>** Righto! Meeting adjourned
**\<sarang\>** thanks to everyone for attending

186
_posts/2020-04-01-mrl-meeting.md Normal file
View File

@ -0,0 +1,186 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-04-01
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<ArticMine\>** Hi
**\<Isthmus\>** Heya
**\<Isthmus\>** Sorry I fell asleep last week
**\<sarang\>** I'm feeling a bit under the weather today, so I'll try to keep things short and sweet if possible
**\<sarang\>** No problem Isthmus
**\<sarang\>** Let's move on to ROUNDTABLE
**\<sarang\>** My list is short but hopefully interesting
**\<sarang\>** The CLSAG preprint has been revised and updated on the IACR archive
**\<sarang\>** Link: https://eprint.iacr.org/2019/654
**\<sarang\>** New security model and proofs
**\<UkoeHB\_\>** Oh hi forgot about this :p
**\<sarang\>** Alongside this, the code has been updated to make it easier to include trezor/ledger support
**\<sarang\>** Plumbing for device support: https://github.com/SarangNoether/monero/commit/94a7daad0f53074a28dbfb39c0ed1d68d5c40e86
**\<sarang\>** Support for ledger, courtesy of cslashm: https://github.com/SarangNoether/monero/pull/1
**\<sarang\>** Smaller items are proofreading for UkoeHB\_'s Zero to Monero update, and finalizing a PR for hash function domain separation, along with the usual literature review
**\<sarang\>** Does anyone have particular questions, or otherwise have research of interest to share?
**\<sarang\>** I see that Isthmus has just added to the agenda issue
**\<Isthmus\>** https://user-images.githubusercontent.com/21246742/78165574-c14f9500-7408-11ea-8ae5-7d695b4321d3.png
**\<Isthmus\>** n3ptune and I have been exploring tx\_extra some more
**\<sarang\>** neat
**\<Isthmus\>** A few months ago @UkoeHB\_ suggested that the \*ordering\* of tags might leak some information
**\<Isthmus\>** This intuition turned out to be correct
**\<n3ptune\>** link to the issue: https://github.com/monero-project/research-lab/issues/61
**\<Isthmus\>** If we look at tx\_extra in the wild since 1978433 (v12) we see 8 different ways that tags are assembled
**\<sarang\>** Enforcing an ordering and certain fields makes sense for uniformity; I wonder what the added time complexity would be for parsing overall
**\<sarang\>** This also ties in with an idea for Janus mitigation, which would enforce a per-transaction Janus transaction key and per-output tx pubkeys
**\<Isthmus\>** +1
**\<sarang\>** And, FWIW, there was a PR yesterday from moneromooo with an idea for an encrypted-memo-type addition to extra: https://github.com/monero-project/monero/pull/6410
**\<sarang\>** (I have concerns about that one)
**\<Isthmus\>** I would support encrypted memo if \*length\* and \*inclusion\* enforced in protocol. :- )
**\<Isthmus\>** Zcash has a 512 byte encrypted memo on all z2z transactions, and people are having a lot of fun with it
**\<Isthmus\>** (mostly whimsical fun at the moment, but I expect fun applications to follow)
**\<sarang\>** Of course, this seems to overlap in functionality somewhat with encrypted pIDs
**\<Isthmus\>** Oh yea, could just roll the PID into the memo
**\<sarang\>** But yes, I agree that if included, length should be enforced for uniformity
**\<Isthmus\>** Would it be per txn or per output?
**\<UkoeHB\_\>** Im a bit skeptical about scope creep, since Monero is money, not random messages
**\<ArticMine\>** and kept small
**\<UkoeHB\_\>** or email
**\<ArticMine\>** or a replacement for twitter
**\<sarang\>** AIUI that PR requires a single non-change output
**\<sarang\>** at least from my initial read of the code
**\<sarang\>** Its use in Zcash is per-output, I believe
**\<ArticMine\>** Can we actually do away with this messaging entirely?
**\<sarang\>** ?
**\<UkoeHB\_\>** Isthmus's research indicates that even though the extra field is technically open ended, in practice people arent implementing random things
**\<UkoeHB\_\>** supporting random messages with core code would directly lead to more random things in the chain
**\<Isthmus\>** Wait can we clarify "random"
**\<Isthmus\>** Do we mean a fixed tag that supports arbitrary payload
**\<UkoeHB\_\>** non-standard
**\<UkoeHB\_\>** I guess 'memo field' implies to me 'any random message you feel like'
**\<Isthmus\>** Ideally encrypted
**\<sarang\>** To clarify, this PR uses chacha to encrypt with the DH shared secret, including padding as needed to hit certain size resolution
**\<atoc\>** what are pros of including memo field?
**\<sarang\>** but it's not possible to enforce that the data are actually encrypted
**\<UkoeHB\_\>** does chacha index each chunk in some way (so no two chunks are likely to be the same)?
**\<ArticMine\>** That is my question
**\<sarang\>** I think the goal was to enable encrypted recipient data as desired, to reduce the likelihood of non-standard inclusion of data in extra
**\<sarang\>** UkoeHB\_: the chunks are appended before passing to chacha
**\<sarang\>** If I'm reading the PR correctly, the chunking is just to enforce size resolution
**\<Isthmus\>** From a technical/statistical info leak standpoint, we should either have \*no\* messages, or an encrypted message on \*every\* transactions. Which option we choose is partially a UX/design conversation.
**\<sarang\>** And at that point, you basically have a larger pID setup
**\<Isthmus\>** Yea
**\<sarang\>** Which was part of my concern
**\<Isthmus\>** Is there no way to mathematically verify that a field is encrypted?
**\<sarang\>** Not for the network AFAIK
**\<sarang\>** Nor is it possible in Zcash either
**\<sarang\>** It is possible to assure the \_recipient\_ that if they can decrypt properly, the data were encrypted as expected
**\<Isthmus\>** Ohhh yea that's how that works
**\<sarang\>** But otherwise, it's just uniformly distributed data
**\<UkoeHB\_\>** I think that encryption or not isn't a concern, since implementers should want to harmonize with other implementations. The core impl would encrypt, so others would too
**\<ArticMine\>** All of this begs the question do we need this memo filed and even extra
**\<sarang\>** So the worst case in Zcash is that you throw a bunch of unencrypted junk into a tx that gets accepted by the network, but that the recipient won't properly decrypt
\< I would be very happy to do away with both
**\<UkoeHB\_\>** ArticMine: I think ultimately the extra field is useful when/if hard forks are no longer feasible.
**\<sarang\>** At the very least, enforcing ordering as UkoeHB\_ listed in their issue would help a lot of this
**\<sarang\>** certainly not all cases though
**\<UkoeHB\_\>** Imagine if Janus attack wasn't discovered until after hard forks stopped happening. We'd be in Bitcoin's situation of absolute chaos
**\<UkoeHB\_\>** (i.e. if no extra field for wiggle room)
**\<ArticMine\>** How would extra help
**\<Isthmus\>** Geez, if that happened I think the issue is ossification
**\<UkoeHB\_\>** wallets can implement janus mitigation on their own, since it's technically unverifiable anyway
**\<Isthmus\>** I'd like to proactively avoid a situation like that by keeping an agile codebase, not having an anything-goes tx\_extra field
**\<Isthmus\>** Anyways, lots of different pros & cons to consider for each possibility
**\<sarang\>** The question at this point, I think, is to decide whether doing order enforcement (e.g. TLV) is something that a develop wishes to take on
**\<sarang\>** Which ties in to whether enforcement of a consistent Janus mitigation is desirable (I think yes, it is)
**\<UkoeHB\_\>** After next gen tx protocol gets implemented, I imagine the stuff that can go in a hard fork will drop off quite a bit. Rather than losing the ability to make hard forks, we might just run out of hard forks to make. Once the expectation of making periodic hard forks fades away, subsequent hard forks will become much more difficult (also the case if adoption rises concurrently).
**\<sarang\>** Network upgrades also have the probable advantage of encouraging client upgrades
**\<Isthmus\>** Yeah "we might just run out of hard forks to make" is a different situation from encountering an issue (e.g. Janus) and not forking
**\<sarang\>** which provide other non-consensus fixes and benefits
**\<Isthmus\>** Regardless, let's separate the metadata question (should we enforce ordered TLV) from feature questions (should we have a memo field)
**\<sarang\>** Well, TLV enforcement has a big effect on non-standard data, since it requires a stated type
**\<UkoeHB\_\>** I did make pseudo code for enforced sorted TLV, about 200lines
**\<sarang\>** yes
**\<sarang\>** But I mean that the features and the layout enforcement are closely intertwined here
**\<UkoeHB\_\>** Current code already mostly does sorted tlv by default
**\<UkoeHB\_\>** So all that needs to change is in tx validation
**\<Isthmus\>**
**\<atoc\>** nice
**\<sarang\>** OK, so I think what should be brought up in -dev is a well-considered position for 3 things related to extra
**\<sarang\>** 1. Decision on TLV enforcement, and responsibility for implementation
**\<atoc\>** koe, what's your github
**\<sarang\>** 2. Decision on Janus mitigation, and implementation
**\<sarang\>** 3. Musings on the new encrypted-memo idea
**\<UkoeHB\_\>** atoc https://github.com/monero-project/research-lab/issues/61
**\<sarang\>** My position is 1: yes, 2: yes, 3: not unless enforced uniformly (and then it runs up against ePIDs)
**\<Isthmus\>** 1: agree, 2: agree, 3: agree
**\<sarang\>** Anyway, good things to consider here
**\<gingeropolous\>** is the janus mitigation the thing with the subaddresses?
**\<sarang\>** Yes
**\<UkoeHB\_\>** Janus https://github.com/monero-project/research-lab/issues/62
**\<sarang\>** Enforcing a mitigation has the added advantage of making the number of tx pubkeys uniform
**\<Isthmus\>** !!!
**\<Isthmus\>** yesplz
**\<gingeropolous\>** ima just throw it out there to play devils advocate, dunno if its been stated before. What about reverting to not having subaddresses?
**\<sarang\>** So you have one Janus-specific tx pubkey per transaction, and a separate additional pubkey per output
**\<fuwa\>** is it possible to replace tx extra completely with memo, so you don't need to sort anything
**\<sarang\>** You'd need to remove all non-recipient-specific data from memo
**\<sarang\>** Which IIRC moneromooo said would be a significant engineering effort
**\<sarang\>** Extra isn't an inherent problem if uniformity is reasonably enforced
**\<Isthmus\>** Oh, I was wondering something actually
**\<Isthmus\>** Suppose we decide that each transaction should contain X, Y, and Z
**\<UkoeHB\_\>** gingeropolous: then Janus would no longer be a problem. That's about it afaik
**\<Isthmus\>** What's the performance difference between having 3 separate fields versus having 1 field with 3 enforced objects
**\<sarang\>** That's a good question, and I'm not sure
**\<gingeropolous\>** right. so i guess the underlying question is whether subaddresses are worth it.
**\<sarang\>** The scanning benefit is huge for large sets of addresses
**\<sarang\>** Hash lookups are much faster than doing multiple scans of all transactions per address
**\<sarang\>** and Janus checks are only needed for transactions that are already identified as being destined for you
**\<sarang\>** (and those checks are quite fast anyway)
**\<sarang\>** Also note that MLSAG -\> CLSAG drops average tx size by 600 bytes already
**\<sarang\>** s/average/typical
**\<ArticMine\>** Like 2 in 2 out
**\<sarang\>** Yes, a 2-2 tx drops already from ~2.5 kB to ~1.9 kB
**\<sarang\>** So Janus mitigation adds something like about 64 bytes back in
**\<sarang\>** (more for multi-output)
**\<sarang\>** Meaning there's already plenty of wiggle room
**\<gingeropolous\>** well here's hoping its the last mitigation for subaddresses.
**\<atoc\>** that's a pretty good drop
**\<ArticMine\>** We can increase the ring size
**\<UkoeHB\_\>** meeting is getting toward the end, so Ill add my update here: ztm2 should be ready to publish this weekend, I'm finishing up my last proofreading atm
**\<sarang\>** UkoeHB\_: great!
**\<UkoeHB\_\>** might take a bit for getmonero to update though, so we will see when I post about it
**\<atoc\>** koe - i sent you an email but to reiterate it's looking really good
**\<UkoeHB\_\>** yeah saw that :)
**\<sarang\>** Since the hour is indeed almost up, does anyone else wish to share any topics of interest?
**\<Isthmus\>** https://www.reddit.com/r/Monero/comments/fnhm6u/maam\_monero\_ask\_anything\_monday\_march\_23\_2020/flbbt45?utm\_source=share&utm\_medium=web2x
**\<Isthmus\>** ^ thoughts?
**\<Isthmus\>** I'm looking for projects for Fellows to work on, wondering if that seems like a good candidate
**\<sarang\>** That sounds like a question for -dev or -gui TBH!
**\<Isthmus\>** I could also have one of the software engineers implement ordered TLV if -dev wants somebody else to tackle it
**\<Isthmus\>** Oh yea, good point
**\<Isthmus\>** Any wish list projects for MRL? I have 2 software engineers, 1 mathematician, and some data scientists that are open to working on Monero stuff
**\<atoc\>** Isthmus this seems good. i am willing to help but probably can't commit too much atm
**\<sarang\>** Isthmus: perhaps pop over to -dev after meeting and let the channel know that a Fellow might be able to tackle TLV
**\<sarang\>** see what the responses are
**\<sarang\>** I bet moneromooo will have better knowledge of the effects that parsing would have on performance overall
**\<UkoeHB\_\>** well this never got much traction but Im still a fan https://github.com/monero-project/research-lab/issues/59 could be a lot of work idk
**\<sarang\>** Isthmus: I know this important PR needed review... https://github.com/monero-project/supercop/pull/3
**\<sarang\>** and if any Fellows have sufficient interest, the new CLSAG security model in the paper could use some eyes
**\<sarang\>** Anyway, let's start to wrap up
**\<ArticMine\>** I'll cover the fee, penalty and median proposal in the next meeting. By then I'll have most of this finalized
**\<sarang\>** Any ACTION ITEMS to share?
**\<sarang\>** Great ArticMine
**\<atoc\>** @sarang i'll probably ping you tomorrow to go over some zkp ideas for atomic swap
**\<sarang\>** I'll be doing some work on an older preprint, reviewing some ideas in a draft preprint that were sent to me by another researcher, and returning to some Triptych code
**\<UkoeHB\_\>** there are two other big projects: fully-formed audit functionality, and extensive updates to multisig; mentioned those to TheCharlatan but they really are beasts I expect
**\<atoc\>** i have some resources i'd like to share
**\<sarang\>** for sure
**\<Isthmus\>** We can close up the meeting, but I'm curious later if anybody has speculation around what's going on with https://xmrchain.net/search?value=f6cff1edd1a7861ed13d494dd4ae7c4a7f42b5c3bf91457310d2166722c1316f
**\<Isthmus\>** It has an unknown tag type, and the length is recorded incorrectly
**\<UkoeHB\_\>** are you sure it's a length and not a value byte?
**\<Isthmus\>** Not sure, that's why I'm asking
**\<sarang\>** All right, let's go ahead and adjourn for timing purposes, but discussions can of course continue
**\<sarang\>** Thanks to everyone for attending!
**\<sarang\>** Logs posted shortly on the GitHub agenda issue

148
_posts/2020-04-08-mrl-meeting.md Normal file
View File

@ -0,0 +1,148 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-04-08
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, time for the weekly research meeting
**\<sarang\>** Let's get started
**\<sarang\>** GREETINGS
**\<sarang\>** hi
**\<ArticMine\>** hi
**\<atoc\>** hi
**\<TheCharlatan\>** ahoy
**\<sarang\>** On to ROUNDTABLE, I suppose
**\<sarang\>** I've been working on papers for PoPETs submission, which has been a blast
**\<binaryFate\>** hello!
**\<sarang\>** As well as some review for a paper on hierarchical one-of-many proofs
**\<sarang\>** Finally, plenty of code relating to Triptych
**\<sarang\>** Not too much exciting stuff to report overall
**\<sarang\>** Any particular questions?
**\<atoc\>** hierarchical one-of-many-proofs sounds interesting. can you link the paper?
**\<sarang\>** It's not on the IACR yet (and I am not the author)
**\<sarang\>** Otherwise, anyone else who wishes to share research topics is welcome to do so
**\<binaryFate\>** what are hierarchical one-of-many-proofs?
**\<sarang\>** An extension of the Groth proofs used in Triptych and Lelantus that trade size for prover complexity
**\<sarang\>** They use a clever layering technique
**\<binaryFate\>** smaller size for increased prover complexity?
**\<sarang\>** Other way around :)
**\<binaryFate\>** ok :)
**\<sarang\>** The author thought there could be verification savings in certain cases, but I don't think that's the case if you do batching in the usual way
**\<sarang\>** Does anyone else have research topics they'd like to share or discuss here?
**\<ArticMine\>** I can give an update on the scaling and fees issue #70
**\<sarang\>** Sure!
**\<ArticMine\>** I have a solution for the scaling side and minimum relay fee. I am still finalizing the fee ratios
**\<ArticMine\>** Basically we can use the long term medium to deal with this
**\<sarang\>** Can you summarize?
**\<ArticMine\>** Sure
**\<ArticMine\>** 1) Put a cap on the rate of fall of the long term medium so that it falls at the same rate it rises
**\<ArticMine\>** 2) Make the penalty free zone dynamic as the greater of 300000 bytes and 25% of the log term medium
**\<sarang\>** Will that 300K value change with CLSAG?
**\<ArticMine\>** No the reference transaction size will to 2100
**\<sarang\>** yes
**\<sarang\>** But there are no plans to change the fixed-value penalty-free size?
**\<ArticMine\>** The minimum relay fee will very close to the old normal fee
**\<ArticMine\>** So for the current minimum penalty one the minimum fee will actually go up ~2.5x
**\<binaryFate\>** ArticMine what issue/risk is this solution tackling?
**\<ArticMine\>** A sudden drop in use followed by a recovery
**\<ArticMine\>** In many ways similar to COVID-19
**\<binaryFate\>** What would be the shortcomings of the current implementation in that situation?
**\<ArticMine\>** https://github.com/monero-project/research-lab/issues/70
**\<ArticMine\>** This create the scenario
**\<binaryFate\>** Ah, couldn't find issue. Thank you
**\<ArticMine\>** The basic problem is a sharp rise in fee that can take months or year to come back to normal
**\<ArticMine\>** Also a very sudden drop in the long term medium that also could take months or years to recover
**\<ArticMine\>** Issue #70 does not mention COVID-19 but COVID-19 is a very good scenario
**\<sarang\>** Will you have specific code or pseudocode soon to allow for simulations prior to any recommended deployment?
**\<ArticMine\>** Also there are scenarios where COVID-19 cold lead to a significant demand on the Monero network in terms of transactions
**\<ArticMine\>** Yes
**\<ArticMine\>** I have all the formulas now except for the fee ratios
**\<sarang\>** OK, thanks
**\<ArticMine\>** Still working on that
**\<sarang\>** I assume you'll post them to the issue you linked?
**\<ArticMine\>** Yes that is where I will post this
**\<sarang\>** Got it
**\<sarang\>** Anything else of note that folks wish to discuss?
**\<sarang\>** I know UkoeHB\_ recently posted his new version of Zero to Monero
**\<sarang\>** not sure if he's around right now
**\<ArticMine\>** Yes that is excellent
**\<sarang\>** but that's on the getmonero library page, along with a link to the TeX source repo
**\<sarang\>** and there was also a suggestion from UkoeHB\_ for updating how MLSAG secret data is wiped, which was a great catch (PR now available)
**\<sarang\>** Anyone else?
**\<sarang\>** Otherwise, we can move on to ACTION ITEMS for the week
**\<sarang\>** I will be continuing work on a C++ implementation of Triptych for timing efficiency tests
**\<sarang\>** as well as some new material for the multi-signer Triptych variant's security model, prior to the PoPETs submission deadline
**\<Isthmus\>** Oops, just got back. Nice work Artic!
**\<sarang\>** Isthmus: do you have any research or topics you'd like the group to discuss?
**\<Isthmus\>** Ah, I've been neck deep in Zcash all week.
**\<Isthmus\>** https://twitter.com/Mitchellpkt0/status/1245769462172745728
**\<monerobux\>** [ Mitchell P. Krawiec-Thayer on Twitter: "Several unique phenomena in the #Zcash transaction lock\_time field. Most make sense: 0, block heights, unix timestamps, delayed broadcast. Still trying to under ] - twitter.com
**\<Isthmus\>** We did find that funny transaction over in NRL
**\<Isthmus\>** Probably more of a novelty than anything else
**\<Isthmus\>** Lemme grab the link
**\<sarang\>** Anything relating to the Zcash lock times that's been observed in the Monero network too?
**\<Isthmus\>** https://gist.github.com/noncesense-research-lab/a90b8bc5f57ffa9fff1a22d1323e5c2c
**\<sarang\>** Or any lessons to learn from the Zcash work?
**\<Isthmus\>** Monero's lock times look very similar
**\<Isthmus\>** Actually there's also 4 bands
**\<Isthmus\>** Like this:
**\<Isthmus\>** 0
**\<Isthmus\>** {1,3,8,10,12}
**\<Isthmus\>** {block heights ~ 1xxxxxx}
**\<Isthmus\>** and then UTC timestamps
**\<Isthmus\>** It's all over the place, and I don't think any of it is enforced, so the lock\_time field is really just an arbitrary memo xD
**\<sarang\>** In Zcash too?
**\<TheCharlatan\>** Did you analyze the distribution of the UTC timestamps as well?
**\<Isthmus\>** Lemme try to find that notebook
**\<Isthmus\>** Shoot, I don't have it on this computer
**\<sarang\>** No worries
**\<sarang\>** Any other action items for the week?
**\<TheCharlatan\>** So what's up with duplicate subaddresses?
**\<sarang\>** Isthmus: were those the only two such examples?
**\<sarang\>** You suggested "novelty", heh
**\<Isthmus\>** No, there were several, But all very similar, that one is representative
**\<sarang\>** hmm
**\<sarang\>** Along those lines, it was suggested (last week, IIRC) to move some of the more standardized tx fields out of extra
**\<sarang\>** Which wouldn't eliminate strange behavior, of course
**\<sarang\>** but could help with distinguishing factors like ordering etc.
**\<sarang\>** Any further thoughts on that?
**\<Isthmus\>** I'm working on it a bit, but need to move ideas from my head into diagrams. Will share here in a week or two.
**\<Isthmus\>** Might have a new approach, but tbd
**\<sarang\>** New approach to what exactly?
**\<sarang\>** Transaction structure?
**\<Isthmus\>** Nah, mental models that more accurately describe information leaks
**\<Isthmus\>** But it doesn't all fit together yet.
**\<Isthmus\>** My action item is making it into something comprehensible by next week xD
**\<sarang\>** ah ok
**\<sarang\>** Neat!
**\<sarang\>** We're coming up on the end of the hour
**\<sarang\>** Any last questions, topics, action items, etc.?
**\<binaryFate\>** Just curious what's your perception of relevant research over the next 6 months. Everything staled? Business almost as usual?
**\<binaryFate\>** Conferences and events are mostly canceled or moved to remote?
**\<sarang\>** Oh you mean in the broader research community?
**\<sarang\>** Seems that some conferences planned for later in the year are playing it by ear for now
**\<binaryFate\>** Yeah, anything relevant to MRL and Monero, how do you see things going?
**\<sarang\>** The cancellation of the Konferenco was unfortunate, but necessary
**\<sarang\>** Otherwise, calls for papers seem to be mostly continuing as normal, which is great to see
**\<binaryFate\>** ok good to know thank you
**\<sarang\>** Perhaps bored academics stuck at home will be more eager to read and review new research too
**\<binaryFate\>** and go straight for journals :)
**\<Isthmus\>** Oh interesting question @binaryFate
**\<Isthmus\>** That reminds me, when do we want to research quantum-resistant PoW and/or quantum-resistant cryptography?
**\<Isthmus\>** Note that pqPoW isn't super important in the short term
**\<binaryFate\>** "before it's too late"
**\<Isthmus\>** However it is unfortunate that the Monero transaction I make tomorrow will most likely be decrypted by a quantum computer during my life time.
**\<sarang\>** I know that suraeNoether had taken a particular interest recently in post-quantum signature constructions, but I don't know of any relevant efficient results at this point
**\<Isthmus\>** It might be nice to have somebody put together a survey of (1) Exactly which pieces of Monero will be broken by quantum computers (2) Potentially Monero-compatible solutions
**\<sarang\>** The reliance on discrete log hardness is the kicker
**\<Isthmus\>** Yep, it's gonna be tricky.
**\<Isthmus\>** But, I believe we can do it! If not, Monero has a very limited shelf-life :- P
**\<atoc\>** I feel like the bipartite graph matching project that suraeNoether is verifying will be one of the most vulnerable
**\<sarang\>** Graph matching is already parallelizable without a quantum computer
**\<sarang\>** It's just a very large search space in general
**\<sarang\>** On that happy note, let's go ahead and adjourn!
**\<sarang\>** Thanks to everyone for participating
**\<sarang\>** Logs will be posted shortly to the agenda GitHub issue

220
_posts/2020-04-15-mrl-meeting.md Normal file
View File

@ -0,0 +1,220 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-04-15
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** First, GREETINGS
**\<sarang\>** Hello
**\<ArticMine\>** Hi
**\<Isthmus\>** Heya
**\<UkoeHB\_\>** hi
**\<binaryFate\>** hi!
**\<sarang\>** I'll wait a couple of minutes for anyone else to arrive
**\<sgp\_\>** hello
**\<sarang\>** All right, on to ROUNDTABLE
**\<sarang\>** Who would like to share any research of interest?
**\<cankerwort\>** Howdy
**\<UkoeHB\_\>** https://github.com/monero-project/research-lab/issues/73
**\<UkoeHB\_\>** Research is a big word, but there's an idea
**\<sarang\>** It'd be possible for a recipient to miss spendable funds if this value weren't included properly
**\<binaryFate\>** is there any potential issue if the sender does not play "nicely" (purposefully fail the scheme) but can nonetheless prove having sent some outputs to the recipient?
**\<UkoeHB\_\>** same is true for tx pub keys
**\<Isthmus\>** If the sender doesn't follow the rules, recipient won't see a message showing receipt of funds.
**\<Isthmus\>** So they'd just ask the sender to make a valid transaction
**\<sarang\>** Yep
**\<Isthmus\>** Really, the sender hurt themselves
**\<sarang\>** It's similar to if a sender sent a bad commitment,e tc.
**\<sarang\>** (except for the spendability property)
**\<UkoeHB\_\>** if there is a wallet that doesnt make view tags correctly, it will be a worthless wallet
**\<Isthmus\>** Bingo
**\<UkoeHB\_\>** and quickly get patched
**\<cankerwort\>** Surely this would be a kind of "fast scan" and if the sender messed it up somehow it would still show up in a normal scan?
**\<sarang\>** yes
**\<binaryFate\>** They can "DoS" an exchange support easily
**\<binaryFate\>** Probably hurt them more than the exchange
**\<UkoeHB\_\>** yeah cankerwort it would be trivial to have fast/normal scan differentiation; the technique is very simple
**\<sarang\>** And wallets don't have to use the method to scan at all if they don't want to
**\<selsta\>** how would fast scan work together with supercop EC ASM? would ASM still bring a scanning speedup?
**\<binaryFate\>** would there be interesting tradeoff too with a bit more or a bit less than a byte? (changing the 1/256 chance)
**\<Isthmus\>** The speedup is huge if you're looking for 1-2 addresses, but marginal if you're scanning for 20,000 transactions, right?
**\<UkoeHB\_\>** my thought is 1 byte is a very standard size, and going lower gets kinda hacky; more than that I can't imagine meaningful improvement
**\<Isthmus\>** \*1-2 transactions
**\<UkoeHB\_\>** which speedup?
**\<UkoeHB\_\>** if somehow you own 80% of all tx, then yeah the view tag only helps you for (255/256)\*.2 of the rest
**\<cankerwort\>** So a scan under this system would scan (1/256 of all transactions) + (actually relevant transactions) - overlap
**\<UkoeHB\_\>** right
**\<UkoeHB\_\>** and 'scan' just means perform a few more ec operations
**\<UkoeHB\_\>** per output
**\<UkoeHB\_\>** it's actually 1/256 of all outputs, not tx
**\<Isthmus\>** ah yea, ty
**\<TheCharlatan\>** why only one byte? Are two bytes too revealing?
**\<UkoeHB\_\>** diminishing returns
**\<UkoeHB\_\>** the marginal scan change from 1 byte to 2 byte view tags is tiny
**\<sarang\>** OK, noted
**\<sarang\>** Any additional questions on this idea at this point?
**\<UkoeHB\_\>** any objections also?
**\<Isthmus\>** I like it
**\<TheCharlatan\>** yes :)
**\<Isthmus\>** Hopefully this will reduce the "Y MONERO SO SLO TO SYNC" posts on reddit by 1/256 too
**\<UkoeHB\_\>** one can only dream
**\<cankerwort\>** I suppose generally speaking the fork when transactions get smaller anyway is a good time to introduce these QoL improvements
**\<binaryFate\>** this looks great
**\<sarang\>** Well, there doesn't seem to be a plan for whether or not to include Janus mitigations, which have been brought up repeatedly before
**\<cankerwort\>** or is any reduction in transaction sizes already earmarked for bigger ringsizes?
**\<sarang\>** There is currently no concrete plan to increase the ring size with CLSAG
**\<sarang\>** Note that the move from MLSAG to CLSAG will reduce the typical 2-2 transaction from 2.5 kB to 1.9 kB in size
**\<sarang\>** (absent any other changes)
**\<UkoeHB\_\>** I think the discussion about Janus and tx extra has made some small progress
**\<sarang\>** Sure, but small progress != PR
**\<sarang\>** :D
**\<sarang\>** Anything else you'd like to discuss UkoeHB\_?
**\<UkoeHB\_\>** dont think so thanks sarang
**\<sarang\>** OK thanks UkoeHB\_
**\<sarang\>** Does anyone else wish to share research of interest?
**\<sarang\>** If not, I have a couple of things to share
**\<Isthmus\>** Hmm, I’m still working on creating a graph formalism for fungibility defects. Made a little bit of progress since last week, but it’s still not quite coherent. Being rigorous is hard. Hopefully will have something to share in a week or two.
**\<Isthmus\>** I’m cooking up some stuff with Insight too. One of the Fellows put together a patch to prevent coinbase underclaiming now that we’ve moved away from discretized outputs. I just looked at the code, will clean it up and submit for consideration/review.
**\<Isthmus\>** I want to get more of Insight’s engineers working in our ecosystem! Insigght has been pouring a ton of R & D resources into Polkadot, ICON, Zcash, etc. I really want to leverage my team to contribute to the Monero community at this scale too.
**\<Isthmus\>** Having a few internal syncs to match Fellows onto open challenges, based on their skills/passions/interests. Hopefully in the next week or two, I’ll be introducing new contributors. :- )
**\<sarang\>** Nice
**\<Isthmus\>** More details coming soon as those conversation proceed
**\<sarang\>** What kinds of projects?
**\<Isthmus\>** Meeting with the candidates this week to nail that down based on their skillsets
**\<sarang\>** got it
**\<cankerwort\>** And now I need to go find out wtf is Polkadot and ICON all evening
**\<sarang\>** Thanks Isthmus
**\<sarang\>** This PR to speed up Bulletproofs is ready to go: https://github.com/monero-project/monero/pull/6451
**\<sarang\>** Applies retroactively, and has some pretty nice improvements
**\<sarang\>** Saves 25% on a 64-batch of 2-output proofs
**\<sarang\>** Feel free to review if you like
**\<ArticMine\>** Excellent
**\<cankerwort\>** Fantastic news
**\<sarang\>** Second, I've been working hard on a Triptych implementation in the codebase, for more accurate real-world testing
**\<sarang\>** This is the branch: https://github.com/SarangNoether/monero/tree/triptych
**\<sarang\>** (note that this code is not production-ready, and should not be used in anything important)
**\<sarang\>** Size data comparison: https://usercontent.irccloud-cdn.com/file/KvolrThG/size.png
**\<cankerwort\>** Triptych = Tryptych 2? As in did one version supersede the other?
**\<sarang\>** Verification timing comparison: https://usercontent.irccloud-cdn.com/file/4CATnXf6/timing.png
**\<sarang\>** This is for Triptych, which requires separate proofs per input (much like MLSAG and CLSAG require)
**\<sarang\>** The timing plot uses performance test data from this branch
**\<sarang\>** The gray lines are centered at the 11-MLSAG point for visual reference
**\<sarang\>** The timing data does \_not\_ include some unfinished optimizations, or batching, or common input sets within the same transactions
**\<sarang\>** However, it provides an idea of how MLSAG, CLSAG, and Triptych compare generally
**\<Isthmus\>** Noice
**\<TheCharlatan\>** what's the gray line intersection with the Triptych line x axis value?
**\<sarang\>** The vertical gray line is for ring size 11 across all constructions
**\<sarang\>** The horizontal line is the size/time value for MLSAG at ring size 11
**\<sarang\>** (again, just for visual reference)
**\<sarang\>** To help you compare to what we have in place right now
**\<ArticMine\>** What is the impact on tx size
**\<sarang\>** Each transaction input (not ring element, spent input) requires a single signature, of whatever construction you prefer
**\<sarang\>** Moving from 11-MLSAG to ~32-Triptych would result in no change to signature size
**\<sarang\>** and would result in slightly faster verification
**\<binaryFate\>** really impressive
**\<cankerwort\>** These are awesome improvements! But the plan is not to go straight for Triptych right?
**\<sarang\>** The size data are final; but again, the verification data is still WIP
**\<sarang\>** Triptych (and all other WIP next-gen constructions) require a modification to key images that requires new engineering work for multisig
**\<sarang\>** It's very nontrivial
\<[keybase] seddd\>: sorry 4 late. just finishing review of CLSAG, will send draft report to sarang when done. no big findings :)
**\<sarang\>** Thanks seddd, much appreciated
**\<cankerwort\>** seddd = surae?
\<[keybase] seddd\>: +1
\<[keybase] seddd\>: not by a long shot cankerwort
**\<sarang\>** Finally, ledger/trezor support for CLSAG is getting finished
\<[keybase] seddd\>: (surae wayyyy smarter)
**\<sarang\>** cslashm made a PR that'll be included in the test branch
**\<sarang\>** and ledger has a PR on their side for firmware support that's been completed
**\<cankerwort\>** Nice that hw wallets are so proactive compared to how exchanges were with subaddresses
\<[keybase] seddd\>: ah, that's my next step. still haven't reviewed the ledger-side stuffs. looked at cslashm's PR tho
**\<sarang\>** It's been very nice to see such quick work for ledger/trezor, that's for sure
**\<sarang\>** The goal is to have support ready to go at network upgrade time
**\<sgp\_\>** really cool numbers
**\<sarang\>** Anyway, that's my report: BP speedup, Triptych WIP data, CLSAG device-specific support
**\<sarang\>** Any other questions for me about those topics?
**\<sgp\_\>** Are these numbers \*likely\* similar to Arcturus?
**\<sgp\_\>** for non-bath
**\<sgp\_\>** \*batch
**\<cankerwort\>** what is Arcturus?
**\<sarang\>** Ah, I renamed Triptych-2, both to reduce name confusion and because it operates differently
**\<sarang\>** I never liked the name Triptych-2; it was more of a placeholder
**\<cankerwort\>** Noted and appreciated
**\<sarang\>** I am not good at clever naming :/
**\<sarang\>** Anyway, to answer sgp\_'s question
**\<sarang\>** Arcturus gives better size scaling
**\<sarang\>** Verification timing will be very similar to Triptych
**\<sgp\_\>** size already looks pretty good
**\<ArticMine\>** Still if it can be made smaller then it is an improvement
**\<sarang\>** With Arcturus, you only need one proof/signature per \_transaction\_ instead of per \_input\_
**\<Isthmus\>** Ooooh
**\<sarang\>** The magic of generator reuse means the verification would be similar (if you use common anon sets for Triptych for comparison)
**\<sarang\>** (this difference is why I renamed it)
**\<sarang\>** However, keep in mind that Arcturus relies on a nonstandard hardness assumption
**\<ArticMine\>** What if any are the disadvantages?
**\<sarang\>** ^^
**\<cankerwort\>** Is the plan still to get CLSAG audited in time for the next fork? Which are now annually apparently?
**\<sarang\>** This is my understanding
**\<sarang\>** (but it's not my decision)
**\<binaryFate\>** sarang what's your feeling about whether the multisig issue can be solved without foreign primitives?
**\<sarang\>** As far as I know, we'd need support for general RSA groups for proper multisig with the next-gen constructions
**\<sarang\>** This is for signing only, not verification
**\<sarang\>** (even though it's RSA groups, there are no trusted setup problems, FWIW)
**\<binaryFate\>** And you're confident about this being a requirement, or it's just that nobody found how to do without yet?
**\<UkoeHB\_\>** I did a writeup on the multisig question here https://github.com/monero-project/research-lab/issues/72
**\<sarang\>** If you can point out a homomorphic public-key scheme that can use arbitrary prime-order groups, I'm all ears
**\<sarang\>** Yes, it links to code and a description that I worked out
**\<UkoeHB\_\>** right ^
**\<sarang\>** Paillier encryption is not specifically required
**\<sarang\>** but you need an additively homomorphic scheme
**\<sarang\>** Anyway, I've taken a lot of time in this meeting
**\<sarang\>** Was there anything else of interest to share here?
**\<TheCharlatan\>** I made a Rust PoC for including timelock blinding and commitments in transactions. The PoC builds transactions and verifies them with CLSAG signing and the locktime blinding mechanism as described in DLSAG. It looks like the additional size requirements are: input and output commitments, auxiliary (dummy) plaintext locktime, locktime image and a range proof. Thanks to CLSAG, there is no further
**\<TheCharlatan\>** increase in the signature size. Contrary to the locktime blinding desription in DLSAG, I think we can spare the range proof on the transaction's output locktime. The main size component therefore is the additional range proof. I also had a discussion about aggregating the locktime range proof in a transaction input with the amount range proof in the output with sarang yesterday (admittedly more
**\<TheCharlatan\>** of a lesson from sarang, than a discussion). The gist of it is that in transactions with many outputs and inputs, aggregated range proof verification would become prohibitively slow.
\<[keybase] seddd\>: oh, awesome! please disregard then, sometimes I derp
**\<sarang\>** TheCharlatan: there should be an additional 32 bytes to the signature
**\<sarang\>** because of the use of an additional auxiliary linking tag
**\<TheCharlatan\>** Ah, right I did not include tags in the description :P
**\<sarang\>** However, adding 32 bytes per input is still pretty darn good
**\<sarang\>** Note that verification will take a hit
**\<sarang\>** I have a CLSAG test branch that shows the difference
**\<sarang\>** (but I don't recall the numbers)
**\<sarang\>** TheCharlatan: is your code public?
**\<TheCharlatan\>** yes: https://github.com/TheCharlatan/rs-xmr-cryp/tree/master/timelock
**\<sarang\>** Also: note that Triptych can be easily extended to support this as well, since it's also a d-LRS construction like CLSAG is
**\<sarang\>** nice thanks
\<[keybase] seddd\>: TheCharlatan: that's awesome! was going to live-code CLSAG in Rust this Saturday. glad to have another reference impl :)
**\<sarang\>** There's also another CLSAG rust implementation available too
**\<sarang\>** https://github.com/crate-crypto
\<[keybase] seddd\>: so nice! thanks sarang :)
**\<sarang\>** (I didn't write that, FWIW)
\<[keybase] seddd\>: for sure, thanks for the link then :)
**\<TheCharlatan\>** The crate-crypto implementation is much nicer, mine is more of a quick script.
**\<sarang\>** TheCharlatan: what would be helpful from this group at this point?
**\<TheCharlatan\>** so I don't have a good feel on the boundaries of bulletproof scaling yet. So I think some more data there would be helpful.
**\<sarang\>** OK, I'm glad to help with that if you like
**\<sarang\>** (probably best to save those questions for after the meeting)
**\<TheCharlatan\>** yes :)
**\<sarang\>** Thanks TheCharlatan
**\<sarang\>** OK, we're just past the hour mark
**\<sarang\>** Let's move on to ACTION ITEMS
**\<sarang\>** What do folks plan to work on this week (that they wish to share)?
**\<sarang\>** I plan to finish the last Triptych code optimizations, to finalize that timing data
**\<sarang\>** as well as the CLSAG device-specific code integration
**\<sarang\>** Others?
**\<UkoeHB\_\>** I think Ill write a brief proposal for Janus + view tag + extra field, a package update
**\<UkoeHB\_\>** The concept seems to be coalescing
\<[keybase] seddd\>: just working on finishing up testing/manual review of CLSAG, writing the draft report, etc
**\<sarang\>** Yeah, and there are several related ideas there that could happen concurrently
\<[keybase] seddd\>: \_cedes to UkoeHB\_\_
**\<sarang\>** Any last questions or comments before we adjourn?
**\<UkoeHB\_\>** ArticMine: how is the fee proposal coming along?
**\<binaryFate\>** just wants to say that was a lot of impressive developments, feels like christmas
**\<asdc\_ccc\>** ^
**\<ArticMine\>** Still working on the fee part.
**\<sarang\>** All right; we are adjourned! Thanks to everyone for participating
**\<sarang\>** Lots will be posted shortly
**\<sarang\>** Discussions can of course continue :)

299
_posts/2020-04-22-mrl-meeting.md Normal file
View File

@ -0,0 +1,299 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-04-22
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** First, GREETINGS
**\<sarang\>** hi
**\<sgp\_\>** Hello
**\<moneromooo\>** .time localtime
**\<monerobux\>** Could not find timezone localtime.
**\<sgp\_\>** .time cdt
**\<monerobux\>** Could not find timezone cdt.
**\<Isthmus\>** First agenda item is trolling the monerobux bot
**\<sarang\>** naturally
**\<sarang\>** Well, let's move to ROUNDTABLE
**\<atoc\>** ooh
**\<ArticMine\>** Hi
**\<sarang\>** I assume Isthmus would like to share the material he posted on the agenda issue?
**\<sarang\>** https://github.com/monero-project/meta/issues/456
**\<sarang\>** Specifically: https://github.com/monero-project/meta/issues/456#issuecomment-617883059
**\<Isthmus\>** Sure
**\<sarang\>** Go ahead!
**\<UkoeHB\_\>** hi
**\<Isthmus\>** Just completed a study quantifying the impact of exchange rate volatility for Monero-denominated delayed payouts.
**\<Isthmus\>** Normally I consider exchange rate stuff out of scope for MRL but this is relevant to all CCS-funded contributors
**\<Isthmus\>** Hm, I was going to cut and paste from the GitHub issue but everything is slightly too long for IRC
**\<Isthmus\>** Basically, I put together a sliding window statistical analysis of the XMR price timeseries to create a framework for volatility risk management
**\<Isthmus\>** The TL;DR is this:
**\<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.
**\<Isthmus\>** Suppose we want to look at the last 24 months of data
**\<Isthmus\>** And consider a 4-month sliding window (1 month to fundraise on CCS + 3 months to execute)
**\<Isthmus\>** Here are the outcomes based on historical data
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/tbl4tkZn/image.png
**\<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).
**\<sarang\>** That's quite the asymmetry
**\<Isthmus\>** That's the probability distribution function, the cumulative version is helpful too:
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/2UBTfPI7/image.png
**\<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.
**\<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.
**\<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).
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/aCapoFx3/image.png
**\<Isthmus\>** oops transparent background, ssorry
**\<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).
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/kiCGTbDh/image.png
**\<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).
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/le8lMFik/image.png
**\<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.
**\<sarang\>** This is great data
**\<sarang\>** Any questions for Isthmus?
**\<sgp\_\>** Volatility is expensive
**\<sgp\_\>** No questions, but thanks for doing this
**\<Isthmus\>** ty :)
**\<sarang\>** I can share next, if there are no other questions for Isthmus
**\<ArticMine\>** More of a comment.
**\<ArticMine\>** Thanks for the work
**\<atoc\>** Yeah thanks, just for more clarity: what are Monero-denominated delayed payouts?
**\<ArticMine\>** What we are dealing with is more like a two bear market as opposed to volatility
**\<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
**\<ArticMine\>** With the bear trend longer than the term of the typical CCS
**\<atoc\>** ah I see what this is now
**\<atoc\>** I actually wondered about this previously too. This is definitely good info
**\<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.
**\<UkoeHB\_\>** Donators can lose if recipients justifiably ask for premiums in the name of volatility, so donators are paying for the volatility
**\<sarang\>** At any rate, it provides useful information for proposers and potential donors to assess the impacts of volatility
**\<sarang\>** Isthmus: did you want to also discuss TheCharlatan's possible work on timelocks?
**\<sarang\>** (you just posted to the agenda on it)
**\<ArticMine\>** I think volatility is the wrong term here
**\<Isthmus\>** @ArticMine yeah, there may be a more precise way to phrase it. Let me know if you have ideas
**\<Isthmus\>** @sarang sure
**\<Isthmus\>** We discovered a few months ago that Monero's plaintext unlock time leaks information and presents a transaction linkability risk
**\<Isthmus\>** An encrypted unlock time is possible and would solve privacy issues, however the design and performance characteristics must be carefully considered.
**\<sarang\>** Right
**\<ArticMine\>** The issue is a systematic downward trend during the term of the particular CCS
**\<sarang\>** We investigated this with the DLSAG preprint
**\<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
**\<Isthmus\>** Our goals are:
**\<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
**\<Isthmus\>** Detailed system design decisions (e.g. unlock\_time per output or per transaction?)
**\<Isthmus\>** Prototype code to quickly test different approaches , including simulating transaction construction, signing and verification
**\<Isthmus\>** Report of quantified space/time/privacy tradeoffs with each mitigation strategy
**\<Isthmus\>** Implementation code for Monero source tree, for at least one of the chosen approaches
**\<Isthmus\>** Comprehensive research analysis writeup , cross-referenced with code and documentation
**\<Isthmus\>** Oh sorry Sarang, go ahead
**\<sarang\>** Oh no, just providing some background; please continue
**\<Isthmus\>** Oh, that was the end of the list :- )
**\<sarang\>** Ha got it!
**\<sarang\>** Yeah, so there was already some work on this
**\<sarang\>** and I've been discussing it with TheCharlatan
**\<sarang\>** Basically you can follow an approach similar to that in DLSAG using any d-LRS construction
**\<sarang\>** Meaning MLSAG, CLSAG, Triptych can be used
**\<sarang\>** Obviously the scaling will be different in size/time
**\<sarang\>** But essentially you increase from a 2-LRS (signing key, amount key) to a 3-LRS (signing key, amount key, timelock key)
**\<sarang\>** You also need to change how range proofs are structured, in a nontrivial way
**\<sgp\_\>** Does unlock time per transaction mean all outputs have the same unlock time?
**\<sarang\>** In theory, yes
**\<sarang\>** But it would depend on how it's designed
**\<Isthmus\>** Yep @sgp\_ that's how it works currently
**\<sarang\>** Anyway, there's a marginal increase in transaction size to include the necessary auxiliary commitment data
**\<sarang\>** But more notably, there's a time cost that scales linearly with the ring size
**\<sgp\_\>** Maybe market research some come first to see if there's a demand for per-output. Has this been done at all?
**\<sgp\_\>** \*should come
**\<sarang\>** This time cost exists regardless of whether the locks are per-output or per-transaction
**\<sarang\>** I have C++ timing data for CLSAG to show this, and could modify the new Triptych code similarly
**\<sarang\>** (no point doing it for MLSAG)
**\<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
**\<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
**\<sgp\_\>** Does this impact transactions that use the locks only or all of them?
**\<sarang\>** and, of course, the timing hit needs to be considered
**\<sarang\>** Well, for maximum uniformity all outputs would need locks
**\<sarang\>** The lock could be set to 0
**\<sarang\>** but the time cost is the same
**\<sarang\>** Since for every ring member, you need to process its lock data
**\<sarang\>** and the verifier can't tell which locks are 0 due to the commitment structure
**\<UkoeHB\_\>** I feel like knaccc since I can't imagine what utility timelocks have
**\<Isthmus\>** Crossing borders
**\<moneromooo\>** Would encrypting lock times prevent it from being used as a second layer building block ?
**\<sarang\>** Constructions involving cross-chain and off-chain channels would need them
**\<sgp\_\>** Isthmus: how many transactions use these locks again? I lean towards not pursuing this unless there's a known demand
**\<sarang\>** moneromooo: encrypting timelocks were originally designed for 2nd layer stuff in DLSAG
**\<gingeropolous\>** i thought the second chain requires the kind of time locks that we don';t have yet
**\<sarang\>** They aren't required for DLSAG, but they are useful to avoid spend heuristics
**\<gingeropolous\>** second layer, sorry
**\<sarang\>** e.g. ring members whose locks have just expired may be more likely to be true signers, etc.
**\<gingeropolous\>** but i guess both types would need encryption
**\<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
**\<sarang\>** and this cost scales with the ring size
**\<moneromooo\>** I'd be ok with a fair cost if it is instrumental having a good second layer, but not really otherwise.
**\<gingeropolous\>** it seems pretty integral if we want monero to be programmatic money
**\<sarang\>** To be clear, a solution like DLSAG requires timelocks, but does not require encrypted timelocks
**\<sarang\>** It is highly beneficial for uniformity if the timelocks are encrypted, however
**\<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.
**\<sarang\>** UkoeHB\_: I already have this data for CLSAG, and presented it quite a while ago
**\<sarang\>** For Triptych there are estimates (the C++ code didn't exist at the time)
**\<UkoeHB\_\>** ah, in which case a link would be nice
**\<sarang\>** I can dig it up after the meeting
**\<TheCharlatan\>** That's only the costs for the signature and commitments though, right sarang?
**\<sarang\>** FWIW the branch is here for 3-CLSAG: https://github.com/SarangNoether/monero/tree/3-clsag
**\<sarang\>** TheCharlatan: the range proof wouldn't necessarily incur any extra costs
**\<sarang\>** Depending on if/how the limits are changed
**\<sarang\>** If desired, I can update the new Triptych C++ code to support timelocks, for data on performance differences
**\<sarang\>** it'd be pretty straightforward to do
**\<sarang\>** Anyway, I support the idea if it's based on a solid understanding of the costs, and has general consensus
**\<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
**\<sarang\>** sgp\_: we know exactly \_how\_ to do it
**\<sarang\>** (in terms of signature handling)
**\<sgp\_\>** I meant selecting which is best
**\<sarang\>** What's not known are specifics related to range proofs, fee structure, etc.
**\<UkoeHB\_\>** fee would be pretty simple to update afaik
**\<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
**\<sarang\>** But it's still something that would need to be considered and completed in the design/deployment process
**\<UkoeHB\_\>** right
**\<sarang\>** and it also complicates things since there are currently no specific input limits
**\<sarang\>** whereas Bulletproofs have a ceiling-power-of-2 verification cost, which is why we limit the output count
**\<sarang\>** Having a separate bulletproof makes little sense from a size perspective
**\<UkoeHB\_\>** ah hm
**\<UkoeHB\_\>** per-input timelocks may be expensive, but I defer to the estimates /o\
**\<Isthmus\>** Could we have 1 time per transaction, and an encrypted bit with each output
**\<Isthmus\>** 1 = use encrypted timelock
**\<Isthmus\>** 0 = default (10 blocks)
**\<sarang\>** Isthmus: you still need the signature and range components
**\<sarang\>** How you assign timelock commitments to outputs isn't really relevant there
**\<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)
**\<sarang\>** That's a pretty minimal size cost
**\<sarang\>** The real kicker is verification
**\<sarang\>** and the specifics on range proof structure
**\<Isthmus\>** Yep, those are key things to nail down first
**\<sarang\>** Well, we have CLSAG code to give real numbers on that cost
**\<sarang\>** and it's easy to modify Triptych to give its costs
**\<sarang\>** What is not known is what time hit is considered reasonable
**\<sarang\>** "as low as possible" isn't a design decision
**\<sgp\_\>** Can I step in since I really need to make sure I understand the big picture here
**\<sarang\>** sure
**\<sarang\>** of course
**\<sgp\_\>** In order to add a feature, there should be at least some stated use for it, especially if there are costs
**\<UkoeHB\_\>** nvm per-output timelocks would be cheap at 8 bytes per additional output, most cost is on input proving side
**\<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?
**\<sarang\>** Well, and we allow timelocks right now; but they have multiple accepted specifications, and likely introduce spend heuristics
**\<Isthmus\>** s/likely/do/
**\<sarang\>** So their presence and optionality introduce fingerprinting
**\<sgp\_\>** right but they aren't used as far as we know for anything in particular?
**\<sarang\>** ^^ good point
**\<Isthmus\>** Not only are timelocks used
**\<Isthmus\>** 5 different formats are used
**\<Isthmus\>** See the documentation linked above
**\<sarang\>** that's what I meant
**\<Isthmus\>** So SOMEBODY is using them
**\<Isthmus\>** They're anonymous, unfortunately, so I don't know their use case
**\<sarang\>** Requiring a uniform format is an obvious first step
**\<UkoeHB\_\>** what fraction of all tx have non-zero timelocks?
**\<TheCharlatan\>** sgp\_ they are also useful for atomic swap purposes, if you are looking for specific features.
**\<jwinterm\>** was about to ask same UkoeHB\_
**\<sgp\_\>** https://usercontent.irccloud-cdn.com/file/xIfs2dFC/table
**\<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
**\<gingeropolous\>** yeah right now its payment channels (lightning network) and atomic swaps, for the most relevant application of timelocks (i think)
**\<Isthmus\>** They're not super widely used, on the order of 10k nonzero locktimes
**\<Isthmus\>** Of course, neither are subaddresses ;- )
**\<jwinterm\>** total number of txs is 10M order of magnitude?
**\<Isthmus\>** 6M
**\<Isthmus\>** Almos 7M
**\<Isthmus\>** \*almost
**\<jwinterm\>** .c 1e4/7e6
**\<monerobux\>** jwinterm: 0.001428571429
**\<sgp\_\>** dumb idea: why not threaten to remove this feature entirely unless someone justifies the need?
**\<jwinterm\>** 0.1% more than I would've guessed
**\<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.
**\<sgp\_\>** if these are caused by someone fucking around for no purpose, then why bother having them
**\<UkoeHB\_\>** compact format?
**\<sarang\>** Do you mean supporting only a single uniform format?
**\<sarang\>** Because this seems like a natural first step
**\<UkoeHB\_\>** iirc they are varints atm, so at most 9 bytes
**\<sarang\>** At least removing the fingerprinting possible within the use of timelocks
**\<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
**\<sarang\>** Well, and there is no DLSAG-type payment channel use currently available
**\<Isthmus\>** @UkoeHB\_ I thought it was uint64. I got a few outputs locked until 18446744073709551614 (about 500 billion years) over the weekend :- P
**\<sarang\>** Isthmus: something something store of value
**\<ArticMine\>** Using a single format for timelocks seems a sensible first step to me
**\<UkoeHB\_\>** varints have up to 63 bits of information from what I understand
**\<Isthmus\>** oh yea
**\<sarang\>** OK, so in the interest of time, what's a good next step in this design process?
**\<UkoeHB\_\>** cost estimates
**\<sarang\>** Isthmus TheCharlatan: let's discuss that after the meeting
**\<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.
**\<ArticMine\>** single format
**\<sgp\_\>** I say the cost estimate of only the cheapest option to begin with to see if that action is warranted
**\<TheCharlatan\>** Personally I would get rid of time based lock times entirely.
**\<Isthmus\>** That introduces a correction term when blocktime changes
**\<Isthmus\>** But that's easy enough to do
**\<sgp\_\>** TheCharlatan: haha exactly, or at least aggressively ask for justification from people who use them
**\<sarang\>** OK, so beyond investigating optimal single-format cleartext use and updated cost estimates, anything else on this topic for right now?
**\<sarang\>** (otherwise we could discuss it for hours...)
**\<sarang\>** going once
**\<sarang\>** going twice
**\<sarang\>** sold
**\<sgp\_\>** nope, I just want to stress that we need to know why they are used before slowing down transactions
**\<sarang\>** I can briefly share a couple things in the time we have left
**\<sarang\>** I overhauled Triptych verification to support common-key batching
**\<TheCharlatan\>** and s/time/two - deleted the wrong word :(
**\<sarang\>** New timing data: https://usercontent.irccloud-cdn.com/file/TWAkCeJJ/timing.png
**\<sarang\>** This data represents the input-amortized verification cost for a 2-input set of signatures
**\<sarang\>** Assuming the same ring is used across both inputs for Triptych
**\<sarang\>** (for MLSAG/CLSAG it doesn't matter)
**\<sarang\>** I also overhauled the MLSAG tests for better consistency with the other series
**\<UkoeHB\_\>** wait isnt that way faster?
**\<sarang\>** It should be
**\<selsta\>** What are amortized inputs?
**\<sarang\>** If you have a 2-input transaction, you need to compute 2 signatures
**\<sarang\>** For MLSAG/CLSAG, this takes twice the time as one signature
**\<sarang\>** For Triptych, if you use the same ring, you get huge batching benefits
**\<sarang\>** So this is the per-input cost for a 2-input transaction
**\<sarang\>** For higher-input-count txs that would share rings, the benefits get even better
**\<UkoeHB\_\>**
**\<sarang\>** The gray crossed lines are centered at the current N=11 MLSAG point
**\<sarang\>** This implies that Triptych becomes slower than right now (for 2-input txs) between N=64 and N=128
**\<sarang\>** (but you can't split the difference... you need to pick a power of 2)
**\<sarang\>** Anyway, hopefully this gives more realistic timing data, at least across 2-input txs
**\<sgp\_\>** is 128 about the same time as DLSAG 12? 13?
**\<sarang\>** You can use my `triptych` branch and `clsag-device` branch to construct this data for yourself
**\<sarang\>** I don't have C++ data for DLSAG
**\<sgp\_\>** soory I meant MLSAG
**\<sarang\>** I'd have to run some quick MLSAG tests on those intermediate numbers
**\<sarang\>** I can have that shortly after the meeting (need to do a new build)
**\<sgp\_\>** it's fine, not that important
**\<sarang\>** It's easy, just takes a few minutes
**\<sarang\>** Anyway, that's what I wanted to share
**\<sgp\_\>** cool stuff
**\<sarang\>** Does anyone else have research to share (we're running a little long, but that's ok)
**\<UkoeHB\_\>** very cool
**\<UkoeHB\_\>** hi yes, this proposal went up this week https://github.com/monero-project/monero/issues/6456
**\<UkoeHB\_\>** it's a synthesis of discussion and research from IRC over the past months
**\<sarang\>** It's very comprehensive :)
**\<sarang\>** I admit that I haven't had a chance to sit down and devote time to it :/
**\<sarang\>** However, do you have any concrete suggestions at this point UkoeHB\_?
**\<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
**\<sarang\>** Neat
**\<sarang\>** I'll devote time to it before the next meeting for sure
**\<UkoeHB\_\>** also moving to mandating 1 tx pub key for 2-out tx, and 1 key per output for \>2 out tx
**\<sarang\>** Many thanks for continuing work on that
**\<sarang\>** OK, let's briefly review ACTION ITEMS before we adjourn
\< is that assuming that every 2-output txn has a change output?
**\<Isthmus\>** \*change or dummy
**\<UkoeHB\_\>** we only have to make that assumption if Janus is implemented
**\<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?
**\<UkoeHB\_\>** right
**\<Isthmus\>** Eh that seems harmless. Is a corner case anyways.
**\<Isthmus\>** Sorry @sarang go ahead
**\<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
**\<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
**\<sarang\>** that's all for me :)
**\<sarang\>** Anyone else?
**\<Isthmus\>** I'll expand the timelock proposal with some more references/data/use cases
**\<Isthmus\>** And I'll probably finish another quantum-resistance proposal today or tomorrow, currently incorporating feedback into the first draft
**\<sarang\>** great
**\<sarang\>** Any other final action items before we adjourn?
**\<Isthmus\>** Oh yea, and I'll read UkoeHB\_ 's epic github issue :- )
**\<sarang\>** Righto, we are now adjourned! Thanks to everyone for a great meeting

167
_posts/2020-04-29-mrl-meeting.md Normal file
View File

@ -0,0 +1,167 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-04-29
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, let's get started with the research meeting!
**\<sarang\>** First, GREETINGS
**\<sarang\>** hi
**\<ArticMine\>** hi
\<[keybase] unseddd\>: o7
**\<UkoeHB\_\>** hi
**\<sarang\>** Let's go ahead and continue with the ROUNDTABLE
**\<sarang\>** Anyone is welcome to share research topics of interest
**\<sarang\>** I suppose that I can share a few things
**\<sarang\>** Relating to timelocks, I extended CLSAG and Triptych to support them
**\<sarang\>** CLSAG: https://github.com/SarangNoether/monero/commit/28f098260c5bb4da57bb78ebc885fe27c9f10c39
**\<sarang\>** Triptych: https://github.com/SarangNoether/monero/commit/ed48ab1686b7e7405bd6656c18e37ea21e01fe05
**\<sarang\>** Here is corresponding timing data: https://usercontent.irccloud-cdn.com/file/dQXuFH2U/timing.png
**\<sarang\>** 3-CLSAG and 3-Triptych are the timelock-friendly data series
**\<sarang\>** The other data series are unchanged from when I first shared them
**\<sarang\>** I suspect that 3-CLSAG could be optimized by perhaps another 10% or so from what appears on the plot
**\<sarang\>** Unrelated to this, I'm updating how in-memory key encryption is handled, which is taking a bit longer than expected
**\<sarang\>** and am reviewing the new CLSAG fuzzer tool that unseddd provided
**\<sarang\>** That's about it from me!
**\<sarang\>** Are there any questions that I can answer?
**\<Isthmus\>** Nice work
**\<sarang\>** Thanks!
**\<ArticMine\>** CLSAG optimization in verification time, size or both
\<[keybase] unseddd\>: seconded, nice stuff sarang
**\<sarang\>** ArticMine: in verification time, and only for the new 3-CLSAG variant that would apply to encrypted timelocks
**\<ArticMine\>** Great work by the way
**\<ArticMine\>** Thanks
**\<sarang\>** When I wrote 3-CLSAG, I used a particular multiscalar multiplication that could likely be made faster for this particular case
**\<sarang\>** Also, huge thanks to unseddd for reviewing CLSAG and writing the fuzzer tool
\<[keybase] unseddd\>: is 3-CLSAG limiting the multisig to three parties?
\<[keybase] unseddd\>: np :)
**\<sarang\>** No, it adds another key component that would be used for timelocks
**\<sarang\>** Right now we have two key components: one for the usual signing, and the other for balance purposes
\<[keybase] unseddd\>: ah, thanks for the clarification
**\<sarang\>** Does anyone else wish to share research of interest?
**\<UkoeHB\_\>** it seems like 3-triptych would reduce the ringsize likely to be selected by a power of 2
\<[keybase] unseddd\>: not much interesting on my end. just reading formal verification papers + some pq-crypto stuff from Mike Hamburg
**\<sarang\>** Adding encrypted timelocks is a nontrivial verification hit
**\<ArticMine\>** What is the time ans size cost
**\<sarang\>** What might be interesting as an alternative would be to allow cleartext timelocks, but update decoy selection to account for known spend patterns
**\<sarang\>** It would not eliminate fingerprinting, but could help to mitigate age-related selection heuristics
\<[keybase] unseddd\>: are there any leakage issues having the timelock in the clear?
**\<sarang\>** ArticMine: going from CLSAG to 3-CLSAG is about 1.4x increase in verification time
**\<sarang\>** Which could probably be reduced slightly with some extra work
**\<sarang\>** In terms of size it's fairly trivial... adding an extra auxiliary key image (this does not account for other non-signature data)
**\<sarang\>** unseddd: for sure
**\<sarang\>** I'm not saying that I advocate for such an approach, only that it could be an option
**\<sarang\>** and would not imply any size/time hits
**\<UkoeHB\_\>** it's a ways down the road, but I'd like to mention it now; when deciding ring sizes for next gen tx protocol I feel it should be based on a broader analysis of theoretical maximum tx throughput of the network; this is because the max tx volume is when rings are \_least\_ useful to defend against non-scaling graph heuristics, and because larger ring sizes actually reduce the max tx volume; it's an optimization
**\<UkoeHB\_\>** problem
\<[keybase] unseddd\>: right, from a naive perspective, triptych seems like it has enough savings for the hit from timelocks
**\<sgp\_\>** sorry I'm late. catching up
**\<ArticMine\>** UkoeHB\_ The maximum tx throughput is also dependent on external factor tat keep improving over time
**\<UkoeHB\_\>** unfortunately that optimization depends on the efficacy of ring sizes.. which we don't have a complete understanding of; I hope suraeNoether can return to that topic at some point
**\<UkoeHB\_\>** ArticMine: true, there are a lot of factors to consider!
**\<sarang\>** At the very least, we now have concrete numbers for the spacetime effects of ring size increases
**\<atoc\>** hi
**\<sgp\_\>** the cost of encrypted timelocks seems extreme to me tbh. I don't want to go there unless we know we need to support them for a good use-case
**\<sarang\>** Getting timelock-related spend age data from transparent chains might be helpful if it's decided to continue to allow cleartext timelocks
**\<sarang\>** Then output selection could be improved to account for it, and reduce the usefulness of spend-age heuristics
\<[keybase] unseddd\>: use-case: timelocks necessary for atomic swap, encrypting is the most private
\<[keybase] unseddd\>: could also see the counter-point for clear timelocks if they are necessary for atomic swaps (interop w/ clear chains maybe)
**\<sgp\_\>** sarang: I agree, but given the current low utilization, I consider this low priority. The impact to the wider network is negligible
**\<ArticMine\>** Payment channels come to mind here
**\<ArticMine\>** also escrow
**\<sarang\>** Getting that kind of transparent chain data seems pretty straightforward
**\<sgp\_\>** if there's a payment channel, then we can move to make encrypted mandatory. when that happens
**\<Isthmus\>** @sarang, it's on my to-do list for XMR and BTC
**\<sarang\>** :D
**\<sarang\>** How do you plan to examine spend-age data for XMR?
**\<sarang\>** It was examined in Miller for "deducible" outputs (pretty sure that's the term they used) that were the result of chain reactions, which we find don't occur anymore
**\<Isthmus\>** Oh, I just meant comparing the unlock time height to block height to see how many of them even make sense
**\<Isthmus\>** Not that current usage tells us much about future applications.
**\<sarang\>** Ah, got it
**\<Isthmus\>** What is it that you were interested in?
**\<atoc\>** Isthmus are you thinking about atomic swaps these days at all/
**\<Isthmus\>** @sarang sorry I'm in a zoom call and IRC meeting at the same time, and missing little pieces of both
**\<sarang\>** I'd like to see the age distribution of spent outputs in a transparent asset (like BTC) relative to lock expiration, to see if it differs substantially from the overall age distribution
**\<sarang\>** No problem Isthmus!
**\<Isthmus\>** ahhh, yea I can't officially do that for Monero yet. I'll pull it for BTC though.
**\<UkoeHB\_\>** can't officially? it's possible?
**\<sarang\>** Thanks! The overall distribution likely is still similar to the Miller data
**\<sarang\>** (for BTC, of course)
**\<sarang\>** and having that data would be an interesting check of that
**\<Isthmus\>** @UkoeHB\_ yeah, I mean my research over the past few years reveals anonymity puddles covering like 20% of transactions. Then change outputs bleed everything, so there's a ton of data on obviously real spend times. BUT no guarantee that it's representative.
**\<Isthmus\>** I'll be supper curious to see the BTC distributions, will try to get that in the next week or so.
**\<Isthmus\>** \*super
**\<sarang\>** Yeah, Miller's team used two different large sets of blocks in BTC for their analysis
**\<sarang\>** and found the distributions to be similar
**\<sarang\>** but it doesn't appear they accounted for locks
**\<sarang\>** OK, did anyone else have a topic to discuss?
**\<Isthmus\>** Insight is interested in researching practical post-quantum cryptography for Monero, especially privacy features that will remain secure against retrospective deanonymization by future adversaries that can utilize Shor's algorithm, Grover's algorithm, etc. I want to know what our options are, and their costs (complexity, proof size, generation/verification time, etc)
**\<Isthmus\>** https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/README.md
**\<Isthmus\>** Looking for feedback on the research plan.
**\<Isthmus\>** Our goals are to (1) study and simulate the threats listed above to assess vulnerability to quantum computers, (2) evaluate post-quantum cryptography scheme candidates to create a roadmap for hardening Monero against quantum adversaries, and (3) provide open-source proof-of-concept code and demos where applicable.
\<[keybase] unseddd\>: i like pq stuff :) will take a look
**\<sarang\>** Sounds like a fascinating project
**\<sarang\>** I'd be very curious to see what exactly the Phase 3 deliverables would look like
**\<Isthmus\>** Me too! ^\_^
**\<sarang\>** and I think it'd be important to assess any transtion points between constructions/protocols
**\<sarang\>** e.g. it was possible to transition from pre-CT to post-CT
**\<Isthmus\>** Yeah, we'll have to document both the transition and post-transition costs/tradeoffs
**\<sarang\>** New constructions are great, but if it's not possible/feasible to transition on the same chain, that's a sticking point
\<[keybase] unseddd\>: here is the Hamburg paper i am reading through: https://www.shiftleft.org/papers/qromcca/
**\<ArticMine\>** Yes this is a very interesting project
**\<sarang\>** Are you confident about the timeline?
**\<sarang\>** Particularly surrounding the Phase 3 stuff
**\<sarang\>** (not that practical quantum computers are expected by the end of summer...)
**\<Isthmus\>** There's two types of things we could prototype
**\<UkoeHB\_\>** it does say May - June, only a couple days away, not sure if a CCS could be approved and funded in time
\<[keybase] unseddd\>: ten million qubits by fall!!!
**\<Isthmus\>** (1) demo of a quantum computer breaking a Monero encryption feature (at a reduced keysize, or something like that)
**\<UkoeHB\_\>** s/June/July
**\<monerobux\>** UkoeHB\_ meant to say: it does say May - July, only a couple days away, not sure if a CCS could be approved and funded in time
**\<Isthmus\>** Adam did this before, got an IBM quantum computer mining bitcoin at shorter hash length
**\<Isthmus\>** So that's demo breaking classical crypto
**\<Isthmus\>** (2) prototype a possible solution
**\<Isthmus\>** (so we'd use traditional computers and prototype a future solution)
\<[keybase] unseddd\>: \_thoroughly impressed\_
**\<Isthmus\>** Now honestly, I think that #2 would be way cooler. But it also may be hopeful thinking
**\<Isthmus\>** I've seen Adam rapidly convert math papers to code before, but this is going to be a pretty serious endeavor
**\<sarang\>** Either way, would be fascinating
**\<Isthmus\>** here was my note in the writeup
**\<Isthmus\>** "Phase 3 deliverables: The best use of time during this final stage depends strongly on results from the exploratory research. Likely deliverables are a proof of concept or prototype tooling for demonstrating a vulnerability or potential solution"
**\<UkoeHB\_\>** would (1) also include a comparison with a classical computer on the same task? at reduced keysizes, the encryption is weaker on classical computers too
\<[keybase] unseddd\>: Isthmus: are Adam and you regularly in IRC? what is best communication channel?
**\<Isthmus\>** @UkoeHB\_ exactly
**\<Isthmus\>** Adam'll be on IRC shortly :- )
**\<Isthmus\>** We'll probably do a lot of the research in this room, if that's okay with people?
**\<Isthmus\>** Or could make #pq-mrl
**\<sarang\>** Up to you!
**\<Isthmus\>**
**\<sarang\>** OK, any other topics to address before finishing up the meeting?
**\<UkoeHB\_\>** does anyone have new thoughts on https://github.com/monero-project/monero/issues/6456?
\<[keybase] unseddd\>: UkoeHB\_: unfortunately no, have been consumed elsewhere. many apologies
**\<sarang\>** UkoeHB\_: I got unexpectedly caught up in other coding, and didn't review in detail yet :/
**\<Isthmus\>** Oh! Yeah, I'll look at that by Monday. Hopefullly today
**\<sarang\>** my aopologies
**\<sarang\>** s/aopologies/apologies
**\<monerobux\>** sarang meant to say: my apologies
**\<sarang\>** All righty, any ACTION ITEMS for the next week to share?
**\<sarang\>** I will be reviewing 6456, reviewing some CLSAG tests, updating some in-memory encryption code, etc.
**\<Isthmus\>** I'll probably bump the pq-monero proposal over to CCS by EOW, so shoot me a message (irc or isthmus@getmonero.org works) if you have any suggestions for updates or additions
**\<UkoeHB\_\>** on a certain level I have nothing else to contribute to the proposal; whether it gets implemented or not is out of my control; keep in mind it likely won't be superseded by anything, so for 'tx extra', 'janus mitigation', 'tx pub keys', and 'view tag', that's the 'final answer' for the forseeable future
**\<atoc\>** I'm working on some slides (summary) that details how Grin does their grin-btc atomic swap
**\<atoc\>** looking to see if we can get some insight for xmr-btc swaps
**\<hyc\>** Iǘe become convinced that itś never in any XMR holders'interest to swap for BTC, due to BTC taint issues
**\<hyc\>** but I'd be curious to see how it can work, for future XMR(earth)/XMR(mars) swaps
\<[keybase] unseddd\>: hyc: even for true DEX scenario?
\<[keybase] unseddd\>: marsero
**\<hyc\>** especially for true DEX, wher eyou can't vet the BTC
**\<hyc\>** the benefits are all one-sided, in favor of the BTC seller
**\<Isthmus\>** Eh if I've got a wallet full of Monero, but the sandwich shop I'm standing in only takes BTC, I might find that swap useful.
**\<ArticMine\>** I have to agree with hyc Selling XMR for BTC on a swap is very dangerous
\<[keybase] unseddd\>: yeah, i see your point. do you have the same opinion for other swap pairs?
**\<hyc\>** if the other pairs also involve transparent coins, yes
**\<sgp\_\>** +1 concern here
**\<sarang\>** Well, in the interest of time (our hour is up), I'll adjourn the meeting for log purposes, but discussion can of course continue

123
_posts/2020-05-06-mrl-meeting.md Normal file
View File

@ -0,0 +1,123 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-05-06
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** All righty! Time for the weekly research meeting
**\<sarang\>** As always, we begin with GREETINGS
**\<ArticMine\>** Hi
**\<UkoeHB\_\>** hi
**\<atoc\>** hi
**\<sarang\>** Let's move on to ROUNDTABLE
**\<sarang\>** Any research of interest that folks wish to share?
**\<sarang\>** I can share a few things, I suppose
**\<sarang\>** I worked up a PR to update how keys are encrypted in memory
**\<sarang\>** This has follow-on effects to how they're stored on disk, and I'm making some additional updates to improve the existing unit tests and add others
**\<sarang\>** and I'm finishing up a test implementation of Arcturus, the extension of Triptych that offers better proof sizes
**\<sarang\>** I'd like to determine exactly what the timing differences are, since initial estimates suggested that Arcturus and Triptych would be very close
**\<kenshamir[m]\>** Sorry if I've missed this; are there any comparisons for Arcturus, Triptych and CLSAG ?
**\<sgp\_\>** hello
**\<sarang\>** And kenshamir[m]: I have comparisons for CLSAG and Triptych, but this will add actual implementation data for Arcturus when finished
**\<kenshamir[m]\>** Oh right, very cool
**\<sarang\>** The size data is already known, FWIW
**\<sarang\>** But the Arcturus timing was always an estimate based on operation counts
**\<sarang\>** It's different enough in how it handles transactions that I'd like to know for sure
**\<kenshamir[m]\>** concretely?
**\<kenshamir[m]\>** Is there a link for it?
**\<sarang\>** The size/timing data?
**\<kenshamir[m]\>** Yeah, the size data
**\<sarang\>** Yeah, let me pull it up
**\<kenshamir[m]\>** Probably may not be that helpful for Monero, but there is a new paper out on an endomorphism that allows you to compute aG + bH faster in variable time
**\<sarang\>** Page 11: https://eprint.iacr.org/2020/312.pdf
**\<kenshamir[m]\>** Link : https://eprint.iacr.org/2020/454.pdf
**\<kenshamir[m]\>** Thank you
**\<sarang\>** Anyway, that's what I wanted to share
**\<sarang\>** Does anyone else have research of interest?
**\<UkoeHB\_\>** what's the gist of your encryption update?
**\<sarang\>** The in-memory encryption of keys was being done with a chacha stream that was XORed with keys, instead of just encrypting the keys with chacha directly
**\<sarang\>** This PR makes this change
**\<sarang\>** The existing unit tests for wallet and key encryption also get some updates
**\<UkoeHB\_\>** ah interesting
**\<sarang\>** It also transitions old encrypted keys to the new format, which needs better testing that I'm still working on
**\<sarang\>** Seems pretty quiet today!
**\<sarang\>** We could always end early if there isn't more that needs to be discussed...
**\<sgp\_\>** I have nothing to add except to remind people that I still want coinbase outputs to be avoided entirely in non-coinbase-spend rings :p
**\<sarang\>** You mean the idea that a ring containing a coinbase output must have all coinbase outputs, right?
**\<sarang\>** sgp\_: can you briefly recap your rationale, to ensure everyone is on the same page?
**\<sgp\_\>** yes that idea
**\<sgp\_\>** rationale is that no normal users spend coinbase outputs
**\<sgp\_\>** even people who mine on mining pools never spend coinbase outputs
**\<sgp\_\>** so the selection of these is markedly different from expected user spend behavior
**\<sarang\>** When I thought about this earlier, I was concerned that it sort of kicks the can down the road one hop on the graph
**\<sgp\_\>** separating these will increase the effective ringsize for most (\>99%) users by 10-20%
**\<sgp\_\>** sarang: it kicks the can down the road, but it's still MUCH better
**\<ArticMine\>** Interesting
**\<sarang\>** And that if a heuristic was "this coinbase probably isn't the true signer" previously, it would become "this output that came from a coinbase ring probably isn't the true signer" as a somewhat weaker heuristic
**\<sarang\>** Yeah, I think it's better but doesn't totally eliminate it
**\<sarang\>** If it were implemented, there would need to be a decision on what selection distribution to use, which should probably be based on a transparent-chain analysis at minimum
**\<sgp\_\>** it's still essentially one set of transactions separated (one ring signature? I'm struggling to explain this simply and also accurately)
**\<sarang\>** to see if it matches the overall distribution
**\<ArticMine\>** The idea is that an ouput from a mining pool is far more likely to e spent by a normal user
**\<sgp\_\>** basically the real spend of the after-coinbase output would look the same as several transactions that select this output as the decoys
**\<sarang\>** Yeah
**\<sarang\>** Does my statement about the analysis for a distribution make sense?
**\<ArticMine\>** I agree it mitigates but does not completely eliminate the risk
**\<sgp\_\>** but now this accounts for the behavior that the user could just be a miner on a mining pool, for example
**\<sgp\_\>** which is hugely broader
**\<sarang\>** But it is true that right now, the spend patterns of coinbase vs non-coinbase are assumed to be the same by the selection algorithm
**\<sarang\>** It'll be very interesting to see that distribution for coinbase-only
**\<sgp\_\>** only solo miners can spend coinbase outputs. Miners on mining pools can also spend from-coinbase outputs
**\<sarang\>** right
**\<sgp\_\>** so while it kicks the can down the road, in terms of practical behavior, it's a night and day improvement
**\<sarang\>** I'll ping Isthmus here, since his group has access to this sort of data for other chains
**\<sgp\_\>** discussion on this idea has been mixed for years. I'd like to see this actually done
**\<sgp\_\>** 10-20% better effective ringsizes just with smarter selection
**\<ArticMine\>** It is a significant mitigation of the issue. I do not see a clear downside to this.
**\<sgp\_\>** downside is to people that are running private pools. They effectively need to "churn" once by not directly sending the coinbase outputs to people
**\<sgp\_\>** I think this is a small tradeoff
**\<sarang\>** I think it's an improvement, provided it doesn't introduce unexpected or unintended consequences to the selection distribution, and is based on distribution data from known spends where reasonable (e.g. Bitcoin)
**\<zkao\>** hoi, can someone evaluate how sound this ECDSA adaptor signature is? https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/ if these ECDSA adaptor signature works, it looks like the atomic swap can be done using a scheme similar to the suggested by andytoshi-sarang (equivalent discrete logs), mixed with the game theory from h4sh3d's proposal: all game theory on bitcoin script (forcing players to act or
**\<sgp\_\>** I agree with that caveat, though I want to add my own caveat that I don't see how it can be worse
**\<zkao\>** lose), and no need for monero refund. so it should work on monero today.
**\<sarang\>** zkao: I didn't invent that cross-group discrete log idea; it was andytoshi
**\<zkao\>** yes, i know, u proposed
**\<sarang\>** sgp\_: if the coinbase-only selection distribution ends up being very different to the overall distribution, it would introduce a heuristic for coinbase true signers
**\<sarang\>** and for all we know, it could be a very different distribution in that miners/pools spend immediately or something
**\<sgp\_\>** luckily then we can approach coinbase with its own algo
**\<sgp\_\>** which we can't do now
**\<sarang\>** The non-coinbase distribution could be easily modified to simply redraw if it chooses a coinbase
**\<sgp\_\>** if these are actually very different spend patterns, then the possibility for increased privacy is even greater
**\<sgp\_\>** since we can handle them separately, not together
**\<sarang\>** The coinbase distribution would simply be some fixed selection distribution on block order, that doesn't need to do the shuffling method we do now
**\<sarang\>** sgp\_: right
**\<sgp\_\>** my gut suggests coinbase spends are quicker on average
**\<sgp\_\>** but Bitcoin data would be great for that ofc
**\<sarang\>** Right
**\<sarang\>** Hopefully someone like Isthmus's group can get that data, since they have easy access to the dataset AFAIK
**\<sgp\_\>** I still support avoiding coinbase with the stupid method of re-selecting a coinbase is chosen, though improvements can make that better. I see even this stupid model as an incremental improvement
**\<sgp\_\>** \*if a coinbase is chosen
**\<sgp\_\>** what I'm trying to say is that the data on Bitcoin should help make the selections better, but that they are not prerequisites to switch since it can't be worse than it already is in my eyes
**\<sarang\>** If there were no known distribution from Bitcoin etc., what selection for coinbase-only would you suggest?
**\<sarang\>** Reselect-on-coinbase seems reasonably for non-coinbase rings, but there still would need to be a chosen selection distribution for coinbase-only rings
**\<sgp\_\>** same as current probably? I agree that's not ideal
**\<sarang\>** Well, the current one takes block density into account, and that's not relevant for coinbase-only
**\<sgp\_\>** keeping in mind most public pools publish this data openly anyway
**\<sgp\_\>** so frankly the coinbase rings would be susceptible to a lot of public data causing a high proportion of heuristically dead outputs
**\<sgp\_\>** in the worst of cases I say ~90% of of the hashrate accounted for by public pools sharing coinbase data, so ringsize 11 doesn't really help with that in the best of cases
**\<sgp\_\>** \*I saw ~90%
**\<sarang\>** Well, at that point you could \_almost\_ suggest removing the requirement for nontrivial rings in coinbase-only at all
**\<sarang\>** \*altogether
**\<sarang\>** If the thought is that analysis could reveal true signers in a huge number of cases anyway
**\<sgp\_\>** there's a push for pools to not share this data, but I agree that in the current case, coinbase rings should be considered to offer near-zero protection
**\<sgp\_\>** really any coinbase spend. in the current situation, they are still heuristically dead, just spread across normal users' transactions
**\<sarang\>** Hmm, we're a bit over time
**\<sgp\_\>** yeah we can end
**\<sarang\>** Let's move to ACTION ITEMS and then continue discussion
**\<sarang\>** I have some unit tests update to make for the key encryption PR, and hopefully can get Arcturus code working in C++ with the timing data that I want
**\<sarang\>** Any other updates, action items, etc. before we adjourn?
**\<sarang\>** If not, adjourned!
**\<sarang\>** Logs will be posted shortly

100
_posts/2020-05-13-mrl-meeting.md Normal file
View File

@ -0,0 +1,100 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-05-13
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** First, GREETINGS
**\<sarang\>** Hi
**\<binaryFate\>** hello!
**\<Isthmus\>** Heyo
**\<h4sh3d[m]\>** Hello
**\<ArticMine\>** Hi
**\<sarang\>** Next up is ROUNDTABLE
**\<rehrar\>** hi
**\<sarang\>** Does anyone have research of interest to share with the group?
**\<sarang\>** I know Isthmus just mentioned something before we started
**\<Isthmus\>** Hey everybody. I incorporated y'all's feedback on the research proposal (thanks for your input), updated version here: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/142
**\<Isthmus\>** Most of the changes are in the Roadmap section
**\<Isthmus\>** For phase 1 we've switched to a very formal enumeration of adversary capabilities and Monero features of interest, and will document possible issues and solutions along the lines of:
**\<Isthmus\>** "Monero's [component] is vulnerable to [impact] by a hypothetical adversary that can leverage [algorithm]. In general, the solution must meet [requirements]. Current relevant methods include [cryptosystem] which would require [migration process] and has [tradeoffs] that would prevent implementation until [device bandwidth/resource threshold] is widely available."
**\<Isthmus\>** Throughout this entire project, the community will receive updates during the weekly #monero-research-lab meetings. During phase 3 however, several specific documents (the key deliverables from this research) will be freely published:
**\<Isthmus\>** 1. User-friendly writeup: This community-facing writeup will provide an approachable explanation of how hypothetical quantum computers may impact Monero, and possible future mitigations. The writeup should minimize FUD and provide the context that these vulnerabilities apply to almost all cryptocurrencies (not only Monero).
**\<Isthmus\>** 2. Technical documentation: An MRL position paper to distill key information for (current and future) researchers and developers. The writeup should formally describe vulnerabilities, and highlight potential strategies and solutions, noting their tradeoffs. Code snippets may be included if appropriate for pedagogical purposes or clarity.
**\<Isthmus\>** 3. Non-technical 1-pager: An ELI5 / TL;DR summary will be provided for journalists, Monero Outreach, etc. This blurb will discuss risks and myths with no technical jargon, with key takeaways that a broad audience will appreciate.
**\<Isthmus\>** Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos. :- )
**\<Isthmus\>** (ends notes)
**\<Isthmus\>** Oh, I'll X-post the proposal to Reddit today
**\<sarang\>** I like the change in scope, particularly focusing on communicating the current state of the protocol
**\<sarang\>** Moving away from specific things like implementations and proofs-of-concept for changes seems wise, especially considering that the state of the art will change
**\<Isthmus\>** ^ yep
**\<Isthmus\>** It's important to note that many current post-quantum cryptography candidates require large proofs and significant computational resources, and will thus not be suitable for immediate deployment. For this reason, understanding broad strategies and their tradeoff will be more useful than specific implementations. Thankfully, consumer device capabilities increase over time, and researchers continue to
**\<Isthmus\>** discover new faster/smaller proving systems, so these practical barriers are temporary.
**\<sarang\>** Were there any questions for Isthmus about this proposal? (Comments could also be made on the proposal itself to reach a wider audience)
**\<rehrar\>** nop
**\<sarang\>** OK, does anyone else wish to share research of interest?
**\<sarang\>** If not, I have a few items to share
**\<h4sh3d[m]\>** Yes, I have something
**\<h4sh3d[m]\>** Earlier someone posted this: https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
**\<sarang\>** Ah yes, the atomic swap idea
**\<h4sh3d[m]\>** I had a closer look. The interesting part is the usage of ECDSA adaptor signature
**\<sarang\>** Avoids the use of hash preimage proofs IIRC?
**\<sarang\>** (I have yet to examine it in detail)
**\<h4sh3d[m]\>** Yes, the protocol is very close what I already shared here
**\<h4sh3d[m]\>** But with the idea of using a cross group dl-proof with an ECDSA adaptor signature might work
**\<sarang\>** At the very least, a cross-group DL equivalence proof is very straightforward
**\<sarang\>** and exists today
**\<h4sh3d[m]\>** Yes, that's why it's interesting =)
**\<h4sh3d[m]\>** The new part for me is this: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
**\<sarang\>** Is that link related to the gist?
**\<Isthmus\>** Very cool
**\<sarang\>** Ah, the link is from the gist
**\<h4sh3d[m]\>** Yes, it's the first link "single signer ECDSA adaptor signatures" in the Gist
**\<sarang\>** got it
**\<sarang\>** I'm excited to work it out in detail!
**\<h4sh3d[m]\>** With this, we can put one half of the monero key as the adaptor `Y` (or the other half depending if the swap succeed or not)
**\<h4sh3d[m]\>** I'd be happy to work on this too. As zkao mentioned it earlier we are thinking about a proposal if it make sense
**\<sarang\>** Having more eyes on ideas like this is definitely a good thing
**\<sarang\>** Thanks for sharing this h4sh3d[m] (and zkao earlier as well!)
**\<sarang\>** Were there any questions for h4sh3d[m] ?
**\<h4sh3d[m]\>** Cool, I'll continue posting my findings here in the next days.
**\<sarang\>** Thanks, please do
**\<sarang\>** I wanted to finish up some work on next-gen transaction protocols, so I wrote up a proof-of-concept C++ implementation of Arcturus: https://github.com/SarangNoether/monero/tree/arcturus
**\<rehrar\>** weeeeee!!!!
**\<sarang\>** The usual disclaimer that it has not undergone any kind of review, and should be considered unsafe for production use
**\<sarang\>** However, I got timing data from it
**\<sarang\>** I had to rewrite the performance tests for Triptych, MLSAG, and CLSAG for better comparison since Arcturus integrates balance checking directly into the proof (and the others do not)
**\<sarang\>** The results, which I'll paste in just a sec, show that transaction input/output structure plays a role in the overall timing results
**\<sarang\>** Here is data for 1-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/KZxENlzN/timing-1-2.png
**\<sarang\>** Here is data for 2-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/Ww2hDEbo/timing-2-2.png
**\<sarang\>** These account for the total verification time for signature/proof verification and balance checks
**\<sarang\>** but does not include range proof verification (that's the same for all protocols)
**\<sarang\>** You can get the same data by choosing the appropriate performance test parameters on my `clsag-device` branch (for MLSAG \_and\_ CLSAG), `triptych` branch (for Triptych), and `arcturus` branch (for Arcturus)
**\<sarang\>** The grey lines are centered at the 11-MLSAG point to show the current timing
**\<binaryFate\>** it looks super close to Triptych, any hunch how it would look like for more-inputs and/or more-outputs?
**\<sarang\>** At higher ring sizes, Triptych and Arcturus should stay very close, as the balance check component becomes less relevant overall
**\<sarang\>** The difference mainly arises from whether the balance check group operations are separated (in Triptych) or included in a single multiscalar multiscalar operation with the rest of the proof (in Arcturus)
**\<sarang\>** and that difference goes away at higher ring sizes
**\<sarang\>** The real benefit is in transaction size
**\<sarang\>** I thought I already had Arcturus included in plot data, but it turns out I don't... I'll work that out right after the meeting and post it here
**\<sarang\>** Unrelated to this, I'm coordinating a statement of work for the CLSAG audit with OSTIF and Teserakt, the audit firm that the audit workgroup recommended
**\<sarang\>** Were there any other questions for me on these topics?
**\<moneromooo\>** Oooooh ^\_^
**\<sarang\>** Does anyone else have topics to discuss for the roundtable, before we move on?
**\<Isthmus\>** Hmm, I just remembered a showerthought to generate seashell avatars based on transforming heterogeneously-structured transaction metadata into a signature string, and then running that through surae's visual hash function...
**\<Isthmus\>** I'll try to prototype it this weekend so I can share examples next week (kind of hard to describe abstractly)
**\<sarang\>** Oh man, I remember that seashell work! It's been a while
**\<Isthmus\>** Yeah, that's a throwback. I forked Surae's repo back in 2018 and turned it into a notebook, but never connected it to Monero input data. https://github.com/Mitchellpkt/seashells/blob/master/seashells\_notebook.ipynb
**\<sarang\>** I suppose we can move on to ACTION ITEMS and finish up the meeting if there isn't anything else to discuss
**\<selsta\>** I wish we could display seashells in CLI wallet.
**\<sarang\>** I'll be incorporating some changes to my in-memory key encryption PR, looking into that swap proposal in greater detail, and updating the Arcturus security model for conference submission
**\<sarang\>** Anyone else?
**\<h4sh3d[m]\>** I'll study more in details adaptor for ECDSA and rewrite the concerned parts of the atomic swap paper.
**\<sarang\>** You mean updating your original write-up?
**\<h4sh3d[m]\>** yes
**\<sarang\>** Excellent
**\<sarang\>** All right, I suppose we can adjourn; thanks to everyone for participating!
**\<sarang\>** Logs will be posted shortly to the agenda issue

185
_posts/2020-05-20-mrl-meeting.md Normal file
View File

@ -0,0 +1,185 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-05-20
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** GREETINGS
**\<sarang\>** hello
**\<sgp\_\>** hello
**\<dEBRUYNE\>** hi
**\<telapongo23\>** Hi guys, just eavesdropping here :-D
**\<hyc\>** hello
**\<sarang\>** Let's move to ROUNDTABLE, where anyone is welcome to share research topics of interest
**\<sarang\>** Who wishes to share something? (I saw Isthmus just posted to the agenda issue)
**\<ArticMine\>** Hi
**\<sarang\>** I suppose that I can share a few items
**\<sarang\>** First, I'll review some Arcturus numbers, some of which were presented last week
**\<sarang\>** Recall that Arcturus is a modification of Triptych that needs only one proof per transaction, instead of one proof per spend
**\<h4sh3d[m]\>** Hi
**\<sarang\>** (making it similar to RCT3's update and Omniring)
**\<sarang\>** I'll link some plots...
**\<sarang\>** Size data for 1 input: https://usercontent.irccloud-cdn.com/file/DYMoX7jy/size-1.png
**\<sarang\>** Size data for 2 inputs: https://usercontent.irccloud-cdn.com/file/7Hw5Wnsv/size-2.png
**\<sarang\>** Size data for 16 inputs: https://usercontent.irccloud-cdn.com/file/QzJ03VBI/size-16.png
**\<sarang\>** You can see the improvement as the number of inputs increases
**\<sarang\>** From last week, I'll re-post the timing data...
**\<sarang\>** Verification timing for 1-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/airMJ4pC/timing-1-2.png
**\<sarang\>** Verification timing for 2-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/iZdBR8xe/timing-2-2.png
**\<sarang\>** Related to this, I've been working on the Arcturus transaction security model, which uses an Omniring-style balance game/definition and applies it to the combination of Arcturus proofs and Bulletproof range proofs
**\<sarang\>** I'll post that update when I've finished typesetting it and reorganizing the preprint on IACR
**\<sarang\>** (but it's still in progress!)
**\<sarang\>** Any questions for me on this material?
**\<hyc\>** Arcturus seems to blow away the other sig mechs
**\<fort3hlulz\>** What's the main drawback(s) of Arcturus compared to other sig mechs?
**\<fort3hlulz\>** Seems like a clear win, but maybe there is something I'm missing.
**\<sarang\>** The RCT3 update beats it for overall size (when looking at the whole chain), but that does very poorly in verification due to input padding
**\<sarang\>** Arcturus relies on a nonstandard cryptographic hardness assumption
**\<hyc\>** what are the implications of being nonstandard? needs further proofs?
**\<sarang\>** You can see the full-chain comparative estimates on page 12 of the Arcturus IACR preprint: https://eprint.iacr.org/2020/312.pdf
**\<sarang\>** note that in Figure 3, RCT3 wins, but in Figure 4, it loses
**\<sarang\>** (size vs time)
**\<sarang\>** It would need external study to see if it can either be reduced to more standard assumption, broken, or considered/tested enough to be considered reasonable
**\<sarang\>** Triptych does not have this limitation, and relies on only standard assumptions
**\<sarang\>** I'm submitting it to conference proceedings in the hope that it will get some quality review
**\<sarang\>** so I want to update the security model prior to that deadline at the end of this month
**\<hyc\>** the win on time is huge
**\<sarang\>** FWIW both Triptych and Arcturus are very similar for verification time
**\<sarang\>** that's because of how generators are batched similarly in both approaches
**\<hyc\>** triptych appears to be a constant factor larger in size
**\<hyc\>** well, nearly.
**\<sarang\>** It requires multiple proofs, and has some extra elements included (e.g. commitment offsets)
**\<sarang\>** Arcturus is a single proof, and does not require any commitment offsets
**\<sarang\>** (it does have proof elements that scale with the number of spends, but does so pretty darn well)
**\<hyc\>** at least all of the size plots are linear, no silly exponential growth
**\<hyc\>** probably an obvious statement but I would choose to optimize time
**\<sarang\>** In that case, Triptych and Arcturus are essentially comparable
**\<sarang\>** with small variations relating to how balances are checked
**\<sarang\>** and these variations disappear at higher ring sizes anyway
**\<hyc\>** and Triptych requires no nonstandard assumptions
**\<sarang\>** Nope
\< ah thanks, I was wondering about this
**\<sarang\>** I could probably add the Arcturus-style balance security definition to Triptych as well
**\<sarang\>** Isthmus: balance checks in MLSAG/CLSAG/Triptych are identical... sum the commitment offsets and outputs to zero
**\<sarang\>** In Arcturus it's built in to the proving system directly
**\<sarang\>** At high ring sizes, the offset-based balance check is overshadowed by the large number of group operations required for the rest of the verification process
**\<hyc\>** this is some great stuff. Arcturus still grows in size more slowly than Triptych,
**\<sarang\>** At low ring sizes, they're more comparable and the difference is notable
**\<sarang\>** Yeah
**\<sarang\>** Its per-spend elements scale better
**\<sarang\>** What's nifty is they both use the same underlying Groth-style cryptographic plumbing, but in different ways
**\<sarang\>** (this is the same plumbing that Lelantus uses)
**\<sarang\>** Anyway, I've taken up enough of the roundtable time for one day!
**\<sarang\>** Does anyone else have research they wish to share?
**\<Isthmus\>** TheCharlatan updated the encrypted unlock time research proposal with sarang's timing data: https://github.com/insight-decentralized-consensus-lab/monero\_encrypted\_unlock\_time
**\<sarang\>** s/Tryptich/Triptych/
**\<Isthmus\>** (based on feedback at previous MRL meeting, and input from sarang)
**\<Isthmus\>** Also, experimenting with a new application for surae's seashell avatars project. Essentially, each transaction fingerprint (behavior or metadata) is compared against the behavior of the core software and assigned a 0 if matching or 1 if deviating.
**\<Isthmus\>** Looping over fingerprints creates a fingerprint string that is ingested to produce a visual hash. These could be added to a research blockchain explorer so that it's easier to tell at a glance which transactions must have been generated by custom software.
**\<sarang\>** I'm glad the 3-CLSAG and 3-Triptych data was useful!
**\<Isthmus\>** For example, the first image shows the avatar for transactions that are from (or mimic) the core GUI/CLI, which has fingerprint ...0000
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/vjCauM0y/image.png
**\<Isthmus\>** The secnd image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010)
**\<Isthmus\>** the bottom image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010)
**\<Isthmus\>** https://usercontent.irccloud-cdn.com/file/Lzt9vfyJ/image.png
**\<Isthmus\>** (note that this particular issue was fixed in recent update)
**\<Isthmus\>** Anyways, still very early toy/prototype
**\<sarang\>** So the hash inputs are individually set bits? 1 = "basically the same as standard", 0 = "different enough"
**\<sarang\>** and this is done over different characteristics to build the input string?
**\<Isthmus\>** Yep
**\<Isthmus\>** 0 = "the core wallet would construct a transaction in this way"
**\<Isthmus\>** 1 = "the core wallet would never construct a transaction this way"
**\<Isthmus\>** e.g. the juvenile spend example
**\<sarang\>** got it
**\<Isthmus\>** Will spice it up a bit though, surae comments "The skin of the shells could be fractals dependent on the hash input visualized in 2d with \*color schemes\* selected from families of pleasing color triples based on hash input..."
**\<UkoeHB\_\>** What's a juvenile ring member,
**\<UkoeHB\_\>** ?
**\<Isthmus\>** Any transaction that includes a ring that includes a ring member less than 10 blocks old (based on the time it was mined)
**\<Isthmus\>** https://github.com/monero-project/monero/issues/5712
**\<UkoeHB\_\>** ah
**\<Isthmus\>** The core wallet has observed a 10-block lock time, so they must have been generated by custom software
**\<Isthmus\>** But now it's a consensus rule
**\<sarang\>** To what extent does the visual fingerprint identify the extent to which the transaction is nonstandard?
**\<sarang\>** e.g. can you look at a fingerprint and see "oof, this transaction is \_very\_ nonstandard!"
**\<sarang\>** (obviously the Hamming weight of the input will tell you this by inspection)
**\<Isthmus\>** No, since the visual hash function is appropriately unstable
**\<UkoeHB\_\>** You could look at the fingerprint string itself to see how different, since more 1s = more different
**\<sarang\>** That's what I mean by the Hamming weight
**\<Isthmus\>** aaaactually if the hamming weigh was used to select the colorscale......
**\<Isthmus\>** Then it could be intuitively accomplished
**\<Isthmus\>** if colorscale(0) is greenish
**\<sarang\>** At that point, what's the usefulness of the fingerprint shape?
**\<sgp\_\>** going all the way back to the unlock time proposal, I still think the tradeoffs aren't worth it
**\<Isthmus\>** Because 0010 and 0001 are different
**\<sarang\>** True
**\<sarang\>** So it really only tells you if the actual strings are different
**\<sarang\>** I guess I figured the "more useful" component in general might be the Hamming weight
**\<sarang\>** since one goal is to minimize it
**\<Isthmus\>** It depends if 'degree of wrongness' is important
**\<UkoeHB\_\>** I agree sgp\_ it feels quite expensive
**\<Isthmus\>** From my perspective, 0010, 0001, and 0011 are 3 distinct signatures
**\<Isthmus\>** Even though 0011 is more worse :- P
**\<UkoeHB\_\>** ArticMine: how is it going with your penalty/fee proposal?
**\<sarang\>** While we wait to see if ArticMine is around, were there any other questions on the material Isthmus presented?
**\<sgp\_\>** none about the presented material, but I eventually have a question for Isthmus about the coinbase vs non-coinbase spend distributions
**\<Isthmus\>** Hey @sgp\_ what do you have in mind? :- )
**\<sarang\>** I would also be interested to see that for BTC
**\<sgp\_\>** heelo Isthmus :)
**\<sgp\_\>** s/heelo/hello
**\<monerobux\>** sgp\_ meant to say: hello Isthmus :)
**\<sgp\_\>** I really want to segregate coinbase outputs form other outputs
**\<sgp\_\>** to do this, I ideally would like to know what the independent spend distributions are for these two categories of outputs
**\<sgp\_\>** my suspicion is that coinbase outputs are spent faster on average
**\<Isthmus\>** We can ascertain this by subtracting the reference distribution from the observed ensemble distribution
**\<Isthmus\>** And split it by type:
**\<Isthmus\>** distribution(coinbase inclusion in rings) - reference\_distribution
**\<Isthmus\>** distribution(non-coinbase inclusion in rings) - reference\_distribution
**\<Isthmus\>** I think @binaryFate was going to present this type of analysis at Konferenco, though I don't know if was split up by output type (non/coinbaase)
**\<sarang\>** Having a direct measurement from something like BTC would be very helpful regardless
**\<sarang\>** ideally to follow the Miller et al. idea of comparing known-estimated Monero behavior to BTC
**\<Isthmus\>** I'll see about extracting true BTC spend times from Google's BigQuery dataset
**\<sarang\>** That'd be great
**\<Isthmus\>** There's probably some way to do it in a clever SQL one-liner
**\<Isthmus\>** But I can do it in 20 lines!
**\<Isthmus\>** :- P
**\<sarang\>** Separately, it would also be interesting to see how/if overall BTC spend times have changed since Miller et al.'s paper
**\<sarang\>** They used two different large groups of blocks
**\<sgp\_\>** we need to have some selection for the coinbase-only rings in any case, though if the results show that the distributions are different, then that's even more reason to segregate
\< this
**\<sgp\_\>** note I still support coinbase-only rings even if the distributions are exactly the same :p
**\<sarang\>** In the interest of time, were there any other topics to be brought up before moving on?
**\<sgp\_\>** that's all fro me, thanks Isthmus
**\<sgp\_\>** \*from
**\<UkoeHB\_\>** Any new comments on the Tx Supplement proposal?
**\<sarang\>** Restructuring for uniformity and Janus mitigation seems useful and reasonable to me, FWIW
**\<sgp\_\>** agreed
**\<sgp\_\>** costs are small
**\<sarang\>** Especially with the savings from CLSAG
**\<Isthmus\>** I'm in favor. Uniformity is the whole point.
**\<ArticMine\>** UkoeHB\_ It is almost done. I held it back to give ti ore thought especially with COVID-19 which is a perfect scenario for the issue
**\<ArticMine\>** I should have this in the next two weeks
**\<UkoeHB\_\>** Cool thanks :)
**\<sarang\>** OK, with the last few minutes of the hour, let's get to ACTION ITEMS
**\<sarang\>** I would like to finish the update of the Arcturus security model, to get the updated preprint submitted for review
**\<sarang\>** And will be discussing the CLSAG audit with Teserakt
**\<sarang\>** Anyone else?
**\<UkoeHB\_\>** In the tx supplement proposal I recommend moving to sorted TLV in the extra field. However, it's not completely solved. One option is to retain 'restricted tags' for core features (e.g. encrypted payment IDs, miner nonce). Are restricted tags worthwhile or too hands-on?
**\<sarang\>** Well, certain tags would be required by consensus... can you refresh us on your definitions here?
**\<UkoeHB\_\>** Moving to restricted tags might force more uniformity out of pool implementations, since there would be a fixed miner nonce size. However, they could just move their unique nonces to unrestricted tags.
**\<UkoeHB\_\>** Only encrypted payment IDs would remain in the extra field after the update
**\<UkoeHB\_\>** And miner extra nonce
**\<UkoeHB\_\>** So not much consensus left
**\<sarang\>** Oh, TLV for \_extra only\_... of course
**\<sarang\>** nvm
**\<sarang\>** I was thinking about fields in general, which is not correct
**\<UkoeHB\_\>** With a restricted miner nonce we (probably I) could release a miner nonce guideline for pool implementer to reference
**\<UkoeHB\_\>** If it's easy enough then hopefully most pools and solominers would be indistinguishable on-chain
**\<sarang\>** OK, any other questions, topics, or action items before we adjourn?
**\<h4sh3d[m]\>** I posted a proposal for the atomic swap, feedback are welcome
**\<sarang\>** Link?
**\<h4sh3d[m]\>** https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/145
**\<sarang\>** thanks
**\<sarang\>** All right, let's adjourn in the interest of time (and for log posting purposes). Thanks to everyone for attending!

177
_posts/2020-05-27-mrl-meeting.md Normal file
View File

@ -0,0 +1,177 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-05-27
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, it's time for the meeting!
**\<sarang\>** As usual, begin with GREETINGS
**\<Isthmus\>** GREETINGS
**\<ArticMine\>** Hi
**\<sarang\>** hello
**\<knaccc\>** yo
**\<knaccc\>** very nice :)
**\<sarang\>** Subtle!
**\<sgp\_\>** hello
**\<sarang\>** OK, let's move to ROUNDTABLE
**\<sarang\>** I'll start with a few things
**\<sarang\>** A preprint came out from student researchers at CMU on Monero and Zcash tracing: https://eprint.iacr.org/2020/593
**\<sarang\>** It only looked at pre-Sapling Zcash data that was previously examined (independent checking of earlier work is valuable)
**\<sarang\>** but did look at much more recent Monero transactions
**\<sarang\>** The overall conclusions are that protocol improvements have been very useful
**\<sarang\>** I disagree completely with their methodology leading to a conclusion about the effectiveness of the updated output selection algorithm, however
**\<sarang\>** and I think they can't reach any conclusions from that
**\<sarang\>** I put together some notes and sent them to the authors, along with my thanks for their work
**\<sarang\>** They did make their analysis code available on GitHub, so I'm going to see what useful information can be pulled from that as well
**\<sarang\>** Separately from this, I'm working on some non-slanderability definition stuff to port from Omniring's security model to that of Arcturus now
**\<sarang\>** Worked on address verification proof updates with moneromooo
**\<sarang\>** and wrote up some test code for the view tag scanning idea
**\<knaccc\>** in what lang?
**\<sarang\>** As described by UkoeHB\_ earlier, the idea is to include a small truncated hash of the key derivation for each output, and use this for a "fast scanning" mode that avoids some curve operations
**\<sarang\>** knaccc: timing code in the C++ codebase
**\<sarang\>** It's not an implementation, only for getting timing information
**\<sarang\>** Under the assumption that a view tag is a single byte and only 1 out of every 256 tag checks results in a match, here are the numbers
**\<sarang\>** On a particular test machine, the total scan cost \_without\_ view tags for those 256 checks is 43.520 ms
**\<sarang\>** The total scan cost \_with\_ view tags (and a single match in the group) is 32.559 ms
**\<sarang\>** That means the fast scan mode operates in 75% of the time as the standard scan mode, in this example
**\<knaccc\>** how many txs in total were you scanning?
**\<sarang\>** This wasn't an actual scan; it was a simulation that performed all the operations for fake outputs generated by the test code
**\<knaccc\>** i just mean, what was the ratio of matching outputs to outputs scanned
**\<sarang\>** It built a view tag and output key, and then timed the scanning under various modes
**\<sarang\>** This assumed 1/256
**\<sarang\>** Purely statistical
**\<knaccc\>** when you hit that 1 in 256, are you including the cost of the extra scalamultbase to then properly check?
**\<sarang\>** Yes, let me explain a bit
**\<sarang\>** The test has 3 modes
**\<sarang\>** Mode 1. standard scanning, no view tags
**\<sarang\>** Mode 2. view tag, no hit (compute the derivation and view tag, and then abort)
**\<sarang\>** Mode 3. view tag, hit (after the derivation and view tag check, recompute the expected spend pubkey)
**\<sarang\>** So the "no view tags" total assumes 256 Mode 1 operations
**\<sarang\>** The "yes view tags" total assumes 255 Mode 2 operations, and 1 Mode 3 operation
**\<ArticMine\>** There is the question also of non standard math
**\<sarang\>** ?
**\<sarang\>** knaccc: the test code actually always generates a matching view tag and output key (for sanity checking), but the simulation just uses the modes to fake whether or not a match occurred (there's no difference in timing doing it this way)
**\<knaccc\>** your findings roughly match up with the back-of-envelope calc that if you almost always save on a scalarmultbase, and if variable-base scalarmult costs 25 and a fixed-base scalarmult costs 15, then you reduce the scanning cost from 100% to 25/(25+15) = 62.5%
**\<ArticMine\>** for Arcturus
**\<sarang\>** ArticMine: view tags are entirely separate from Arcturus
**\<ArticMine\>** sorry
**\<sarang\>** They apply generally to the output key construction process
**\<sarang\>** which is abstracted away from Arcturus anyway
**\<sarang\>** The added risk with view tags is that a sending wallet can generate whatever tag it wants, and the receiver would not detect the output
**\<sarang\>** But FWIW the reverse isn't true... you can't DoS a scan with this method
**\<sarang\>** Bad view tag implementations could also fingerprint if a wallet did something silly like always set it to a fixed value
**\<sarang\>** Of course, compatible recipient wallets wouldn't detect it if they did fast scanning, and this would not look good for the incompatible sending wallet anyway
**\<sarang\>** Here's the timing code: https://github.com/SarangNoether/monero/commit/93172f80b2c25def9aaf40fc30dbee54f92f47a5
**\<sarang\>** (it does pass build checks, but Windows CI is broken)
**\<knaccc\>** i wonder where the difference is between the 75% real-world and 62.5% theoretical
**\<knaccc\>** i'll read through your code
**\<sarang\>** There is a small cost for each hash computation, and for the few non-scalarmult operations
**\<sarang\>** Yeah, let me know if you notice something that I missed
**\<knaccc\>** those are usually neglibible compared to .15ms or .25ms for an EC mult
**\<sarang\>** aye
**\<sarang\>** IIRC the hash stuff is something like 2-3% of the total time
**\<knaccc\>** i don't see anywhere in your code actually referencing loop\_count
**\<sarang\>** That's taken care of by the test runner
**\<sarang\>** Which uses the individual results for statistics
**\<knaccc\>** ah
**\<sarang\>** Each test is set up by a non-timed init()
**\<sarang\>** and then timed for test()
**\<knaccc\>** makes perfect sense
**\<sarang\>** If you build yourself, just run `./performance\_tests --stats --filter=\\*view\_tag\\*`
**\<sarang\>** the `true`/`false` flags correspond to the bools in the test definition
**\<sarang\>** Oh, the byte conversions would need to be accounted for
**\<sarang\>** They're not huge, but not negligible either
**\<sarang\>** I tend to ignore those during back-of-envelope estimates
**\<sarang\>** Anyway, that's the stuff I wanted to present here
**\<sarang\>** Are there other questions?
**\<knaccc\>** code looks good to me
**\<sarang\>** OK, does anyone else wish to present any research of interest?
**\<sarang\>** knaccc: cool
**\<Isthmus\>** Hmmm, I started wondering about something this morning...
**\<Isthmus\>** Over the last several years, I’ve had to nix a ton of cool software ideas because repeated 3-output transactions are heuristically linkable, and alternative business models (subscriptions, accounts, etc) have tons of downsides and privacy concessions compared to adding a small service fee to each operation.
**\<Isthmus\>** Now I’m wondering if this is stifling Monero adoption and integration by preventing the most straightforward and private method for compensating the developers who want to contribute new stuff to the ecosystem.
**\<Isthmus\>** If we want Monero to be used for more than point-to-point transactions, without putting the first adopters at statistical risk, there may be some pros to a 3-output minimum: recipient + change + optional service fee.
**\<Isthmus\>** Of course, for many transactions the third output will be an empty dummy. (Or people could get creative and split the return across 2 change addresses for latter flexibility, etc)
**\<sarang\>** Ah, increasing the enforced minimum to 3?
**\<Isthmus\>** It might make sense to bundle this in with bigger rings, since the ratio of (# outputs) / (# ring signatures) per unit time shouldn’t get too large (since outputs that haven’t ever shown up in a ring signature yet have a known spend state [unspent], and inforrms [with provable certainty] the sender that funds weren’t subsequently moved).
**\<Isthmus\>** @sarang yep
**\<sarang\>** Splitting change means more likely to pull in multiple change outputs in later transactions
**\<sarang\>** which is bad for linking
**\<sarang\>** Downside is chain bloat
**\<Isthmus\>** Yeah, that's why I've always advocated against people splitting up within their wallet
**\<ArticMine\>** What is the additional size per tx?
**\<Isthmus\>** 0.22 kB
**\<Isthmus\>** I think
**\<Isthmus\>** oh wait
**\<sarang\>** that seems too big
**\<Isthmus\>** That number isn't right
**\<Isthmus\>** hold on a sec
**\<ArticMine\>** If we go to 4?
**\<sarang\>** ArticMine: why 4?
**\<ArticMine\>** Is there not efficiency bullet proofs?
**\<ArticMine\>** with 4 vs 3 outputs that had to be padded
**\<sarang\>** BP padding doesn't imply extra outputs
**\<Isthmus\>** Now I'm getting pulled into a side adventure on xmrchain that I can't find any 1/3/e txns but there are lots of 1/3/s (trying to figure out what that means)
**\<sarang\>** it's merely an algebra thing
**\<sarang\>** ArticMine: it would mean that the corresponding bulletproof is a bit bigger for standard transactions
**\<sarang\>** if that's what you meant?
**\<ArticMine\>** Yes
**\<sarang\>** Ah, a 3-out BP (padded to 4) is 64 bytes larger than a 2-out BP
**\<sarang\>** (a 4-out BP is the same size as a 3-out BP)
**\<ArticMine\>** That is y point
**\<ArticMine\>** my
**\<sarang\>** got it
**\<sarang\>** Yes, you are correct that this would increase the typical range proof size
**\<Isthmus\>** Yep, it makes Monero usable for more applications and businesses, but does increase the transaction size
**\<Isthmus\>** Hm, little easter egg:
**\<Isthmus\>** There are essentially no 1-in-3-out txns with encrypted PIDs
**\<Isthmus\>** There are a few 1-in-3-out transactions with no PID at all
**\<Isthmus\>** And a few 1-in-3-out with some unusual tag in xmrchain, not sure what's in tx\_extra
**\<jwinterm\>** I guess that would make sense considering any PID tx is probably from user to exchange/service, so would likely just be one in two out
**\<Isthmus\>** Ugh, stands out as non-standard software
**\<Isthmus\>** I feel like we sometimes make things worse when we add a feature "to all transactions" in the wallet, but not the protocol :- (
**\<sarang\>** aye
**\<ArticMine\>** So is there additional bloat over the 64 bytes?
**\<sarang\>** The new output has a pubkey, a commitment, an encrypted amount...
**\<sarang\>** those three are 72 bytes total
**\<ArticMine\>** and 4
**\<sarang\>** 73 bytes if you add a view tag
**\<sarang\>** add another pubkey, commitment, amount, view tag for each output you want
**\<ArticMine\>** so 82 vs 73 bytes for 4 over 3
**\<sarang\>** No
**\<sarang\>** In addition to a possible marginal range proof increase, each additional output requires 73 more bytes for pubkey, commitment, hidden amount, [optional view tag]
**\<sarang\>** The marginal range proof increase from 2 -\> {3 or 4} is another 64 bytes
**\<ArticMine\>** So for 3 it is 137 bytes
**\<sarang\>** sounds about right
**\<sarang\>** This also implies increased scanning time (reduced by view tags)
**\<ArticMine\>** and for 4 210 bytes
**\<sarang\>** and additional scanning time
**\<ArticMine\>** Yes
**\<sarang\>** Anyway, in the interest of time, were there other topics that needed to be brought up?
**\<sarang\>** (We can always continue discussions afterward)
**\<knaccc\>** btw i'd be interested to know some examples of great use-cases for 3-out txs
**\<knaccc\>** either now or after
**\<sarang\>** Service fees are a big one
**\<sarang\>** One output goes to the recipient, one to change, one to service provider
**\<ArticMine\>** VAT / GST?
**\<knaccc\>** sarang can you be more specific about the service? just one example of something that could be common?
**\<knaccc\>** ArticMine you're suggesting paying VAT direct to the gov as part of a tx?
**\<sarang\>** knaccc: maybe you're using some kind of hosted wallet service
**\<sarang\>** Or maybe your wallet software has an option to donate a small amount to charity with each txn
**\<knaccc\>** oh right, fine yes, gotcha.
**\<sarang\>** OK, let's finish up with ACTION ITEMS if there aren't any other topics to bring up
**\<sarang\>** If/when Windows CI gets fixed up, I'll rebase some new work for PR/review
**\<sarang\>** and get Triptych and Arcturus sent off to PoPETs
**\<sarang\>** and hopefully be able to reproduce some of the results from that tracing preprint
**\<moneromooo\>** Micropayments in every tx is a great way to punch monero into the ground. We don't want to have huge amounts of dust outputs, they take up the same resources as "normal" outputs.
**\<sarang\>** moneromooo: that's what I meant by chain bloat and scan increases
**\<knaccc\>** service-fee is essential for multisig arbitration insurance fee probably
**\<ArticMine\>** but I see a slippery slope
**\<knaccc\>** eventually i think the default kind of payment tx should be multisig w/arbitration insurance fee attached
**\<knaccc\>** and multisig won't be a different type of wallet, it'll be something created on-the-fly on each payment tx
**\<sarang\>** OK, I suppose we can formally adjourn (so I can post logs), but discussion can of course continue
**\<sarang\>** Thanks to everyone for attending!
**\<knaccc\>** ^^

182
_posts/2020-06-03-mrl-meeting.md Normal file
View File

@ -0,0 +1,182 @@
---
layout: post
title: Logs for the MRL Meeting Held on 2020-06-03
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<sarang\>** OK, let's get started!
**\<sarang\>** First, GREETINGS
**\<sarang\>** hello
**\<ArticMine\>** Hi
**\<dEBRUYNE\>** hi
**\<hyc\>** hey
**\<Isthmus\>** Heyo
**\<sarang\>** Next up, ROUNDTABLE, where anyone is welcome to share research of general interest
**\<sarang\>** I have a few topics of interest
**\<sarang\>** The recent preprint from CMU student researchers on transaction tracing has been updated to reflect suggestions and corrections: https://eprint.iacr.org/2020/593
**\<binaryFate\>** hello
**\<sarang\>** The researchers still claim that a small but nonzero number of post-changeover (i.e. the RingCT protocol switch) transactions were traceable, which didn't correspond with other numbers I'd found
**\<sarang\>** So I decided to independently run the same analysis and compare
**\<sarang\>** I ran updated numbers that account for all transactions up to the beginning of this week
**\<sarang\>** If you run a full chain-reaction-type analysis, there are 7303 transactions after the changeover containing at least one deducible input
**\<sarang\>** However
**\<sarang\>** All of those transactions spend pre-changeover outputs
**\<sarang\>** So if you filter out all transactions that aren't CT-in-CT-out, there are still precisely 0 deducible transactions/inputs
**\<sarang\>** But wait, there's more!
**\<sarang\>** The preprint also tries to determine how effective the guess-newest age heuristic is against modern transactions
**\<sarang\>** Unfortunately, it uses those 7303 (or however many were in their block range) deducible post-changeover transactions as ground truth
**\<sarang\>** and assumes that holds for all post-changeover transactions
**\<binaryFate\>** huh that's pretty dumb
**\<sarang\>** I wouldn't say it's dumb; it just failed to account for transaction types
**\<ArticMine\>** So the key here is RingCT
**\<sarang\>** Because there are "full-CT" transactions post-changeover that are deducible, the entirety of their ground-truth data set is based on spends of old funds, for which the modern selection algorithm does not apply
**\<sarang\>** But there is an interesting twist
**\<dEBRUYNE\>** To be clear, it concerns transactions were non-RingCT outputs are essentially converted to RingCT outputs, right?
**\<sarang\>** Among that ground-truth data set, the researchers find those transactions are \_still\_ twice as good against guess-newest from Miller et al.!
**\<sarang\>** dEBRUYNE: yes, or that aren't converted to CT at all
**\<sarang\>** (very limited cases involving single inputs)
**\<moneromooo\>** \> Because there are "full-CT" transactions post-changeover that are deducible,
**\<moneromooo\>** Forgot a no, right ?
**\<sarang\>** Correct, thank you
**\<sarang\>** because there are NO full-CT post-changeover that are deducible (typo)
**\<dEBRUYNE\>** sarang: Thanks, I guess those are dust outputs then that first have to be converted to standardized outputs
**\<dEBRUYNE\>** dust or non-mixable
**\<sarang\>** So the conclusions presented in the paper about transaction counts aren't wrong, but don't differentiate between type, which I think is very important
**\<sarang\>** The conclusions about guess-newest are only valid for their ground-truth set, and cannot be extrapolated to CT transactions
**\<binaryFate\>** The wallet warns you when you spend old outputs that privacy is lessen and it's known you should churn in that case. It should absolutely be mentioned in their paper that these transactions are particular and users are fully informed of the risk
**\<sarang\>** I'm drafting an email to the authors to let them know of this, should they wish to revise again
**\<sarang\>** They were very prompt in responding to my earlier email, and very quickly revised, which was great
**\<sarang\>** Now that I have a complete deduced data set, I'm checking their results on effective anonymity sets of non-deduced transactions
**\<sarang\>** I want to separate those by transaction type as well
**\<sarang\>** Even though the preprint had errors, I'm glad they did the research
**\<sarang\>** We should encourage student researchers
**\<binaryFate\>** I'm unclear on the guess-newhest on this dataset
**\<sarang\>** How so?
**\<binaryFate\>** Since this dataset is specifically about real output being old, shouldn't that give very specific results when seeing how the heuristic performs, that can't be extended to other transactions?
**\<sarang\>** Yes
**\<sarang\>** That's what I was saying earlier
**\<sarang\>** They assumed their ground-truth post-changeover dataset was representative of all post-changeover transactions, which is entirely false
**\<UkoeHB\_\>** pre-ringCT inputs could be used in rings just like modern coinbase outputs are, which makes me sad
\<= Yes, because uninformed readers may infer that it concerns full RingCT transactions
**\<binaryFate\>** IIRC the decoy selection algorithm is very different for these transactions, only selecting non-ringct. Since all of them are very old, they are old on the tail of the gamma distribution, very different from recent one
**\<moneromooo\>** Using pre-ringct outs as fake outs would help shortly after ringct, but would otherwise introduce a number of known spent outs in rings.
**\<binaryFate\>** \*they are all
**\<sarang\>** When I finish the effective anonymity data, it should give a much more clear picture of the status of modern transactions (before and after ring increases too)
**\<sarang\>** The code still needs some cleanup to make it easier for others to run this analysis, either now or in the future
**\<UkoeHB\_\>** interesting point moneromooo
**\<sarang\>** thanks to gingeropolous for the use of a fast machine for this analysis
**\<sarang\>** If the researchers choose not to revise, I can always write a new preprint that presents this data
**\<sarang\>** but I strongly suspect the researchers will revise again, since they did a very prompt first revision
**\<binaryFate\>** super cool that you checked all these results
**\<hyc\>** sounds great
**\<sarang\>** I can also post the raw data for the post-changeover deducible transactions, in case anyone wants to specifically analyze them
**\<hyc\>** super cool that their work is pulblicly reproducible
**\<sarang\>** Again, I'm really glad they did the analysis
**\<sarang\>** Yeah, I didn't end up using their Java code though
**\<sarang\>** I wanted some extra data they didn't provide, so I rewrote
**\<sarang\>** but kudos to them for making all their code public, for sure
**\<UkoeHB\_\>** I'd like to see if the code can be adapted to a certain analysis I have in mind, so I'm looking forward to it
**\<moneromooo\>** Not really. More like negative kudos for those that don't.
**\<sarang\>** What analysis is that UkoeHB\_?
**\<hyc\>** moneromooo: yes but that still tends to be the majority these days
**\<moneromooo\>** Papers without it are really hearsay. Should never be published.
**\<UkoeHB\_\>** getting data on ring loops, and comparing to a purely randomly generated ring db
**\<sarang\>** Define ring loop
**\<hyc\>** moneromooo: agreed
**\<moneromooo\>** A ring is a circular construct. A loop is.... a.......
**\<UkoeHB\_\>** e.g. two outputs are owned by the same person, a loop is when their descendents intersect in the same tx
**\<sarang\>** Oh, output merging
**\<sarang\>** ?
**\<moneromooo\>** Can happen by chance too (from fake outs).
**\<sarang\>** yes
**\<UkoeHB\_\>** yeah basically, so I want to see the probability of given loop sizes happening randomly
**\<sarang\>** I think the question is how likely it is to occur in practice vs not
**\<Isthmus\>** @UkoeHB\_ important research. Results will be probably be depressing :- (
**\<moneromooo\>** If it was super fast, it'd be nice for the wallet to try and pick fake outs that generate "false positives".
**\<sarang\>** There's code that will do forms of merge analysis, and it's something I have to add specifically to my check code
**\<sarang\>** The graphs involved are likely quite large, so it isn't clear what the complexity of this is
\<
**\<sarang\>** FWIW the early analysis on output merging used deducible transactions only
**\<UkoeHB\_\>** right, I have some ideas about limiting the output range to first estimate exactly how long such analysis would take; can also limit the maximum loop size considered
**\<Isthmus\>** UkoeHB\_: to generate random data set, will have to select guesstimates for parameters like number of transactions per wallet. (really, would be a distribution, not single value)
**\<sarang\>** yes
**\<Isthmus\>** The interesting thing is that we may be able to establish statistical estimates of these parameterss based on the real blockchain data
**\<UkoeHB\_\>** Isthmus we can just use the transactions that already exist, but make the input rings randomly selected; this provides a direct comparison with the real ring db
**\<Isthmus\>** Especially if rare "natural" occurrence, i.e. low false positive rate
**\<sarang\>** This sort of analysis was considered as a major part of the churn framework as well
**\<UkoeHB\_\>** and do the randomly generated analysis multiple times for variance
**\<Isthmus\>** Makes sense
**\<sarang\>** Anyway, I've taken up a lot of time on that
**\<sarang\>** Was there other research of interest to discuss from anyone?
**\<Isthmus\>** I'll be interested in seeing plots where x-axis is # of txns made within a given wallet, and y-axis is statistical measures, like precision/accuracy/etc
**\<Isthmus\>** I have a few quick updates
**\<Isthmus\>** I’ve been doing some p2p network scalability research, creating some testing suites, etc. Still very early reading/planning, but hopefully will have some actionable insights for Monero.
**\<UkoeHB\_\>** yes it's a big project and might be worthy of a paper if it goes somewhere, we will see; I also want to see how well the gamma distribution is working by subtracting the theoretical distribution from what we have in reality
\< YES PLEASE
**\<Isthmus\>** @UkoeHB\_ I have some algorithms floating around GitHub to identify and filter txns that use uniform decoy selection instead of correct algo. If you don't strip those out, it will introduce a bias in your results towards older oututs
**\<Isthmus\>** I'll dig those up and send links
**\<UkoeHB\_\>** cool thanks
**\<sarang\>** Yeah, trying to exclude old software will be important
**\<sarang\>** since there's no consensus enforcement
**\<UkoeHB\_\>** I think ring analysis is too scary for anyone to tackle alone, so a collaborative and incremental effort seems reliable
**\<Isthmus\>** Software can't be any older than the last ring size change, right?
**\<sarang\>** Sorry, I meant software using old/incorrect methods
**\<sarang\>** "nonstandard" is a better term
**\<sarang\>** A big reason why deterministic input sets are intriguing is because they're likely to contain many outputs from the same transactions
**\<sarang\>** and therefore are included as a "standard feature" of all rings
**\<binaryFate\>** "see how well the gamma distribution is working by subtracting the theoretical distribution from what we have in reality" I was doing stuff in that direction too, exciting!
**\<UkoeHB\_\>** I think I missed the last meeting. The Janus proposal was updated a week ago (https://github.com/monero-project/monero/issues/6456), and now the Janus mitigation is to encode the tx private key for recipients. For 2-out tx where there will only be 1 tx pub key, the 'change output' would use a 'hidden tx pub key' derived from the non-change recipient's encoded tx private key. An alternative would be for the
**\<UkoeHB\_\>** change output to use a unique 'derivation to scalar', however I am concerned that affects too much protocol-level code (could be wrong).
**\<binaryFate\>** What happens where there is a 2-out tx but none of them is change?
**\<Isthmus\>** I think you have to make a 3
**\<Isthmus\>** 3-output then?
**\<UkoeHB\_\>** The proposal is to enforce 1 tx pub key for 2-outs, and 1 key per output for \>2-outs. All tx with no change output would have to be \>2-out, even if it means adding a dummy output.
**\<moneromooo\>** A 0 change is automatically added \*only\* if there's one output otherwise.
**\<UkoeHB\_\>** Right, and following the proposal there would be a very rare case of 2 non-change outs needing a dummy
**\<Isthmus\>** It's an edge case, so I perceive this as a reasonable solution
**\<UkoeHB\_\>** Originally encoding the tx private key was disregarded since current tx share tx pub keys, but since we'd start enforcing more tx pub keys that problem is solved.
**\<UkoeHB\_\>** i.e. as a solution for Janus\*
**\<UkoeHB\_\>** Well, the hidden tx pub key might be unnecessary now that I think about it.. anyway that's my dusty update.
**\<ArticMine\>** but does this means that a 2 out tx always has change real or dummy
**\<UkoeHB\_\>** yes
**\<ArticMine\>** Can this then be attacked?
**\<UkoeHB\_\>** the idea that there is always a change output in 2-out tx? that assumption can be made today already
**\<Isthmus\>** Oh no wait, it would just move the issue to n+1
**\<sarang\>** Sorry, connection problems; back now
**\<ArticMine\>** but not with 100% certainty
**\<UkoeHB\_\>** well the shenanigans around 2-out tx are mostly to optimize scanning and tx sizes, since 2-out tx are ~95% of tx
**\<UkoeHB\_\>** that's true ArticMine
**\<luigi1111w\>** one can assume with high certainty that every transaction contains a change output. I don't understand why that's a significant observation.
**\<Isthmus\>** Most txns. Churn doesn't, for example.
**\<sarang\>** ^
**\<moneromooo\>** Why does it not ?
**\<sarang\>** Doesn't have to
**\<sarang\>** And would affect output merging later
**\<moneromooo\>** Well, that's circular reasoning then.
**\<Isthmus\>** Churning with change creates the loops UkoeHB\_ mentioned earlier
**\<luigi1111w\>** churn has two change outputs, no?
**\<ArticMine\>** It can
**\<luigi1111w\>** or one and a fake one
**\<UkoeHB\_\>** churn has an 'output to yourself' and a 'change output'; change outputs are handled differently in the code
**\<luigi1111w\>** sure but this is from a network perspective
**\<UkoeHB\_\>** yeah
**\<ArticMine\>** Or a split 2 separate wallets under the control of one person
**\<ArticMine\>** It introduces uncertainty
**\<luigi1111w\>** but why does it matter?
**\<ArticMine\>** because even a small bias can grow.
**\<sarang\>** Given the time, is there other research that needs to be brought up before adjourning?
**\<Isthmus\>** I've got 2 updates, will keep brief for sake of time:
**\<Isthmus\>** Our CCS for researching Monero’s post-quantum security is sooooooo close. Only 7% left, less than 40 XMR needed. https://ccs.getmonero.org/proposals/research-post-quantum-monero.html
**\<Isthmus\>** If that could get topped off today, we’ll dive in immediately and have our first update at next week’s MRL meeting. :- )
**\<Isthmus\>** Unrelated - I also have one of Insight’s DistSys engineers buildling “speedup” networks, i.e. highly-connected peers with high bandwidth to propagate blocks/txns through the ad hoc network faster than organic propagation. Main goal is to eliminate the long tail in block propagation times.
**\<Isthmus\>** The codebase is very modular with Terraform/ansible deployment and control scripts, so could be configured to spin up a Monero speedup network in the future.
**\<Isthmus\>** That's all from me.
**\<sarang\>** Nice!
**\<sarang\>** I suppose I should mention that I welcome/request comments/questions/emoji on my funding proposal as well, so a decision can be made whether to open it: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge\_requests/148
**\<luigi1111w\>** thanks for opening it well in advance
**\<sarang\>** OK, I suppose we can formally adjourn for the sake of logging
**\<sarang\>** Thanks to everyone for joining in today
**\<sarang\>** Discussion can of course continue!