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