00:45:00 atomic swaps sounds great until you sit down and think about what you're going to get in return for your swap 00:51:36 Atoms ? 01:37:56 I guess that'd be a step up from just electrons 05:35:15 I'll swap you some of my lead atoms for some of your gold atoms 06:15:56 I'll only accept neutrons 06:31:36 I sent you some Neutrinos. Did you get them? 07:44:15 *one small nuclear explosion later* 07:50:22 Hm. I wonder if there is economy in it for big miners to add an unreasonable amount of cheap spam transactions to BTC when there is traffic, to force those who need to send transactions, to pay more .. best case the spam TX just time out, and the increased revenue from real transactions more than make up the diff? 07:50:48 I guess something like that might not be feasible in XMR due to how the fees work. 09:29:32 a decent btc fee estimator uses mempool tx depth (depth being in virtual Bytes[vB] with txs sorted by fee [sat/vB]), so one can jump the line easily in front of these spam txs by paying 0.01 sat/vB more than the spam txs. the real issue is when these spam txs pay expensive fees, and a large quartel of miners make sure they do not get included in a block -- but if they do get included, the attackers have to pay for 09:29:32 it 09:49:04 currently there is like 20+ MB of 1 and 2 sat/byte transactions, and if you want to get in the next few blocks you are paying 20-30 sats/byte. Of course this could just be consolidations (the low fee transactions seem to be pretty large on average) 09:51:28 Inge-: have a look here https://fee.cryp.ee/ 09:53:33 right now u should not pay less than 2.129 sat/vB, that would be really stupid 10:08:37 Nice page 16:40:23 Research meeting begins at 17:00 UTC (about 20 minutes from now) 16:46:22 sarang mah boi 16:58:06 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 16:58:26 (will mention during the meeting, just sharing early in case anybody wants to get a head start reading it) 16:59:22 Most of the changes are in the Roadmap section 16:59:49 OK, let's get started! 16:59:57 The usual agenda: https://github.com/monero-project/meta/issues/462 17:00:03 First, GREETINGS 17:00:08 Hi 17:00:59 hello! 17:01:14 Heyo 17:01:30 Hello 17:02:11 Hi 17:02:54 Next up is ROUNDTABLE 17:02:55 hi 17:03:05 Does anyone have research of interest to share with the group? 17:03:15 I know Isthmus just mentioned something before we started 17:03:55 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 17:04:00 Most of the changes are in the Roadmap section 17:04:51 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: 17:04:58 "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." 17:05:10 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: 17:05:15 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). 17:05:21 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. 17:05:26 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. 17:05:32 Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos. :- ) 17:05:56 (ends notes) 17:06:09 Oh, I'll X-post the proposal to Reddit today 17:06:20 I like the change in scope, particularly focusing on communicating the current state of the protocol 17:06:51 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 17:07:15 ^ yep 17:07:15 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 17:07:15 discover new faster/smaller proving systems, so these practical barriers are temporary. 17:08:45 Were there any questions for Isthmus about this proposal? (Comments could also be made on the proposal itself to reach a wider audience) 17:09:13 nop 17:09:52 OK, does anyone else wish to share research of interest? 17:10:19 If not, I have a few items to share 17:10:39 Yes, I have something 17:10:55 Earlier someone posted this: https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f 17:11:17 Ah yes, the atomic swap idea 17:11:45 I had a closer look. The interesting part is the usage of ECDSA adaptor signature 17:12:12 Avoids the use of hash preimage proofs IIRC? 17:12:19 (I have yet to examine it in detail) 17:12:46 Yes, the protocol is very close what I already shared here 17:13:37 But with the idea of using a cross group dl-proof with an ECDSA adaptor signature might work 17:13:59 At the very least, a cross-group DL equivalence proof is very straightforward 17:14:08 and exists today 17:14:43 Yes, that's why it's interesting =) 17:14:51 The new part for me is this: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html 17:15:11 Is that link related to the gist? 17:15:41 Very cool 17:15:59 Ah, the link is from the gist 17:16:00 Yes, it's the first link "single signer ECDSA adaptor signatures" in the Gist 17:16:05 got it 17:16:27 I'm excited to work it out in detail! 17:17:57 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) 17:19:05 I'd be happy to work on this too. As zkao mentioned it earlier we are thinking about a proposal if it make sense 17:19:29 Having more eyes on ideas like this is definitely a good thing 17:20:17 Thanks for sharing this h4sh3d[m] (and zkao earlier as well!) 17:20:32 Were there any questions for h4sh3d[m] ? 17:20:36 Cool, I'll continue posting my findings here in the next days. 17:20:41 Thanks, please do 17:21:34 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 17:21:51 weeeeee!!!! 17:21:59 The usual disclaimer that it has not undergone any kind of review, and should be considered unsafe for production use 17:22:09 However, I got timing data from it 17:22:34 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) 17:23:10 The results, which I'll paste in just a sec, show that transaction input/output structure plays a role in the overall timing results 17:24:15 Here is data for 1-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/KZxENlzN/timing-1-2.png 17:24:36 Here is data for 2-in-2-out transactions: https://usercontent.irccloud-cdn.com/file/Ww2hDEbo/timing-2-2.png 17:24:56 These account for the total verification time for signature/proof verification and balance checks 17:25:06 but does not include range proof verification (that's the same for all protocols) 17:25:54 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) 17:27:02 The grey lines are centered at the 11-MLSAG point to show the current timing 17:27:52 it looks super close to Triptych, any hunch how it would look like for more-inputs and/or more-outputs? 17:28:34 At higher ring sizes, Triptych and Arcturus should stay very close, as the balance check component becomes less relevant overall 17:29:27 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) 17:29:40 and that difference goes away at higher ring sizes 17:29:48 The real benefit is in transaction size 17:30:13 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 17:32:35 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 17:34:43 Were there any other questions for me on these topics? 17:34:48 Oooooh ^_^ 17:38:03 Does anyone else have topics to discuss for the roundtable, before we move on? 17:38:24 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... 17:38:27 I'll try to prototype it this weekend so I can share examples next week (kind of hard to describe abstractly) 17:39:46 Oh man, I remember that seashell work! It's been a while 17:40:51 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 17:41:47 I suppose we can move on to ACTION ITEMS and finish up the meeting if there isn't anything else to discuss 17:41:49 I wish we could display seashells in CLI wallet. 17:42:56 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 17:43:09 Anyone else? 17:45:08 I'll study more in details adaptor for ECDSA and rewrite the concerned parts of the atomic swap paper. 17:45:31 You mean updating your original write-up? 17:45:38 yes 17:45:43 Excellent 17:48:56 All right, I suppose we can adjourn; thanks to everyone for participating! 17:49:03 Logs will be posted shortly to the agenda issue 17:49:21 Thank you 17:49:48 thank you! 17:50:26 gg 18:09:57 o/ 18:26:49 \o 18:27:02 sarang where can I find the meeting notes? Wanted to share those since they included discussion of the atomic swaps protocol 18:27:09 Google is being very unhelpful in finding those notes lol 18:27:27 https://github.com/monero-project/meta/issues/462#issuecomment-628148250 18:27:40 I always post meeting logs to the corresponding agenda issues on the meta repo 18:28:01 ah thanks! 18:28:01 Logs for the whole channel (and others) are also available: https://monerologs.net/monero-research-lab 18:29:00 The second link is a better interface 18:29:09 I don't recall who runs that service 21:09:22 sarang: Hi :) 21:09:27 fort3hlulz: You can use monerologs to link to a specific message by clicking on the time next to it, might come in handy if you want to point someone to a specific part of the discussion. 21:09:46 Hello 21:53:14 I have size data for signatures/proofs that account for multiple spends: MLSAG, CLSAG, Triptych, Arcturus 21:53:32 For 1-input txs: https://usercontent.irccloud-cdn.com/file/JdqIK3cU/size-1.png 21:53:46 For 2-input txs: https://usercontent.irccloud-cdn.com/file/P3KAaiCY/size-2.png 21:53:59 For 16-input txs: https://usercontent.irccloud-cdn.com/file/fmQTwrbs/size-16.png 21:54:17 This accounts _only_ for signatures/proofs required for spends, as well as commitment offsets if needed 21:54:29 It does not account for range proofs or other auxiliary data common to all constructions 21:54:42 Arcturus does not require commitment offsets 21:55:01 The grey lines are at N=11 on all plots, the current network-enforced ring size 21:55:42 If anyone needs an alternate form of the plot (e.g. if you are not able to discern the color differences) please let me know 21:56:26 Note that 1-input and 2-input transactions are by far the most common on chain 22:00:53 woh 22:01:20 The major difference is that all non-Arcturus constructions on the plot require a separate proof/signature for each spend 22:01:34 Whereas Arcturus has a single proof (and also does not require commitment offsets) 22:01:42 so whats the downside 22:01:48 (these are also called "pseudo-output commitments"... but I hate this terminology) 22:02:13 The downside is that all non-CLSAG protocols require a modified linking tag construction that makes multisig irritating 22:02:24 and Arcturus relies on a non-standard cryptographic hardness assumption 22:03:48 Submitting Arcturus to a conference (which I'm doing) will help to increase the number of experienced eyes on it 22:03:59 but its security model could use some improvement first 22:05:07 oh multisig 22:05:13 yep 22:05:28 We have a method to do it, but it's not as straightforward as with {M,C}LSAG