<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: db33d18bb8 <sarang> And the 3-Triptych concept code: f7581a385d <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!