15:56:41 Reminder that today's research meeting is at 17:00 UTC 15:56:43 .time 15:56:43 2020-05-20 - 15:56:43 15:56:47 about one hour from now 16:03:02 Agenda is updated: https://github.com/monero-project/meta/issues/467 16:57:17 We'll get started in just a couple of minutes 17:00:04 OK, let's begin 17:00:04 ! 17:00:07 GREETINGS 17:00:08 hello 17:00:53 hello 17:01:01 hi 17:01:35 * sarang will wait a bit for others to arrive 17:02:06 Hi guys, just eavesdropping here :-D 17:02:14 * Isthmus waves 17:04:07 hello 17:04:27 Let's move to ROUNDTABLE, where anyone is welcome to share research topics of interest 17:04:42 Who wishes to share something? (I saw Isthmus just posted to the agenda issue) 17:05:54 Hi 17:06:16 I suppose that I can share a few items 17:06:25 First, I'll review some Arcturus numbers, some of which were presented last week 17:06:43 Recall that Arcturus is a modification of Triptych that needs only one proof per transaction, instead of one proof per spend 17:06:45 Hi 17:06:51 (making it similar to RCT3's update and Omniring) 17:07:01 I'll link some plots... 17:07:24 Size data for 1 input: https://usercontent.irccloud-cdn.com/file/DYMoX7jy/size-1.png 17:07:36 Size data for 2 inputs: https://usercontent.irccloud-cdn.com/file/7Hw5Wnsv/size-2.png 17:07:50 Size data for 16 inputs: https://usercontent.irccloud-cdn.com/file/QzJ03VBI/size-16.png 17:08:07 You can see the improvement as the number of inputs increases 17:08:35 From last week, I'll re-post the timing data... 17:08:58 Verification timing for 1-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/airMJ4pC/timing-1-2.png 17:09:19 Verification timing for 2-input/2-output transaction: https://usercontent.irccloud-cdn.com/file/iZdBR8xe/timing-2-2.png 17:10:52 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 17:11:31 I'll post that update when I've finished typesetting it and reorganizing the preprint on IACR 17:11:40 (but it's still in progress!) 17:11:53 Any questions for me on this material? 17:12:36 Arcturus seems to blow away the other sig mechs 17:12:45 What's the main drawback(s) of Arcturus compared to other sig mechs? 17:12:56 Seems like a clear win, but maybe there is something I'm missing. 17:13:04 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 17:13:18 Arcturus relies on a nonstandard cryptographic hardness assumption 17:13:58 what are the implications of being nonstandard? needs further proofs? 17:14:01 You can see the full-chain comparative estimates on page 12 of the Arcturus IACR preprint: https://eprint.iacr.org/2020/312.pdf 17:14:28 note that in Figure 3, RCT3 wins, but in Figure 4, it loses 17:14:35 (size vs time) 17:15:12 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 17:15:40 Triptych does not have this limitation, and relies on only standard assumptions 17:16:20 I'm submitting it to conference proceedings in the hope that it will get some quality review 17:16:35 so I want to update the security model prior to that deadline at the end of this month 17:17:07 the win on time is huge 17:17:24 FWIW both Triptych and Arcturus are very similar for verification time 17:17:38 that's because of how generators are batched similarly in both approaches 17:18:01 triptych appears to be a constant factor larger in size 17:18:16 well, nearly. 17:18:29 It requires multiple proofs, and has some extra elements included (e.g. commitment offsets) 17:18:40 Arcturus is a single proof, and does not require any commitment offsets 17:18:53 (it does have proof elements that scale with the number of spends, but does so pretty darn well) 17:19:25 at least all of the size plots are linear, no silly exponential growth 17:20:05 probably an obvious statement but I would choose to optimize time 17:20:25 In that case, Triptych and Arcturus are essentially comparable 17:20:41 with small variations relating to how balances are checked 17:20:56 and these variations disappear at higher ring sizes anyway 17:21:17 and Triptych requires no nonstandard assumptions 17:21:26 Nope 17:21:33 "with small variations relating to how balances are checked" < ah thanks, I was wondering about this 17:21:40 I could probably add the Arcturus-style balance security definition to Triptych as well 17:22:00 Isthmus: balance checks in MLSAG/CLSAG/Triptych are identical... sum the commitment offsets and outputs to zero 17:22:08 In Arcturus it's built in to the proving system directly 17:23:07 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 17:23:12 this is some great stuff. Arcturus still grows in size more slowly than Triptych, 17:23:16 At low ring sizes, they're more comparable and the difference is notable 17:23:25 Yeah 17:23:37 Its per-spend elements scale better 17:24:02 What's nifty is they both use the same underlying Groth-style cryptographic plumbing, but in different ways 17:24:11 (this is the same plumbing that Lelantus uses) 17:24:49 Anyway, I've taken up enough of the roundtable time for one day! 17:24:55 Does anyone else have research they wish to share? 17:25:17 TheCharlatan updated the encrypted unlock time research proposal with sarang's timing data: https://github.com/insight-decentralized-consensus-lab/monero_encrypted_unlock_time 17:25:59 s/Tryptich/Triptych/ 17:26:10 (based on feedback at previous MRL meeting, and input from sarang) 17:26:30 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. 17:26:32 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. 17:26:36 I'm glad the 3-CLSAG and 3-Triptych data was useful! 17:26:54 For example, the first image shows the avatar for transactions that are from (or mimic) the core GUI/CLI, which has fingerprint ...0000 17:26:56 https://usercontent.irccloud-cdn.com/file/vjCauM0y/image.png 17:27:06 The secnd image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010) 17:27:10 the bottom image shows the avatar for transactions that included a juvenile ring member and thus produce a different signature (...0010) 17:27:14 https://usercontent.irccloud-cdn.com/file/Lzt9vfyJ/image.png 17:27:35 (note that this particular issue was fixed in recent update) 17:28:09 Anyways, still very early toy/prototype 17:28:28 So the hash inputs are individually set bits? 1 = "basically the same as standard", 0 = "different enough" 17:28:59 and this is done over different characteristics to build the input string? 17:29:38 Yep 17:30:06 * Isthmus pauses to clarify wording 17:30:23 0 = "the core wallet would construct a transaction in this way" 17:30:30 1 = "the core wallet would never construct a transaction this way" 17:30:42 e.g. the juvenile spend example 17:31:02 got it 17:32:44 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..." 17:33:11 What's a juvenile ring member, 17:33:12 ? 17:33:55 Any transaction that includes a ring that includes a ring member less than 10 blocks old (based on the time it was mined) 17:33:56 https://github.com/monero-project/monero/issues/5712 17:34:16 ah 17:34:26 The core wallet has observed a 10-block lock time, so they must have been generated by custom software 17:34:32 But now it's a consensus rule 17:35:22 To what extent does the visual fingerprint identify the extent to which the transaction is nonstandard? 17:35:44 e.g. can you look at a fingerprint and see "oof, this transaction is _very_ nonstandard!" 17:36:02 (obviously the Hamming weight of the input will tell you this by inspection) 17:36:42 No, since the visual hash function is appropriately unstable 17:37:38 You could look at the fingerprint string itself to see how different, since more 1s = more different 17:37:49 That's what I mean by the Hamming weight 17:38:08 aaaactually if the hamming weigh was used to select the colorscale...... 17:38:21 Then it could be intuitively accomplished 17:38:25 if colorscale(0) is greenish 17:38:28 At that point, what's the usefulness of the fingerprint shape? 17:38:36 going all the way back to the unlock time proposal, I still think the tradeoffs aren't worth it 17:39:09 Because 0010 and 0001 are different 17:39:26 True 17:39:35 So it really only tells you if the actual strings are different 17:39:48 I guess I figured the "more useful" component in general might be the Hamming weight 17:39:55 since one goal is to minimize it 17:39:59 It depends if 'degree of wrongness' is important 17:40:06 I agree sgp_ it feels quite expensive 17:40:24 From my perspective, 0010, 0001, and 0011 are 3 distinct signatures 17:40:36 Even though 0011 is more worse :- P 17:43:13 ArticMine: how is it going with your penalty/fee proposal? 17:45:12 While we wait to see if ArticMine is around, were there any other questions on the material Isthmus presented? 17:45:35 none about the presented material, but I eventually have a question for Isthmus about the coinbase vs non-coinbase spend distributions 17:45:52 Hey @sgp_ what do you have in mind? :- ) 17:45:57 I would also be interested to see that for BTC 17:46:02 heelo Isthmus :) 17:46:14 s/heelo/hello 17:46:14 sgp_ meant to say: hello Isthmus :) 17:46:42 I really want to segregate coinbase outputs form other outputs 17:47:13 to do this, I ideally would like to know what the independent spend distributions are for these two categories of outputs 17:47:24 my suspicion is that coinbase outputs are spent faster on average 17:48:28 We can ascertain this by subtracting the reference distribution from the observed ensemble distribution 17:48:32 And split it by type: 17:48:59 distribution(coinbase inclusion in rings) - reference_distribution 17:49:02 distribution(non-coinbase inclusion in rings) - reference_distribution 17:49:26 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) 17:49:28 Having a direct measurement from something like BTC would be very helpful regardless 17:49:52 ideally to follow the Miller et al. idea of comparing known-estimated Monero behavior to BTC 17:50:24 I'll see about extracting true BTC spend times from Google's BigQuery dataset 17:50:32 That'd be great 17:50:32 There's probably some way to do it in a clever SQL one-liner 17:50:41 But I can do it in 20 lines! 17:50:42 :- P 17:50:55 Separately, it would also be interesting to see how/if overall BTC spend times have changed since Miller et al.'s paper 17:51:07 They used two different large groups of blocks 17:51:08 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 17:51:32 "if the results show that the distributions are different, then that's even more reason to segregate" << this 17:52:01 note I still support coinbase-only rings even if the distributions are exactly the same :p 17:52:17 In the interest of time, were there any other topics to be brought up before moving on? 17:52:38 that's all fro me, thanks Isthmus 17:52:41 *from 17:53:03 Any new comments on the Tx Supplement proposal? 17:54:10 Restructuring for uniformity and Janus mitigation seems useful and reasonable to me, FWIW 17:54:17 agreed 17:54:20 costs are small 17:54:31 Especially with the savings from CLSAG 17:54:56 I'm in favor. Uniformity is the whole point. 17:55:20 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 17:55:39 I should have this in the next two weeks 17:55:49 Cool thanks :) 17:56:53 OK, with the last few minutes of the hour, let's get to ACTION ITEMS 17:57:10 I would like to finish the update of the Arcturus security model, to get the updated preprint submitted for review 17:57:25 And will be discussing the CLSAG audit with Teserakt 17:57:34 Anyone else? 17:57:45 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? 17:59:11 Well, certain tags would be required by consensus... can you refresh us on your definitions here? 17:59:47 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. 18:00:20 Only encrypted payment IDs would remain in the extra field after the update 18:00:30 And miner extra nonce 18:00:48 So not much consensus left 18:01:02 Oh, TLV for _extra only_... of course 18:01:03 nvm 18:01:20 I was thinking about fields in general, which is not correct 18:02:52 With a restricted miner nonce we (probably I) could release a miner nonce guideline for pool implementer to reference 18:03:37 If it's easy enough then hopefully most pools and solominers would be indistinguishable on-chain 18:04:02 OK, any other questions, topics, or action items before we adjourn? 18:04:11 I posted a proposal for the atomic swap, feedback are welcome 18:04:19 Link? 18:04:35 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/145 18:04:38 thanks 18:05:43 All right, let's adjourn in the interest of time (and for log posting purposes). Thanks to everyone for attending! 18:05:50 And, if there is some kind of community expectation for pools to be uniform then there may be enough pressure for it to materialize.. 18:05:53 Logs will be posted shortly to the agenda issue, as usual 18:06:00 Thanks sarang 18:06:08 Discussions can of course continue! 18:06:19 Thanks 18:06:19 I just need a cutoff for posting them 18:12:22 Thinking about pools publishing blocks.. Any miner can parse their pool's blobs and recognize when a block from their pool is mined into the chain, since the miner tx will be the same. This means pools would have to generate unique timestamps and miner tx pub keys for each worker, in addition to unique miner nonces (perhaps making the miner nonce redundant). 18:13:28 i.e. if pools were to stop publishing blocks in order to remove most/all fingerprinting from coin base 18:15:49 It's doable but a bit burdensome for implementers