02:47:23 https://github.com/monero-project/monero/issues/6456 updated 12:57:01 sarang the question over Hs(128 bits) as a private key is essentially what I was asking Pieter Wuille about here: https://bitcoin.stackexchange.com/questions/72612/bip32-recommends-a-256-bit-seed-why-do-most-bitcoin-wallets-only-use-a-128-bit 12:57:21 when I pushed him to clarify in the comments, he said: "I guess the answer is defense in depth: less than 128 bits of entropy definitely hurts security. Less than 256 bits may hurt. More than 512 bits can't help" 12:57:36 so it's all about the "may" 12:59:53 UkoeHB_ nice idea with the hidden txprivkey 13:00:59 how do you handle >=3 out txs? a dummy txpubkey, and then you use your own hidden txpubkey instead? 13:01:44 it would seem cleaner to go back to the idea of using a symmetric key and no DH for the change output 13:02:20 so change output one-time key = Hs(a||key_image)G+B or something like that 13:09:55 or change output one-time pubkey = Hs(a || lexicographically sorted key_images)G+B so only one mult with G req'd per tx, although that limits you to one change output per tx 13:42:54 oh wait i keep forgetting about view tags. so yeah you could just do Hs(a||key_image)G+B 13:43:45 it sits well with me philosophically that DH is only for establishing keys with strangers, and symmetric keys are for talking to yourself 13:47:00 and i'd argue that what i've just written is much cleaner from an implementation perspective than hidden txpubkeys based on encrypted txprivkeys on other outputs 13:48:05 and it also means there is no janus issue on change outputs 14:21:37 sarang: did you send the response for the alt-coin paper? 14:22:47 i've also kept thinking about the consequences of a compromised shared secret. no funds can be stolen if it is. and if it ever becomes possible to compromise it, then most bitcoin wallets are also compromised because they use seeds with 128 bits of entropy. so i'd vote for 128-bit tx private keys 14:23:51 but it's not a strong vote. it hangs somewhat in the balance 15:00:40 * kenshamir[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/cmwBZorvThtWqlxyuBhacgEh > 15:04:02 I guess it also depends on what the hash function is as well; if it’s quite new then the extra padded security would likely be something I’d add. 15:04:02 ^ Also not an expert in hash functions haha 15:04:04 sgp_: yes 15:11:23 kenshamir interesting, thanks for your thoughts. i must imagine that a lot of people have thought a lot about this, given that bitcoin wallets have 128-bit private keys 15:11:48 it's easy to say "more is better", but there must have serious thought with bitcoin. 15:11:56 must have been* 15:12:57 Yep I agree, if you find out the exact reason, I would be really interested to hear why also 15:14:43 Interesting knaccc 15:15:36 one interesting article (what was about AES256, not EC) is this https://blog.1password.com/guess-why-were-moving-to-256-bit-aes-keys/ where they cite 2 reasons for moving to 256 keys as "NSA insists that TOP SECRET material be encrypted using 256-bit keys" "for defense against quantum computing" 15:16:03 o_0 15:27:41 an argument for 256-bit keys with Monero would be that if quantum computing advancements do start to make 128-bit bitcoin seeds look shaky, then people can easily move their BTC funds to a new 256-bit seed wallet with plenty of warning. but loss of privacy in Monero is forever 15:28:43 I think that monero relies on enough DL math that quantum computers are just catastrophic, at 128 or 256 bits 15:29:01 But someone feel free to correct me if I'm wrong 15:30:19 heh all EC crypto is dead in 10 years. let's disband and enjoy the summer :) 15:52:47 Is there an easy way to scrape all BTC peg-in and peg-out addresses for Liquid? I want to see the histories of coins that people are pegging in 15:56:02 ^ Isthmus etc. 15:56:15 I wonder if it will act like a rebranded mixer 16:08:15 Potentially, what do the pegging transactions look like? If they have a distinguishing characteristics that can be searched for in BigQuery, then it should be pretty easy 16:11:04 And yea, to echo knaccc, you can play the escalating key size game if your only concern is *security*, but that approach is paradigmatically wrong for *privacy* given retroactive deanonymization 16:12:16 FYI UkoeHB_: I have timing numbers for view tags :D 16:12:31 also knaccc ^ 16:27:27 Meeting here at 17:00 UTC 16:27:28 .time 16:27:28 2020-05-27 - 16:27:28 16:27:33 about half an hour from now 16:27:34 good bot 16:50:03 view tags are just so good. wish i'd thought of that. 16:51:54 Wasn't there a similar-in-spirit idea for such a scan speedup a long while ago? I don't really remember 16:52:16 Anyway, I'll share the numbers at the meeting 16:52:38 The only real downside is that sending wallets don't have to include them honestly 16:52:55 so you could trick a recipient into missing the output on a fast scan 16:53:16 But that seems to be a "just want to watch the world burn" kind of thing 16:53:26 can you envision a scenario where that could actually be used to burn anyone? 16:53:46 i guess it's a way of concealing incoming funds from an auditor 16:54:46 Well, presumably an auditor with a view key would do a full scan 16:55:16 So the way the idea of fast scanning is presented would need to be carefully considered 16:56:28 " Wasn't there a similar-in-spirit idea for such a scan speedup a long while ago? I don't really remember" < I had some silly idea for partial stealth address collisions for this purpose a while ago 16:56:36 But it's not something I would seriously suggest implementing 16:57:03 heh i still kinda like the idea of brute-forcing the choice of tx private key until the last 8 bits of the txpubkey are the same as the necessary view tag :) 16:57:11 ^^ 16:58:41 it's not actually that absurd an idea 16:59:13 given how many EC ops the brute force would take in context with all of the other EC ops being done to create a tx or scan the blockchain 16:59:47 Eh, wait until you see the view key speed up numbers 16:59:54 Maybe you'll think "meh, good enough already..." 17:00:29 heh i'm on the edge of my seat :) 17:00:49 OK, it's time for the meeting! 17:00:59 As usual, begin with GREETINGS 17:02:03 GREETINGS 17:02:07 Hi 17:02:18 hello 17:02:42 * sarang will wait a couple of minutes for others 17:03:28 yo 17:04:08 very nice :) 17:04:15 Subtle! 17:04:18 hello 17:04:24 OK, let's move to ROUNDTABLE 17:04:32 I'll start with a few things 17:04:52 A preprint came out from student researchers at CMU on Monero and Zcash tracing: https://eprint.iacr.org/2020/593 17:05:24 It only looked at pre-Sapling Zcash data that was previously examined (independent checking of earlier work is valuable) 17:05:32 but did look at much more recent Monero transactions 17:05:50 The overall conclusions are that protocol improvements have been very useful 17:06:11 I disagree completely with their methodology leading to a conclusion about the effectiveness of the updated output selection algorithm, however 17:06:19 and I think they can't reach any conclusions from that 17:06:43 I put together some notes and sent them to the authors, along with my thanks for their work 17:07:17 They did make their analysis code available on GitHub, so I'm going to see what useful information can be pulled from that as well 17:07:46 Separately from this, I'm working on some non-slanderability definition stuff to port from Omniring's security model to that of Arcturus now 17:08:03 Worked on address verification proof updates with moneromooo 17:08:30 and wrote up some test code for the view tag scanning idea 17:09:18 in what lang? 17:09:19 As described by UkoeHB_ earlier, the idea is to include a small truncated hash of the key derivation for each output, and use this for a "fast scanning" mode that avoids some curve operations 17:09:27 knaccc: timing code in the C++ codebase 17:09:44 It's not an implementation, only for getting timing information 17:10:50 Under the assumption that a view tag is a single byte and only 1 out of every 256 tag checks results in a match, here are the numbers 17:11:33 On a particular test machine, the total scan cost _without_ view tags for those 256 checks is 43.520 ms 17:11:57 The total scan cost _with_ view tags (and a single match in the group) is 32.559 ms 17:12:32 That means the fast scan mode operates in 75% of the time as the standard scan mode, in this example 17:13:36 how many txs in total were you scanning? 17:14:06 This wasn't an actual scan; it was a simulation that performed all the operations for fake outputs generated by the test code 17:14:28 i just mean, what was the ratio of matching outputs to outputs scanned 17:14:30 It built a view tag and output key, and then timed the scanning under various modes 17:14:38 This assumed 1/256 17:14:48 Purely statistical 17:15:19 when you hit that 1 in 256, are you including the cost of the extra scalamultbase to then properly check? 17:15:28 Yes, let me explain a bit 17:15:31 The test has 3 modes 17:15:48 Mode 1. standard scanning, no view tags 17:16:09 Mode 2. view tag, no hit (compute the derivation and view tag, and then abort) 17:16:30 Mode 3. view tag, hit (after the derivation and view tag check, recompute the expected spend pubkey) 17:16:56 So the "no view tags" total assumes 256 Mode 1 operations 17:17:09 The "yes view tags" total assumes 255 Mode 2 operations, and 1 Mode 3 operation 17:17:23 There is the question also of non standard math 17:17:28 ? 17:18:41 knaccc: the test code actually always generates a matching view tag and output key (for sanity checking), but the simulation just uses the modes to fake whether or not a match occurred (there's no difference in timing doing it this way) 17:18:46 your findings roughly match up with the back-of-envelope calc that if you almost always save on a scalarmultbase, and if variable-base scalarmult costs 25 and a fixed-base scalarmult costs 15, then you reduce the scanning cost from 100% to 25/(25+15) = 62.5% 17:18:47 for Arcturus 17:19:20 ArticMine: view tags are entirely separate from Arcturus 17:19:26 sorry 17:19:37 They apply generally to the output key construction process 17:19:48 which is abstracted away from Arcturus anyway 17:21:14 The added risk with view tags is that a sending wallet can generate whatever tag it wants, and the receiver would not detect the output 17:21:31 But FWIW the reverse isn't true... you can't DoS a scan with this method 17:22:12 Bad view tag implementations could also fingerprint if a wallet did something silly like always set it to a fixed value 17:22:37 Of course, compatible recipient wallets wouldn't detect it if they did fast scanning, and this would not look good for the incompatible sending wallet anyway 17:24:21 Here's the timing code: https://github.com/SarangNoether/monero/commit/93172f80b2c25def9aaf40fc30dbee54f92f47a5 17:24:39 (it does pass build checks, but Windows CI is broken) 17:24:59 i wonder where the difference is between the 75% real-world and 62.5% theoretical 17:25:33 i'll read through your code 17:26:29 There is a small cost for each hash computation, and for the few non-scalarmult operations 17:27:00 Yeah, let me know if you notice something that I missed 17:27:07 those are usually neglibible compared to .15ms or .25ms for an EC mult 17:27:12 aye 17:27:58 IIRC the hash stuff is something like 2-3% of the total time 17:28:00 i don't see anywhere in your code actually referencing loop_count 17:28:12 That's taken care of by the test runner 17:28:28 Which uses the individual results for statistics 17:28:31 ah 17:28:46 Each test is set up by a non-timed init() 17:28:51 and then timed for test() 17:29:17 makes perfect sense 17:29:25 If you build yourself, just run `./performance_tests --stats --filter=\*view_tag\*` 17:29:43 the `true`/`false` flags correspond to the bools in the test definition 17:31:23 Oh, the byte conversions would need to be accounted for 17:31:30 They're not huge, but not negligible either 17:31:51 I tend to ignore those during back-of-envelope estimates 17:32:46 Anyway, that's the stuff I wanted to present here 17:32:52 Are there other questions? 17:34:25 code looks good to me 17:34:32 OK, does anyone else wish to present any research of interest? 17:34:34 knaccc: cool 17:35:12 Hmmm, I started wondering about something this morning... 17:35:14 Over the last several years, I’ve had to nix a ton of cool software ideas because repeated 3-output transactions are heuristically linkable, and alternative business models (subscriptions, accounts, etc) have tons of downsides and privacy concessions compared to adding a small service fee to each operation. 17:35:39 Now I’m wondering if this is stifling Monero adoption and integration by preventing the most straightforward and private method for compensating the developers who want to contribute new stuff to the ecosystem. 17:35:44 If we want Monero to be used for more than point-to-point transactions, without putting the first adopters at statistical risk, there may be some pros to a 3-output minimum: recipient + change + optional service fee. 17:35:48 Of course, for many transactions the third output will be an empty dummy. (Or people could get creative and split the return across 2 change addresses for latter flexibility, etc) 17:35:53 Ah, increasing the enforced minimum to 3? 17:35:54 It might make sense to bundle this in with bigger rings, since the ratio of (# outputs) / (# ring signatures) per unit time shouldn’t get too large (since outputs that haven’t ever shown up in a ring signature yet have a known spend state [unspent], and inforrms [with provable certainty] the sender that funds weren’t subsequently moved). 17:36:01 @sarang yep 17:36:18 Splitting change means more likely to pull in multiple change outputs in later transactions 17:36:26 which is bad for linking 17:36:41 Downside is chain bloat 17:36:43 Yeah, that's why I've always advocated against people splitting up within their wallet 17:37:11 What is the additional size per tx? 17:37:45 0.22 kB 17:37:50 I think 17:38:02 oh wait 17:38:06 that seems too big 17:38:12 That number isn't right 17:38:13 hold on a sec 17:38:17 If we go to 4? 17:38:25 ArticMine: why 4? 17:39:14 * binaryFate taking chair at the back of the room 17:39:28 Is there not efficiency bullet proofs? 17:40:02 with 4 vs 3 outputs that had to be padded 17:40:16 BP padding doesn't imply extra outputs 17:40:23 Now I'm getting pulled into a side adventure on xmrchain that I can't find any 1/3/e txns but there are lots of 1/3/s (trying to figure out what that means) 17:40:27 it's merely an algebra thing 17:41:30 ArticMine: it would mean that the corresponding bulletproof is a bit bigger for standard transactions 17:41:39 if that's what you meant? 17:41:43 Yes 17:42:08 Ah, a 3-out BP (padded to 4) is 64 bytes larger than a 2-out BP 17:42:17 (a 4-out BP is the same size as a 3-out BP) 17:42:28 That is y point 17:42:44 my 17:42:48 got it 17:43:00 Yes, you are correct that this would increase the typical range proof size 17:43:51 Yep, it makes Monero usable for more applications and businesses, but does increase the transaction size 17:44:15 Hm, little easter egg: 17:44:34 There are essentially no 1-in-3-out txns with encrypted PIDs 17:44:51 There are a few 1-in-3-out transactions with no PID at all 17:45:05 And a few 1-in-3-out with some unusual tag in xmrchain, not sure what's in tx_extra 17:45:14 * Isthmus is referring to data from the last week 17:45:33 I guess that would make sense considering any PID tx is probably from user to exchange/service, so would likely just be one in two out 17:46:10 Ugh, stands out as non-standard software 17:46:29 I feel like we sometimes make things worse when we add a feature "to all transactions" in the wallet, but not the protocol :- ( 17:46:37 aye 17:47:11 So is there additional bloat over the 64 bytes? 17:47:39 The new output has a pubkey, a commitment, an encrypted amount... 17:47:49 those three are 72 bytes total 17:47:59 and 4 17:48:02 73 bytes if you add a view tag 17:48:15 add another pubkey, commitment, amount, view tag for each output you want 17:48:57 so 82 vs 73 bytes for 4 over 3 17:49:22 No 17:49:54 In addition to a possible marginal range proof increase, each additional output requires 73 more bytes for pubkey, commitment, hidden amount, [optional view tag] 17:50:34 The marginal range proof increase from 2 -> {3 or 4} is another 64 bytes 17:50:55 So for 3 it is 137 bytes 17:51:10 sounds about right 17:51:24 This also implies increased scanning time (reduced by view tags) 17:51:52 and for 4 210 bytes 17:52:09 and additional scanning time 17:52:17 Yes 17:52:38 Anyway, in the interest of time, were there other topics that needed to be brought up? 17:52:46 (We can always continue discussions afterward) 17:52:56 btw i'd be interested to know some examples of great use-cases for 3-out txs 17:53:04 either now or after 17:53:27 Service fees are a big one 17:53:51 One output goes to the recipient, one to change, one to service provider 17:53:53 VAT / GST? 17:54:15 sarang can you be more specific about the service? just one example of something that could be common? 17:54:29 ArticMine you're suggesting paying VAT direct to the gov as part of a tx? 17:54:48 knaccc: maybe you're using some kind of hosted wallet service 17:55:12 Or maybe your wallet software has an option to donate a small amount to charity with each txn 17:55:21 oh right, fine yes, gotcha. 17:55:51 OK, let's finish up with ACTION ITEMS if there aren't any other topics to bring up 17:56:13 If/when Windows CI gets fixed up, I'll rebase some new work for PR/review 17:56:24 and get Triptych and Arcturus sent off to PoPETs 17:56:53 and hopefully be able to reproduce some of the results from that tracing preprint 17:56:55 Micropayments in every tx is a great way to punch monero into the ground. We don't want to have huge amounts of dust outputs, they take up the same resources as "normal" outputs. 17:57:12 moneromooo: that's what I meant by chain bloat and scan increases 17:58:09 service-fee is essential for multisig arbitration insurance fee probably 17:58:38 but I see a slippery slope 17:58:45 eventually i think the default kind of payment tx should be multisig w/arbitration insurance fee attached 17:59:16 and multisig won't be a different type of wallet, it'll be something created on-the-fly on each payment tx 18:01:08 OK, I suppose we can formally adjourn (so I can post logs), but discussion can of course continue 18:01:13 Thanks to everyone for attending! 18:01:33 ^^ 18:41:57 knaccc: https://usercontent.irccloud-cdn.com/file/AqclvwTR/view-tags.png 18:42:25 This is a plot of the average scan time per output as a function of tag size (assuming large numbers of outputs scanned) 18:43:13 ^ UkoeHB_ 18:43:41 Oh, the x-units are bytes (not bits) 18:47:03 For smaller tag sizes (note the units): https://usercontent.irccloud-cdn.com/file/tPqYCY1S/view-tags.png 18:51:47 Even a very small tag (like 8 bits) gives essentially optimal results 19:33:14 makes perfect sense 19:33:40 it'd be really interesting to know how view tags affect overall wallet scan times 19:33:53 since there will be overhead in other areas that aren't captured in your test 19:35:47 I was surprised how quickly the average time drops 19:36:14 I figured it would take more than just a few bits to see so much of the total possible improvement 19:41:31 why? 19:42:01 No particular reason; just a poor initial guess, I suppose 19:42:18 it's like shaving seconds off the distance you park your car from your front door after a long journey 19:43:21 heh you're a genius mathematician, i'm guessing you were just distracted at the time :) 19:43:52 I'm no genius 19:43:53 ! 19:45:14 So as an example 19:45:21 yeah tell it to the white papers you demolish. 19:45:21 Say we have 6 million view tags 19:45:59 reducing from 8 bits to 4 bits is only 3 MB 19:46:59 so such changes are pretty trivial 19:47:28 yeah it's an awesome realization 19:48:05 At any rate, it tells us that anything over a byte is absolute overkill 19:48:23 And anything under a byte saves you basically nothing in terms of long-term size 19:48:47 it just be child's play to you to have known the savings would have a logarthimic dropoff 19:49:17 Well, the constants are what really tell you where the benefits become only marginal 19:49:37 It's nice to have data to give real numbers for it 19:49:42 yeah 19:49:52 and those constants depend entirely on the relative timing between operations 19:50:16 But hey, that's what performance tests are for 19:51:09 one perf test we never did when we discovered multbase was .15 and multvarbase was .25 was what the frombytesvartime is 19:51:23 that might be the reason for the discrepancy between 62.5% and 75% 19:51:27 Relying on scaling estimates only gets you so far! 19:51:27 Relying on scaling estimates only gets you so far! 19:51:36 Yeah, byte conversions are easy to miss 19:52:10 Especially when looking at things like large-anon-set tx protocols where you need to do a lot of them 19:52:33 Fortunately a fair number of recent speedups come from removing unnecessary conversions 20:14:50 Increasing number of outputs also implies more Janus bytes, currently 32 per output if implemented 20:18:48 yep 20:19:18 I was hoping for around 50% speed up lol, but this is why real analysis is great. Thanks sarang :) 20:19:38 Added the plot to the GitHub issue(s) as well 20:22:19 I'm a bit hesitant to start enforcing behaviors that aren't already ubiquitous. We enforced 2-out tx since 1-outs were super rare. We enforce 10-block lock time since sub-10 was super rare. Starting to enforce 3-out or 4-out in the name of features that don't even exist yet, and whose prevalence we can't evaluate, seems risky. 20:23:25 Well, in this case it's not so much existing ubiquity as a hesitance for responsible services to start doing this because of the obvious uniformity challenges 20:23:54 I'm also not a fan of this, given the cost 20:25:28 Btw knaccc I agree with you about multisig arbitration fees. That seems the most reliable mechanism to power an escrow service, with minimized conflict of interest. 20:26:21 the only problem with escrow is that the escrow services will probably rely on qualitative reputation 20:26:23 The accumulation of bloat is unfortunate but I don't see a good alternative atm 20:26:26 and so lead to centralization 20:27:44 That isn't really a problem for me since as long as they are providing a quality service then customers aren't affected. And competition is fairly trivial 20:28:21 Plus if designed well then an escrow service won't learn much about transactions being made, other than ones they arbitrate 20:28:49 i'm thinking more along the lines of a centralized service that needs to inspect evidence of shipping/etc 20:29:06 one big player with access to sensitive information 20:29:32 yeah it's the arbitrated cases i'd worry about centralization for 20:30:44 and what a great way to unmask a vendor. compromise the arbitrator, cause the delivery to fail, vendor provides privacy-sensitive info to the arbitraror 20:30:55 arbitrator* 20:30:57 how are atomic-swap dexes handling arbitration (is there any)? 20:31:22 the point of real atomic-swap is that no arbitrator is required 20:31:53 The "atomic" part, eh? :D 20:31:59 Yeah I think using escrow in the first place implies such risks. Can't really involve a third party without.. involving them :p 20:32:31 right, seems the best solution 20:32:34 :) 20:34:50 atomic-swaps seem the best solution* for exchanges still requiring arbitration, sounds like a hard problem to solve 20:37:23 maybe something like Bisq using an internal currency to deal with arbitration, or some other way to break the links between addresses involved in trades 20:38:26 how realistic is it for something like this to come https://github.com/monero-project/monero-gui/pull/2925 20:39:53 knaccc re: change outputs and >2-out tx. Since we'd already be including tx pub keys for each output it seems straightforward to treat change outs like normal outs. In the first place 2-out tx would be a 'special case' with a special logic branch. Trying to also have change outs in >2-out tx be special invites more logic branches imo. 20:40:45 sunnuc[m]: maybe try #monero-gui channel 20:41:06 ty 20:41:09 i was weighing the special branches for a symmetric shared secret with the special branches of alternate shared secrets based on encrypted txprivkeys for other outputs 20:41:17 or for that output 20:44:13 I think it's a lot easier to identify and keep track of change outs in 2-out tx since you just say 'if 2-out, generate and store the hidden tx pub key'. And the rest of the code base remains unchanged. 20:44:53 Or actually, I'm not really sure what wallets store.. 21:29:17 Ah I believe 2-out tx may get a bigger reduction in scan times from view tags, since they only (in practice) have 1 tx pub key so you normally only compute `generate_key_derivation()` once, then the `if (is_owned)` stuff twice for each output. If current reduction is to 75%, then 75/(100+25) = 60%. Tx with >2 outputs are only 5% of current tx, so aren't too meaningful for this granularity of analysis. 21:34:59 Hooray, got the tracing preprint's code to run 21:35:05 Now to wait for... a long time 21:35:23 Of course, as Monero changes and grows tx with >2-outs may begin to dominate, so it's good to keep that scenario in mind 21:35:36 It sounded like their code might be pretty useful 21:36:02 It's just very time-consuming for it to pull all the chain data into formats it likes 21:36:30 Fortunately, I can fake-parallelize parts of it by running multiple instances on different block ranges 21:37:06 What I really want is to get specific information on tracing they identified 21:37:20 Their datasets use git lfs, but github complained they used up their data quota 21:37:26 My guess is they were referring to pre-ringct output spends 21:37:31 and FWIW it's probably best to run the data myself as a separate check 21:37:40 UkoeHB_: that is also my guess, but it'll be nice to verify 21:40:00 To test the spend distribution they should have generated a fake database where each ring is selected from the gamma with no real spends, then quantized the two db (real and fake) and subtracted them. Oh well 21:40:39 oh well indeed 21:40:59 I did point out that flaw in their analysis in my email to them, should they choose to revise 21:41:36 the semester is already over, so maybe they have moved on 21:42:03 Could be; but hopefully the information is useful should they do similar research in the future 21:43:40 I was disappointed they didn't have tooling to handle Zcash Sapling transactions, which would have been fascinating to see results on