jeffro256: How are external scanning services (light wallets) supposed to work under Carrot? Is it assumed that internal e-notes don't need to be scanned for because they were constructed by the light wallet itself?

<vtnerd> The lwsf project is likely only going to support balance keys and the backend is going to support balance keys primarily for xmrchat type services

<vtnerd> *support incoming view keys primarily for xmrchat

Do you mean view balance keys? k_vb?

s_vb*

<vtnerd> The backend is going to support both. Xmrchat could theoretically use incoming only, assuming it uses lws as a reporting mechanism only. Up to that team though

Thanks. So in practice, using LWS for balance recovery needs s_vb, which is actually less private than a legacy wallet that can still use k_v.

<jeffro256> Tevador: yeah a wallet either needs to make all their change external , or scan / track internal themselves, or send the LWS s_vb . All have different tradeoffs

<jeffro256> It is technically less private to send s_vb, although not by much compared to today's ring signatures, because one has ~95% chance of guessing outgoing transactions correctly with ring signatures

But a legacy wallet under FCMP has significantly better privacy when sharing k_v than a new wallet sharing s_vb.

<hbs:matrix.org> @jeffro256: This will fade away once FCMP++ is live no?

<syntheticbird> @hbs:matrix.org: no fcmp++ is doomed. PANIC NOW. SELL EVERYTHING

<syntheticbird> (yes)

<vtnerd> The legacy wallet can infer when a spend occurred via external change being received

<vtnerd> Otherwise it's completely blinded, and makes the lws backend problematic

That's true, I forgot about the enote_type specifier. But the LWS server still doesn't know which enote was spent. For new wallets, the LWS server with s_vb knows everything.

<jeffro256> tevador: Maybe. If the LWS can't infer an outgoing transaction based on the amount, then yes. For example, if you always buy coffee for 0.01 XMR every Tuesday so every Tuesday you receive an enote worth 0.01 XMR less than an enote you have received in the past, a LWS might be able to infer outgoing. Wallets can defend against [... too long, see mrelay.p2pool.observer/e/95GBu8AKWlBpU21r ]

<jeffro256> Sharing s_vb is always going to be strictly worse. But significantly worse is up for debate IMO

<jeffro256> If you don't believe that quantum computers will ever be useful for breaking ed25519, or if you don't ever share your public Monero addresses with anyone else, then it would make the most sense to use a legacy wallet under FCMP to guard privacy against the LWS. If your perceived risk of your LWS leaking your info is less than [... too long, see mrelay.p2pool.observer/e/yOySu8AKdEhQV3VW ]

<jeffro256> This is kind of why I like the compromise in this idea: gist.github.com/tevador/d3656a217c0…ment_id=5044400#gistcomment-5044400. Use internal change, but only send k_v to the LWS. The first time you sync your wallet you have to do a full refresh. Optionally, once your wallet client kno [... too long, see mrelay.p2pool.observer/e/u56bu8AKTk5SQUlM ]

<jeffro256> This method achieves better the today privacy against the LWS (since it only knows k_v which isn't useful for scanning outgoing), while also keeping change enotes private from quantum computers who have your public address

Some users might find it infeasible to do a full scan due to bandwidth constraints.

This has been discussed in the Jamtis gists. Having a "more private" filter assist tier might backfire and cause LWS users to start using a higher wallet tier with less privacy overall.

I think we should take this as a lesson learned for Jamtis (the next addressing protocol) and not go overboard with filter assist privacy.