15:24:45 meeting 1.5hr 15:31:29 before we get into the meeting, which main "Types" have the most support currently? Janus B and Janus E? 15:38:52 my proposal is somewhere between, overview here: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#6-wallet-tiers 15:45:08 tevador: this appears most similar to Janus E right? 15:46:40 this is like Janus B, except tier 1 can't generate subaddresses 15:47:54 yes, closer to Janus B because the extra key for view tags is not worth it 15:49:24 also I've been avoiding the term "subaddress" because all addresses in the new scheme are equal 15:53:04 It might not be optimal, but I think 'subaddress' is an appropriate term. It is necessary to differentiate subaddresses (many per account/wallet) from 'addresses', which are used in other cryptos (one per account/wallet). 15:56:03 just needs a fancy new marketing name like Phantom Addresses 15:57:14 thanks for explaining you two ahead of the meeting. These options are making my brain hurt a bit but it's great to have them all :) 17:00:12 meeting time: https://github.com/monero-project/meta/issues/642 17:00:12 1. greetings 17:00:12 hello 17:00:23 hi 17:00:26 hello! 17:00:30 Hallo 17:00:55 Hi 17:00:58 hello :) 17:04:49 Hello! 17:06:10 hi 17:06:27 Hey everyone 🙂 17:06:31 2. discuss Seraphis address schemes: https://github.com/monero-project/research-lab/issues/92 https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 17:06:31 Does anyone have any comments/questions about this? 17:06:56 My goal today is to narrow down the choice to 1-3 options. 17:07:35 I think many users would appreciate a view key that has full functionality, i.e., shows the balance, plus incoming and outgoing transactions 17:07:48 Thus, arguably we already should reduce the options to the schemes that include this 17:08:01 That is everything except Plain A 17:08:33 OK ty 17:08:37 Doesn't reduce it too much :p 17:08:47 Mitigating the janus attack seems like an easy win if we have to change address scheme anyway 17:09:03 I feel like 5 wallet tiers might be a bit confusing for users, though I see 2 are only intended for merchants so maybe it won't be so bad 17:09:37 speaking to tevador's proposal 17:09:45 The merchant tiers are there mainly to facilitate the phase out of integrated addresses. 17:10:10 interesting -- would you anticipate them falling out of use eventually then? 17:10:23 Why does it say "detect" a Janus attack rather than "thwart" a Janus attack? 17:10:32 Lyza: Would be less confusing then having integrated, sub, and public addresses, plus view key / spend key 17:10:38 Which we have currently 17:11:12 I, personally, am quite in favor of JAMTIS, as it encapsulates both a solid address scheme and a great new address approach. 17:11:15 Rucknium[m]: I think saying "detect Janus outputs" would be more accurate 17:11:37 since you can't prevent people from sending them 17:11:40 The address format necessary to facilitate that seems to be a solid fit an matches basically what I would want from the address schemes anyways. 17:11:49 true but not as simple as the proposals with three tiers so ig I'm just asking about the benefits of the other 2 17:12:03 True yes 17:12:43 tevador: you might want to add a comment to the proposal noting that your scheme does not support integrated addresses (no more encrypted PIDs) 17:13:17 FWIW, the merchant tiers can be easily removed and introduced later if needed, it doesn't affect the core of the protocol 17:13:41 tevador: Oh, that's an important detail 🙂 17:14:02 yeah good to know 17:14:10 Even better, then. 17:14:25 How important is it that the first tier of any system allows for which of the two: a) view tags only, or b) incoming outputs (no amounts) 17:14:57 can you restate the question? 17:15:15 sgp_: As far as I can see, with a) we can improve privacy of light wallets 17:16:02 Which tier 1 would satisfy in JAMTIS, AFAICT. 17:16:17 They do more than improve privacy of light wallets. I personally like tevador 's view tag approach or Janus B because they offer this tier 17:16:29 I don't think I have a super strong opinion of Janus B vs Janus E, but Janus B is more in-line with current expectations 17:16:41 jberman[m]: Can you elaborate on 'more'? 17:16:55 It increases the attractiveness of using tier 1 for [background client-side scanning](https://github.com/monero-project/monero/issues/8082) too, or in running your own light wallet server, such as [monero-lws](https://github.com/vtnerd/monero-lws) or [openmonero](https://github.com/moneroexamples/openmonero), and granting tier 1 permission to that server. A perpetual scanning process running on a device poses a security issue: 17:16:55 the key is hot and available to an attacker. If this key only reveals received outputs and not amounts, then the security properties of perpetually scanning the chain on a device are stronger 17:17:45 sgp_: JAMTIS is in the middle of that, it lets you compute all view tags, and additionally find incoming outputs (no amounts) for just addresses you know about (which may not be super useful in practice). 17:17:53 jberman[m]: This ^ Big step forward for the viability and privacy of lightwallets 17:18:14 Actually, I think even revealing received outputs without amounts might be too strong. JAMTIS Tier 1 only reveals view tags, so there are decoy outputs that don't bwlong to the wallet. 17:18:25 Very, very important we have strong LWS support moving forward as the chain grows in usage. 17:18:32 UkoeHB: got it, I have no idea if this is useful in practice but it could be used by expert users in theory 17:18:52 And yet do so without revealing critical information in the case of a malicious 3rd-party LWS 17:19:08 tevador: this is why I like the view tag scheme too 17:19:48 Revealing outputs means Tier 1 could heuristically detect real spends via change outputs, reducing the effectiveness of the rings that use them as decoys. 17:19:51 Can we ask businesses that currently use Monero what type of features they would want in an address scheme? What can we do to make their lives easier (and therefore make prospective XMR-accepting businesses more likely to accept XMR)? LocalMonero has already weighed in, but we should get more businesses in on the conversation. 17:19:57 sethsimmons: to be clear, revealing the view tag is still bad, it's just less bad :) So idk how much it will actually matter in practice but at least there's some deniability so that's something 17:20:25 sgp_: It's still much better than the current system. 17:20:42 revealing the view tags is the least bad thing that can still be used to speed up wallet sync 17:20:44 Obviously the end-user should be running the LWS, but I like that this protects even those that won't/can't as much as possible. 17:21:03 tevador: since JAMTIS tier 1 can see nominal spend keys for all outputs, any time there is a duplicate they will know that is a real spend key 17:21:13 Is there anyone here who thinks reducing the first tier from view received outputs (no amounts) to view tags is a bad idea? 17:21:29 Rucknium[m]: I will report back for Haveno 17:21:35 sgp_: to do that, addresses need to be 1 key longer 17:21:39 sgp_: First tier of which scheme? 17:22:17 Oh Janus B 17:22:20 UkoeHB: I like this one, this sentence sold me (other tradeoffs aside) 17:22:21 UkoeHB: true. It has some limitations, but introducing a separate key for view tags would have its own issues. 17:22:49 Such as needing 2 public keys per output. 17:22:53 On view tags, I think it would be useful to benchmark performance of this approach (with various T's) to gauge exactly how useful this tier would be (how long would it take to scan the prior year's worth of outputs, how many outputs). I think it would be useful to see how significant this speed-up is to better gauge the proposal. would this speed-up be significant enough that we can be confident people will be very happy with 17:22:53 tier 1 in the long run, even when volume picks up a lot? 17:23:19 in practice with JAMTIS, I would run my own LWS and provide my publicly-known addresses to it for better efficiency, and then eat the slightly lower efficiency for the slightly better privacy (which appears to be a net win) 17:23:36 * better privacy for the other addresses (which appears 17:23:44 jberman[m]: you mean a tier than can only compute view tags, no nominal spend keys? 17:23:58 UkoeHB: yep 17:24:55 That would also be an optiont, but it has downsides: 1 more pubkey in each address and 1 more pubkey in each output. 17:25:02 sgp_: I think the only benefit to filtering on addresses in the LWS would be less bandwidth/storage costs, not computation time. 17:27:50 Btw, a basic JAMTIS address is 139 characters (other schemes with 3 keys would be similar). 17:28:09 That's about 50% longer than current addresses. 17:28:24 suppose 1 more use-case: someone wanted to provide proof of receiving funds, but they didn't want to reveal all the future spending. As I'm reading this, they could do this with JAMTIS with the known receiving addresses, correct? 17:29:08 Are fluffypony or LocalMonero here to give their opinions on JAMTIS? They had a lot to say on the MRL issue 17:29:23 what's a jamtis 17:29:27 tevador: It's not like you can currently type them anyways 17:29:35 fluffypony: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 17:29:51 If I look at all the new possibilities of JAMTIS I really worry about A) all the functions wallets will need to handle everything, and B) the effort of users to learn about everything 17:30:02 *all the new functions 17:31:03 while I'm also concerned about explaining the complexity, it provides better base privacy out of the box so I see it as lower overall risk 17:31:11 rbrunner: but that would be abstracted from users 17:31:25 and most wallets will just create a basic address and be done with it 17:31:30 sgp_: you can prove that an address belongs to you. That's different than proving you received funds. 17:31:42 Can you get away with only handle basic addresses? 17:31:54 rbrunner: on the receipt side, sure 17:32:03 jberman[m]: Thanks, makes sense 17:32:11 and on the sending side MyMonero for eg. uses the CLI code transcoded into JS 17:32:18 or WASM I mean 17:32:26 so it's a different world, we don't need to write stuff from scratch 17:32:46 tevador: hmm, so with JAMTIS are we losing the ability to show addresses receive specific outputs without also revealing balance+spend? If so, I must have misunderstood then 17:33:04 tevador: one thing that we should do on addresses is start them with something, eg. xmr, so that they're immediately visually identifiable - that can just be stripped before processing 17:33:14 ie. eVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxWVgMXVyiw54EbULLQ9FzcC4XcxhbRfCsVW2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB should be xmreVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxWVgMXVyiw54EbULLQ9FzcC4XcxhbRfCsVW2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB 17:33:37 Hmm ... we still don't have all wallets propery support subaddresses, and/or integrated addresses, and now we invent new things by the bucketload, and hope for support. May be pretty optimistic 17:34:03 sgp_: a seraphis receive proof would be pretty much the same as it is currently 17:34:13 rbrunner: this streamlines many of those things though tbh 17:34:15 sgp_: maybe I misunderstood that question, JAMTIS is no different than the current scheme in that regard. 17:34:18 rbrunner: fwiw MyMonero has supported payments to subaddresses for ages, there's just too much UX load on implementing it in the wallet 17:34:43 fluffypony: sure, the base58 version could have a "xmr" prefix 17:34:53 UkoeHB: yes but what is that, something else that needs to be shared out of band in addition to a tier 1 viewing key? 17:35:01 Yes, that's one of my points: How many new screens, input boxes, radio buttons etc. you will need to support all that stuff 17:35:01 tevador: also would we not want the checksum to be something a little more useful / robust, eg. Reed-Solomon? 17:35:30 sgp_: if you just want to prove ownership of 1 output, you only need 1 receive proof (no tier 1 key) 17:35:32 If the new functions are deemed too much to implement, they can be added later. Just keep the header bits and everything can be added later. 17:35:36 rbrunner: As far as I understood, in Seraphis there will only be one type of address basically 17:36:01 rbrunner: right - and my point is that you wouldn't, you'd just have a basic address in 90% of the cases. all the other fancy bits are mostly useful to checkout flows in merchant applications, so they'd be generated by a point of sale app 17:36:06 Well, if I look over the JAMTIS proposal, I see a bewildering number of possible addresses 17:36:36 Yeah, maybe I over-estimate what the "normal" user would have to deal with 17:36:38 fluffypony: I was thinking about different checksums, but base58 is not very compatible with these. I can elaborate later if needed. 17:36:40 UkoeHB: currently, I can provide a view key and people can see all outputs coming into that wallet. With JAMTIS, that is not possible unless you also share outgoing right? 17:37:06 tevador: no need - was just curious 17:37:12 sgp_: a tier 1 + set of addresses will show all outputs incoming to those addresses (no amounts) 17:38:08 UkoeHB: okay that is the best of both worlds, sorry I got confused in the middle there so thank you for clarifying 17:38:11 * if the person with tier 1 learns about your addresses from a third party, it is the same 17:38:53 besides the base58 prefix I really have no further comments, this has my full support 17:38:55 Yes, and Tier 2 can see everything including amounts and spends 17:40:09 "tevador: since JAMTIS tier 1 can..." <- can you expand on this more, when would there be a duplicate here? 17:41:13 jberman[m]: any two outputs owned by the same address will have the same nominal spend key, if scanning with a find-received key 17:42:59 what would the benefit of view tags still be in that case? couldn't you easily determine outputs owned by the same address via nominal spend keys then? 17:43:22 Yes, if they are provided to Tier 1, you can. 17:43:32 tevador , is there a minimum subset of features that a wallet could implement for JAMTIS as the proposal stands now? It's a bit confusing to me what the minimal features would be. 17:43:36 Tier 1 cannot derive spend keys. 17:44:14 Overall, I think tier 1 has a lot of pitfalls to keep in mind, but there aren't any realistic ways around those issues without A) eliminating third-party scanning, B) adding cost to addresses, the chain, and LWS scanning, C) greatly increasing the power of third-party scanning 17:44:29 TheCharlatan: yes, the basic address without metadata (mainnet header byte 0xe0) 17:44:30 Is it correct that a merchant address for the 1.5 wallet tier can see all incoming outputs for the wallet because they can generate addresses independently? That's my understanding 17:45:02 sgp_: no, they can only generate addresses for one account. 17:45:06 > what would the benefit of view tags still be in that case? couldn't you easily determine outputs owned by the same address via nominal spend keys then? 17:45:06 Only if > 1 output are owned by the same address. 17:45:40 tevador: okay, thanks for clarifying 17:46:06 At this point I'm quite sold on the tiers for JAMTIS, really great work here 17:46:35 As UkoeHB said, Tier 1 is a compromise. 17:46:47 tevador , so the content lined out in 7.3 may be omitted? 17:47:23 oh wow, TheCharlatan long time no see 17:48:19 TheCharlatan: yes, but then the signatures don't make much sense because they would not cover the whole payment uri (if amount and description are given separately). 17:48:37 so you can remove 7.3 and 7.4 together 17:49:00 the address becomes: header byte, K1, K2, K3, checksum 17:49:20 ok, got it 17:51:26 I was also looking into other checksum options, but the problem of base58 is that a single character typo may change up to 8 bytes, which doesn't play well with any polynomial based checksums. 17:53:05 can they be adopted to base58? 17:53:09 Math should be similar 17:53:34 nope, you need the base to be a prime power 17:53:56 base 59 might work 17:54:46 as far as I can recollect this one of the reasons bitcoin moved to base 32 (but could be mistaken) 17:55:03 Does it require more data in the output (ie, currently amount and pubkey) ? 17:55:21 Before we end the meeting, is there anyone who has an objection to JAMTIS, or thinks another scheme should be included in the list of choices? 17:55:41 rbrunner: ? 17:55:54 moneromooo: no, except it might need a separate pubkey for each output 17:55:57 Could 8 (recipient authentication/everything related to this) be omitted as well and supported by any address scheme at a future time? As I see it, the most critical component is an additional asymmetric key pair for identity verification; couldn't we theoretically implement a protocol that accomplishes the same goal of identity verification alongside any of the proposed address schemes, at any point in the future? 17:56:09 Only a quite general one, more "gut feeling" like, that this is just too much, basically of everything :) 17:56:37 Falling in love with complexity because of all the possibilities it offers, nerd's dream 17:56:37 I read that as "no, except maybe yes". Can you expand a bit please ? 17:57:06 jberman[m]: as I said, the authentication features could be added later, provided the header byte format is kept. 17:57:35 "Remember the time when an cryptocurrency address was just ... an address, and not everything but the kitchen sink". 17:58:06 rbrunner: there is also 'learning from experience' 17:58:11 tevador: got it 17:58:17 moneromooo: this is related to Janus detection, I think UkoeHB had some option with only one pubkey if it's a 2-out tx with one change output. 17:58:19 But I seems I am quite lonely here with these gut feelings :) 17:58:41 Is also mostly a technical meeting, no wonder 17:58:49 Is there a way that we could make this info digestible for Monero-accepting businesses, so we can reach out to them to get their point of view? 17:59:49 ^ second that, I'd like to hear some feedback on the merchant wallet functions 18:00:11 Or maybe we should have a general feedback survey, like, "What are the biggest pain points in dealing with Monero?" 18:01:03 tevador: moneromooo My goal for the new protocol is 2-out tx have 1 txo pubkey (leveraging the change/dummy output, which is mandatory for 2-outs), and >2-out tx have 1 txo pubkey per output. 18:01:38 How does the common complaint "Can't generate subaddresses without knowing a secret key" translate to JAMTIS? 18:01:53 So it should be the same as now if all outputs go to a subaddress. 18:01:58 right 18:02:10 rbrunner: that's why JAMTIS has Tier 0 18:02:20 Ah, ok 18:03:00 I heard that was a common complaint against using subaddresses 18:03:38 "1 txo pubkey" means one more from the one we have now, right ? 18:03:47 no, it means 1 18:03:53 And this has all the usual "can't correlate" active, i.e. I can't see which Tier 0 addresses are the same wallet? Or may be I confuse things now 18:04:02 And 2 out txes would have... what per output ? 18:04:09 0.5 per output 18:04:19 I see. 18:04:33 So better than now then ? 18:04:46 Just making really sure I got it right :) 18:04:52 rbrunner: Tier 0 is only for merchants, addresses generated by Tier 0 can be linked together off chain. 18:05:08 the txo pubkey is the 'transaction public key' and 'additional tx keys', which are horribly named 18:05:50 ^yes, I also found the naming to be confusing 18:06:57 it's a really nice proposal tevador 18:08:57 rbrunner: all Tier 0 addresses would have two common keys, so all addresses from one merchant account would be linkable 18:09:21 I read the proposal, thanks tevador for your work 18:09:34 I'm absolutely staggered by the amount of information in the proposal 18:09:37 non-merchant account addresses would not be linkable 18:10:46 I will try to incorporate the feedback from this meeting 18:10:56 sgp_: Positively or negatively staggered? 18:11:13 We are past the hour, so I will call the meeting here. It seems there is a general consensus to pursue JAMTIS. Future action items include A) getting feedback from merchants, B) deciding how much of the API to support out-of-the-box. 18:11:26 Thanks for attending everyone 18:11:29 positive, though I need to think about sections 7+8+9 more 18:13:43 Tier 0 addresses are linkable in similar ways to integrated addresses, but don't suffer from their other limitations (mainly inability to batch outputs and having to include the payment ID on chain). 18:15:29 not linkable across accounts though right? 18:15:54 correct 18:16:46 this will take a complicated infographic to explain but I will try :) 18:32:29 Thanks, everyone 19:06:55 man oh man, so we gotta roll out jamtis with seraphis b/c seraphis isn't compatible with old-style cryptonote, right? 19:07:50 gonna be quite the release 21:24:48 With seraphis, is there the possibility to fully disclose the details about your wallet? 21:29:17 If yes, I would vote against it. Disclosing optionally the entire details of your wallet because you have asked to might not be a good idea. I know it can improve UX from a point of view, but remember that we should develop something idiot-proof to achieve full privacy for our community. 21:31:04 Anyway nice to see some focus on merchant feedback, it's really important if we want to have Monero accepted anywhere :D