00:26:08 overleaf borked for anyone else? 00:31:43 [keybase] : Was fine for me a few hours ago 01:55:48 Hey y’all sorry I’ve been AWOL 01:55:53 Did we solve privacy yet? 01:56:24 Also, I want in on this Keybase bridge 01:58:52 How much do you think subaddresses are used? 01:59:12 I’m going to poke at the data tonight, and probably post spoilers tomorrow. So if you want to place your bets, do so now 02:01:22 [keybase] : I don't want to speculate about that 14:41:30 Stanford conference streaming is available: https://livestream.com/accounts/1973198/BlockChain2020 14:41:42 or on YouTube: https://www.youtube.com/watch?v=JhZUItnyQ0k&feature=youtu.be 14:41:46 starts in ~2 hours 14:52:16 Schedule of talks: https://cbr.stanford.edu/sbc20/ 17:07:03 Stanford conference livestream is starting now 17:28:52 Research meeting here starts at 18:00 UTC (about half an hour from now) 17:46:25 Aw nobody took the bait on guessing subaddress adoption 17:46:41 I'll be around for a few minutes, but have some outlier meetings this morning 17:46:59 peanut gallery says significant 17:48:04 Do you want to present data right away? Or before meeting? 17:48:06 ^ Isthmus 17:58:28 I don't think it will be too much, maybe 10% or less. AIUI most tx volume is exchange related. Though maybe exchanges do use them, in which case 30% not surprising 18:00:49 OK, let's get started with the meeting 18:00:51 GREETINGS 18:01:11 hello :) 18:01:17 Hello 18:02:56 * needmonero90 waves 18:03:01 I caught the meeting! 18:03:09 I would like to note that the meetings are not listed in the calendar 18:03:14 idk if thats intentional 18:03:38 Which calendar? 18:03:42 Hi 18:03:45 And how are meetings applied to it? 18:04:25 Hi 18:04:39 Meeting times/agendas are always listed as meta repo github issues 18:05:21 Anyway, does anyone wish to begin the ROUNDTABLE with research topics of interest? 18:05:39 Yes 18:05:49 Take it away UkoeHB_ 18:06:55 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. 18:06:58 https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf 18:07:28 Neat 18:07:31 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 18:07:36 Are you seeking analysis on those? 18:07:40 Which is issue #70 18:07:52 They are open for comments any time anywhere 18:08:39 Ah and sarang provided a draft for a tx knowledge proof chapter 18:08:59 aye 18:09:00 (not really my research :p) 18:09:16 Heh, it's more of a summary of what's in the codebase (and some changes) 18:10:20 I look forward to reading the update draft you linked 18:10:40 A number of topics here are lonely and want attention btw https://github.com/monero-project/research-lab/issues 18:11:11 \end 18:11:27 Thanks UkoeHB_ 18:11:33 Any questions or comments on those topics from anyone? 18:11:41 Yes 18:11:48 Please go ahead! 18:12:16 I have taken a look at issue 70 18:12:40 It actually has serious implications 18:13:10 When the LT medium increases substantially 18:13:44 I do have an idea for a solution 18:14:05 Very preliminary at this stage 18:14:41 As for an interim fix 18:15:36 The est is to pay the high or at least normal fee for escrows that are expected to last past the next hard fork 18:16:18 I will have comments on the issue in the next two weeks 18:16:40 end 18:17:07 Thanks ArticMine 18:17:20 Any other questions/comments from the topics presented by UkoeHB_? 18:18:32 Righto 18:18:38 I'll share a few things 18:19:01 First, the Stanford Blockchain Conference is happening right now (and the next couple of days), and has streaming available: https://cbr.stanford.edu/sbc20/ 18:19:38 Second, I did some math/code related to multiparty stuff for next-gen protocols 18:20:10 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 18:20:32 Fourth, I used chain data from n3ptune and friends to do better estimates of the cumulative effects of next-gen protocols 18:20:41 both in chain growth and verification time 18:21:01 Major caveat: these assume the same input/output distribution as the current chain, and are _estimates_only_ 18:21:12 and apply to post-bulletproof chain data only 18:21:34 https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png 18:21:58 ^ this link shows the total chain growth estimates for various protocols with varying ring size 18:22:12 namely, from 16 to 1024 in powers of 2 (lines for visual aid only) 18:22:38 Sarang would you mind adding an indicator for MLSAG and CLSAG at the 11 ring size 'point'? For reference 18:23:02 Sure, let me grab that data from my spreadsheet 18:23:07 hold please 18:23:18 Or the super steep slope from 11 to 20 lol that goes off that chart 18:24:02 Heh, I had that data but didn't include it since it's crazy linear 18:24:25 I'm running the N=11 code for MLSAG/CLSAG, which I don't have handy 18:24:44 Anyway, I'll pull up the time data while we wait 18:24:56 https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png 18:25:10 ^ verification time estimate for _group_operations_only_ at varying ring sizes 18:25:16 I think it's interesting that all these protocols/signature schemes are similar size on the small end 18:26:08 All the verification times are linear (up to a logarithmic term due to multiexp) 18:26:16 Where is tryptich multi hiding? 18:26:34 It's underneath Triptych-single 18:26:42 They're essentially indistinguishable 18:26:59 Does Triptych single have advantages over multi? 18:27:03 RCT3-multi suffers due to input padding requirements that still have a linear verification effect 18:27:15 selsta: a complete soundness proof :) 18:27:33 Update on MLSAG/CLSAG size estimates... 18:27:44 Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable 18:27:57 At N=11, MLSAG for that chain range is 7.84 GB, while CLSAG is 5.84 GB 18:28:25 (the actual size of that chain range is 7.9 GB) 18:29:47 https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png 18:29:54 ^ same time data, zoomed in 18:30:29 Perfect thanks :) are time estimates for CLSAG/MLSAG available? 18:30:37 Heh, just writing that out 18:30:59 I have very early estimates on that, which are tricky since multiexp doesn't apply, and hashing is nontrivial 18:31:30 MLSAG N=11 estimate is 29.9 hours for that chain range (but I have _not_ double-checked it) 18:32:21 What hardware was used for the verification time calculations? 18:32:46 It's a single core on a 2.1 GHz Opteron machine, with a bonkers amount of RAM 18:33:01 I would rely on the timing data only for comparisons, not absolute values 18:33:32 age of CPU? 18:33:34 I am still in the process of getting CLSAG data, which requires additional test code 18:34:05 It's a gen-3 Opteron, if that's what you mean 18:34:14 Is there a way others could run the same tests? 18:34:15 Again, only estimates using performance test code 18:34:25 For next-gen protocols, it's quite easy 18:34:26 Yes great it does give an idea thanks 18:34:34 Well, somewhat easy 18:35:02 You need to get multiexp performance timing data and use a linear interpolation that you plug into the simulator 18:35:21 For MSLAG/CLSAG you need to run more operation performance data 18:35:44 This is the simulator, which is still WIP: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py 18:36:59 * Isthmus ducks in for 30 seconds 18:37:10 https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png 18:37:11 But again, it's tricky to do comparisons between MLSAG/CLSAG and the next-gens 18:37:19 * Isthmus ducks back out 18:37:27 (drive by data) 18:38:00 Wow, that's quite low 18:38:09 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 18:38:17 ;-) 18:38:32 Yep, and has certainly been a topic of interest! 18:38:33 It's a privacy risk to use subaddresses right now... 18:38:51 Anyways, I gotta bounce, sorry to spam n run 18:40:37 OK thanks for sharing the data Isthmus 18:41:10 Another good reminder that I/O structure reveals some information about subaddress use 18:41:33 Since Isthmus had to leave, were there other questions/comments on the data that I shared above? 18:42:56 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 18:43:26 My computer is quite weak, was just asking for viewers :) 18:43:32 sarang: can you remind us on the plans to fix this subaddress thing? 18:43:33 ah ok 18:44:22 Requiring separate tx keys per output is a good idea, but IIRC didn't have a huge amount of support when last brought up 18:44:56 FWIW the size data that I presented for next-gens assumes a separate tx key per output 18:45:31 Is that necessary for the protocols? 18:45:48 For the proving systems, you mean? No, not at all 18:45:58 They don't care how you get signing keys 18:47:06 Can you estimate the amount of additional pub key data? Num outs * 32 and num tx * 32? 18:47:21 sarang: why did it not get support now? complexity? size? verification time? 18:47:26 My numbers for MLSAG/CLSAG include separate tx keys too! 18:48:45 Also: n3ptune's dataset includes the pubkey counts 18:48:53 So I could run that separately for a more direct count 18:49:52 With only 3% subaddress adoption, the difference is likely on the order of 100MB 18:50:08 Or 2% of total size I think 18:50:10 that's probably a good order-of-magnitude estimate 18:50:51 But IIRC scanning requires checking all pubkeys 18:51:09 So either there needs to be a specified correlation, or there's added complexity in scanning 18:51:19 I think it costs ~1GB for 30mill pub keys btw 18:51:29 I think moneromooo had a better idea of the impacts, when it was brought up earlier 18:52:42 FWIW I think it's a good idea unless it's very compelling not to due to complexity 18:54:21 OK, we're running up to the one-hour mark... 18:54:21 obviously without this change, the impacts are quite negative for network privacy........ 18:55:00 It's differentiated data, but it doesn't leak _which_ outputs are subaddress-destined 18:55:20 (not that I'm saying that's a good reason to keep the current approach) 18:55:31 It's quite a lot of unused data, I'm a bit skeptical 18:55:32 just reveals "one of this outputs goes to a subaddres?" 18:55:43 UkoeHB_:? 18:55:54 A lot of dummy data 18:55:55 sgp_: it reveals the number of subaddress outputs 18:56:20 sarang all it reveals is at least one of the outputs must be to a subaddress 18:56:35 Doesn't it reveal the total number of sub outs? 18:56:42 No 18:57:21 orly 18:57:34 How would it? 18:57:48 Number of additional pub keys always equals number of outs 18:57:53 Even if nonsubaddress 18:58:13 How is the CLSAG paper going? 18:58:42 Hmm, for some reason I thought otherwise; noted 18:58:53 I'm still waiting for suraeNoether 18:59:04 He wanted to continue working on his ideas for the security model 18:59:11 So unfortunately I am not the one to ask 19:00:03 OK, is there anything else of interest to share? 19:00:23 (Would be a good idea to continue discussing this after meeting, or on an issue, to keep it alive) 19:00:58 definitely need an issue for it 19:01:05 All righty then; thanks to everyone for attending today 19:01:09 We are adjourned! 19:01:15 Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable >> UNREASONABLE? 19:01:23 And just in time... the next Stanford talk is about Monero and Zcash network issues that were reported and resolved 19:03:11 Two weeks later, the blockhain is synced! 19:03:44 sarang, are those tests on my poor old opterons? 19:03:48 aye 19:03:54 for consistency 19:04:09 Again, best not to use them as absolute numbers, but for comparisons 19:04:10 I am not so sure I would consider ring sizes of 512 or 1024 unreasonable 19:05:10 curious what the existing verification time is for the same region on those things. 19:05:13 Increasing verification time over mlsag/clsag feels like a step back 19:05:24 This would depend on verification time with typical current hardware so it is about absolutes 19:05:56 the physical CPU for those machines is 19:05:57 gingeropolous: my operation-count estimates for MLSAG-11 put it at ~29 hours 19:05:58 model name : AMD Opteron(tm) Processor 6172 19:06:06 We must keep in mind that the goalposts are moving as we talk 19:06:54 the best way would be to time it during an actual sync, once you hit the starting block for the range 19:07:03 My goalposts are the same. Increase ring size without compromising on scaling 19:07:12 but I used op-counts in an attempt to be a bit more consistent with the multiexp-based next-gen numbers 19:07:12 and your running them virtualized, dunno how thats ultimately effecting things 19:08:07 The multiexp numbers were quite consistent 19:08:12 well if thats the goalpost, 29 hours of MLSAG-11 is in the same ballpark as triptych-multi-512 19:08:22 and all next-gen values used the same op count data 19:10:02 u think the whole dataset is in RAM for those runs sarang ? 19:10:22 ? that's not how I got the numbers 19:10:29 my bad 19:10:41 The simulator extracts the I/O data and scales the operation-count data accordingly 19:10:55 so the only time that the hardware matters is when doing baseline op-count data 19:11:03 AMD Opteron(tm) Processor 6172 That is 10 years old https://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors#Opteron_6100-series_%22Magny-Cours%22_(45_nm) 19:11:12 it doesn't run the cryptographic operations on the data directly 19:11:38 ah 19:11:51 Florian's talk is starting now @ SBC20 19:12:58 If anyone wants numbers for different hardware, let me know and I'll explain how to get the right baseline numbers 19:13:10 it's not too bad if you know how to build the codebase 19:17:39 Ahhh subaddress adoption may be a lot higher! Additional pub keys are not added in some cases, which are actually by far the most common cases 19:17:39 I forgot to ask about any particular action items on anyone's list, if they care to share them 19:18:30 Namely, when one output is to a subaddress, and the other output is change, then no additional keys are added. 19:19:41 Isthmus would you mind getting supposed subaddress adoption among the subsets of 2-out tx and >2-out tx? 19:25:46 This week I'll be working on sarang 's tx proof chapter, and then hopefully(tm) start looking at bulletproofs. Bulletproofs is the last to-do for ztm2 before my final proofread, then a public proofreading period of 2-4 weeks, then publishing on getmonero. 19:29:11 neat 19:29:27 Have you decided at what level you want to present bulletproofs? 19:31:07 I kind of want to do a full run through, but guess we'll see when I get there. To understand it properly I'll end up writing a chapter just for my notes, which can easily be a ztm2 chapter 19:34:15 In principal a reader of ztm could make their own (insecure but functional) ec curve library from the basic modular arithmetic, so it feels wrong to not also make their own bulletproofs from scratch. 19:36:53 Is there a big advantage to not pointing the reader to the BP paper? 19:36:59 It's quite good in its explanation 19:38:03 There are definitely some aspects worth noting specifically, like 1/8th point offsets and batch weighting 19:48:35 Very short issue posted to discuss tx pubkey uniformity: https://github.com/monero-project/research-lab/issues/71 19:50:31 It takes a lot of mental time and energy to reinitialize your brain (or my brain anyway) to a new document. Having bulletproofs as part of the 'conceptual world' of ztm makes it way easier for readers to get started, and then to also relate those concepts to other ztm concepts for a wholistic reading experience. 19:52:19 Is there help I can offer? 19:53:13 I'll let you know when my brain gets there :) 19:53:16 heh ok 19:53:54 Feel free to use my Python test implementation if that's helpful 19:58:52 Oh, my action items are further work on next-gen protocol code/analysis 19:59:04 Some review on vtnerd's 64-bit operation code 19:59:34 and, if suraeNoether has new material for CLSAG security model, working on that as well 20:01:02 Oh: and I have 2 open PRs that could use review 20:01:19 One is a simple one relating to hash domain separators: https://github.com/monero-project/monero/pull/6338 20:01:38 The other is an update to transaction in/out proof structure: https://github.com/monero-project/monero/pull/6329 20:02:20 6329 is still listed WIP, but is ready for review 20:04:59 UkoeHB_: I'll read over the changes for ZtM you listed too, if that's helpful 20:05:35 And will be watching lots of livestreamed talks from Stanford: https://cbr.stanford.edu/sbc20/ 20:06:07 * sarang is done now 20:30:11 UkoeHB_: in the multisig chapter, I think it's important to identify which constructions have corresponding security proofs, and which do not... since it appears you're introducing new constructions which are neither part of the codebase nor part of the preprint 20:31:34 Otherwise, it might be tricky for the reader to clearly identify which parts of ZtM document the actual protocol and common implementation(s), and which are ideas you have that do not correspond in this way 21:04:45 Ok I'll clarify 21:07:52 The most controversial point that comes to mind is reducing the commit-and-reveal expectations, which may be due to my rather superficial understanding of the problem it solves. 21:35:51 sarang: check out reremain on my overleaf doc "MRL-00XY" to see a version of the CLSAG paper i want your thoughts on 21:35:59 sure 21:36:02 it's... down to 13 pages 21:36:04 proofs and all 21:36:08 i feel like it's "too simple" 21:36:10 oreeeeeeally 21:36:10 buuut 21:36:25 we'll see