meeting 1.5hr

before we get into the meeting, which main "Types" have the most support currently? Janus B and Janus E?

my proposal is somewhere between, overview here: gist.github.com/tevador/50160d160d2…cfc6c52ae02eb3d17024#6-wallet-tiers

tevador: this appears most similar to Janus E right?

this is like Janus B, except tier 1 can't generate subaddresses

yes, closer to Janus B because the extra key for view tags is not worth it

also I've been avoiding the term "subaddress" because all addresses in the new scheme are equal

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).

just needs a fancy new marketing name like Phantom Addresses

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 :)

meeting time: monero-project/meta #642

1. greetings

hello

hi

hello!

Hallo

Hi

hello :)

Hello!

hi

Hey everyone 🙂

2. discuss Seraphis address schemes: monero-project/research-lab #92 gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

Does anyone have any comments/questions about this?

My goal today is to narrow down the choice to 1-3 options.

I think many users would appreciate a view key that has full functionality, i.e., shows the balance, plus incoming and outgoing transactions

Thus, arguably we already should reduce the options to the schemes that include this

That is everything except Plain A

OK ty

Doesn't reduce it too much :p

Mitigating the janus attack seems like an easy win if we have to change address scheme anyway

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

speaking to tevador's proposal

The merchant tiers are there mainly to facilitate the phase out of integrated addresses.

interesting -- would you anticipate them falling out of use eventually then?

Why does it say "detect" a Janus attack rather than "thwart" a Janus attack?

Lyza: Would be less confusing then having integrated, sub, and public addresses, plus view key / spend key

Which we have currently

I, personally, am quite in favor of JAMTIS, as it encapsulates both a solid address scheme and a great new address approach.

Rucknium[m]: I think saying "detect Janus outputs" would be more accurate

since you can't prevent people from sending them

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.

<dEBRUYNE> true but not as simple as the proposals with three tiers so ig I'm just asking about the benefits of the other 2

True yes

tevador: you might want to add a comment to the proposal noting that your scheme does not support integrated addresses (no more encrypted PIDs)

FWIW, the merchant tiers can be easily removed and introduced later if needed, it doesn't affect the core of the protocol

tevador: Oh, that's an important detail 🙂

yeah good to know

Even better, then.

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)

can you restate the question?

sgp_: As far as I can see, with a) we can improve privacy of light wallets

Which tier 1 would satisfy in JAMTIS, AFAICT.

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

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

jberman[m]: Can you elaborate on 'more'?

It increases the attractiveness of using tier 1 for [background client-side scanning](monero-project/monero #8082) too, or in running your own light wallet server, such as [monero-lws](github.com/vtnerd/monero-lws) or [openmonero](github.com/moneroexamples/openmonero), and granting tier 1 permission to that server. A perpetual scanning process running on a device poses a security issue:

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

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).

jberman[m]: This ^ Big step forward for the viability and privacy of lightwallets

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.

Very, very important we have strong LWS support moving forward as the chain grows in usage.

UkoeHB: got it, I have no idea if this is useful in practice but it could be used by expert users in theory

And yet do so without revealing critical information in the case of a malicious 3rd-party LWS

tevador: this is why I like the view tag scheme too

Revealing outputs means Tier 1 could heuristically detect real spends via change outputs, reducing the effectiveness of the rings that use them as decoys.

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.

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

sgp_: It's still much better than the current system.

revealing the view tags is the least bad thing that can still be used to speed up wallet sync

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.

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

Is there anyone here who thinks reducing the first tier from view received outputs (no amounts) to view tags is a bad idea?

Rucknium[m]: I will report back for Haveno

sgp_: to do that, addresses need to be 1 key longer

sgp_: First tier of which scheme?

Oh Janus B

UkoeHB: I like this one, this sentence sold me (other tradeoffs aside)

UkoeHB: true. It has some limitations, but introducing a separate key for view tags would have its own issues.

Such as needing 2 public keys per output.

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

tier 1 in the long run, even when volume picks up a lot?

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)

* better privacy for the other addresses (which appears

jberman[m]: you mean a tier than can only compute view tags, no nominal spend keys?

UkoeHB: yep

That would also be an optiont, but it has downsides: 1 more pubkey in each address and 1 more pubkey in each output.

sgp_: I think the only benefit to filtering on addresses in the LWS would be less bandwidth/storage costs, not computation time.

Btw, a basic JAMTIS address is 139 characters (other schemes with 3 keys would be similar).

That's about 50% longer than current addresses.

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?

Are fluffypony or LocalMonero here to give their opinions on JAMTIS? They had a lot to say on the MRL issue

what's a jamtis

tevador: It's not like you can currently type them anyways

fluffypony: gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

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

*all the new functions

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

rbrunner: but that would be abstracted from users

and most wallets will just create a basic address and be done with it

sgp_: you can prove that an address belongs to you. That's different than proving you received funds.

Can you get away with only handle basic addresses?

rbrunner: on the receipt side, sure

jberman[m]: Thanks, makes sense

and on the sending side MyMonero for eg. uses the CLI code transcoded into JS

or WASM I mean

so it's a different world, we don't need to write stuff from scratch

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

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

ie. eVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxWVgMXVyiw54EbULLQ9FzcC4XcxhbRfCsVW2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB should be xmreVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxWVgMXVyiw54EbULLQ9FzcC4XcxhbRfCsVW2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB

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

sgp_: a seraphis receive proof would be pretty much the same as it is currently

rbrunner: this streamlines many of those things though tbh

sgp_: maybe I misunderstood that question, JAMTIS is no different than the current scheme in that regard.

rbrunner: fwiw MyMonero has supported payments to subaddresses for ages, there's just too much UX load on implementing it in the wallet

fluffypony: sure, the base58 version could have a "xmr" prefix

UkoeHB: yes but what is that, something else that needs to be shared out of band in addition to a tier 1 viewing key?

Yes, that's one of my points: How many new screens, input boxes, radio buttons etc. you will need to support all that stuff

tevador: also would we not want the checksum to be something a little more useful / robust, eg. Reed-Solomon?

sgp_: if you just want to prove ownership of 1 output, you only need 1 receive proof (no tier 1 key)

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.

rbrunner: As far as I understood, in Seraphis there will only be one type of address basically

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

Well, if I look over the JAMTIS proposal, I see a bewildering number of possible addresses

Yeah, maybe I over-estimate what the "normal" user would have to deal with

fluffypony: I was thinking about different checksums, but base58 is not very compatible with these. I can elaborate later if needed.

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?

tevador: no need - was just curious

sgp_: a tier 1 + set of addresses will show all outputs incoming to those addresses (no amounts)

UkoeHB: okay that is the best of both worlds, sorry I got confused in the middle there so thank you for clarifying

* if the person with tier 1 learns about your addresses from a third party, it is the same

besides the base58 prefix I really have no further comments, this has my full support

Yes, and Tier 2 can see everything including amounts and spends

<UkoeHB> "tevador: since JAMTIS tier 1 can..." <- can you expand on this more, when would there be a duplicate here?

jberman[m]: any two outputs owned by the same address will have the same nominal spend key, if scanning with a find-received key

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?

Yes, if they are provided to Tier 1, you can.

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.

Tier 1 cannot derive spend keys.

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

TheCharlatan: yes, the basic address without metadata (mainnet header byte 0xe0)

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

sgp_: no, they can only generate addresses for one account.

> 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?

Only if > 1 output are owned by the same address.

tevador: okay, thanks for clarifying

At this point I'm quite sold on the tiers for JAMTIS, really great work here

As UkoeHB said, Tier 1 is a compromise.

tevador , so the content lined out in 7.3 may be omitted?

oh wow, TheCharlatan long time no see

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).

so you can remove 7.3 and 7.4 together

the address becomes: header byte, K1, K2, K3, checksum

ok, got it

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.

can they be adopted to base58?

Math should be similar

nope, you need the base to be a prime power

base 59 might work

as far as I can recollect this one of the reasons bitcoin moved to base 32 (but could be mistaken)

Does it require more data in the output (ie, currently amount and pubkey) ?

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?

rbrunner: ?

moneromooo: no, except it might need a separate pubkey for each output

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?

Only a quite general one, more "gut feeling" like, that this is just too much, basically of everything :)

Falling in love with complexity because of all the possibilities it offers, nerd's dream

I read that as "no, except maybe yes". Can you expand a bit please ?

jberman[m]: as I said, the authentication features could be added later, provided the header byte format is kept.

"Remember the time when an cryptocurrency address was just ... an address, and not everything but the kitchen sink".

rbrunner: there is also 'learning from experience'

tevador: got it

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.

But I seems I am quite lonely here with these gut feelings :)

Is also mostly a technical meeting, no wonder

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?

^ second that, I'd like to hear some feedback on the merchant wallet functions

Or maybe we should have a general feedback survey, like, "What are the biggest pain points in dealing with Monero?"

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.

How does the common complaint "Can't generate subaddresses without knowing a secret key" translate to JAMTIS?

So it should be the same as now if all outputs go to a subaddress.

right

rbrunner: that's why JAMTIS has Tier 0

Ah, ok

I heard that was a common complaint against using subaddresses

"1 txo pubkey" means one more from the one we have now, right ?

no, it means 1

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

And 2 out txes would have... what per output ?

0.5 per output

I see.

So better than now then ?

Just making really sure I got it right :)

rbrunner: Tier 0 is only for merchants, addresses generated by Tier 0 can be linked together off chain.

the txo pubkey is the 'transaction public key' and 'additional tx keys', which are horribly named

^yes, I also found the naming to be confusing

it's a really nice proposal tevador

rbrunner: all Tier 0 addresses would have two common keys, so all addresses from one merchant account would be linkable

I read the proposal, thanks tevador for your work

I'm absolutely staggered by the amount of information in the proposal

non-merchant account addresses would not be linkable

I will try to incorporate the feedback from this meeting

sgp_: Positively or negatively staggered?

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.

Thanks for attending everyone

positive, though I need to think about sections 7+8+9 more

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).

not linkable across accounts though right?

correct

this will take a complicated infographic to explain but I will try :)

Thanks, everyone

man oh man, so we gotta roll out jamtis with seraphis b/c seraphis isn't compatible with old-style cryptonote, right?

gonna be quite the release

With seraphis, is there the possibility to fully disclose the details about your wallet?

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.

Anyway nice to see some focus on merchant feedback, it's really important if we want to have Monero accepted anywhere :D