Jamtis changes

[jeffro256]

• nominal address tag protection for LWs (extra address key)
• flexible view tags
• churning and pocketchange protection for LWs (auxiliary enote records)

PR implementing changes is here: UkoeHB/monero#26

[UkoeHB]

Started the review, see commits for changes. Stopped when I encountered a math issue.

[jeffro256]

I need to update the Janus attack section, I think I edited locally and forgot to push the changes

Edit: done

[UkoeHB]

Implementation note: a selfsend enote with a primary view tag must be randomly positioned in the list of selfsends.

[UkoeHB]

Summary of changes as I understand them:

• Txs how have two Diffie-Hellman exchanges instead of one. One DH exchange is used for the view tag (filter-assist derivation D^d_fa) and the other is used for enote information recovery (view-received derivation D^d_vr).
  • reason
    • Separating the derivations means D^d_fa does not reveal any information about the enote. Sharing the derivation means the nominal spend key for normal enotes is visible to third-party scanners (with the old k_fr), which reveals when two normal enotes with the same destination address have been received.
  • cost
    • Jamtis addresses must include an extra key for the additional DH exchange (for 4 total keys).
    • Jamtis addresses cannot use address tag hints to filter effectively in the clients of third-party scanners. Clients must now perform one DH exchange for every view tag match. Note that enotes without view tag matches can be cheaply filtered in the client with an auxiliary view tag check before computing the second DH exchange.
• Enotes now have a primary and complementary view tag.
  • reason
    • Clients of a third-party scanner need an additional filter computed from the view-received derivation (D^d_vr) in order to avoid the large expense of checking the onetime address. This is achieved by replacing the address tag hint with a new 'complementary view tag' that is computed from D^d_vr and the input context.
  • cost
    • None, other than the upstream cost of the double-DH exchange.
• Primary and complementary view tags are written to a single fixed-size view tag. The relative bit-share of each is configurable.
  • reason
    • The granularity of primary view tags affects the privacy and efficiency attributes of third-party scanners. More bits in the primary view tag reduces the anonymity set of enotes owned by their clients (fewer enotes will match). Fewer bits increases the bandwidth costs of transmitting primary view tag matches to their clients (more enotes will match). Allowing a variable bit length facilitates flexibility in the face of transaction volume changes, so the tag can be as large as possible without reducing privacy attributes below desired limits.
  • cost
    • Managing the bit-share configuration adds complexity throughout the ecosystem. Wallets need to correctly parse the current configured value, and the network needs to coordinate configuration changes.
• If a tx has multiple selfsends then the primary/complementary view tags will only be used for one selfsend. The others will write an 'auxiliary view tag' to the view tag variable that has a selfsend-specific computation.
  • reason
    • When a third-party scanner detects a view tag match, we don't want other enotes in the tx also owned by the recipient to also have view tag matches. Using auxiliary view tags means users can locally check the other enotes in the tx cheaply if they are selfsends. This technique only supports users splitting/churning their own funds.
  • cost
    • When a third-party scanner detects a view tag match, it must send all enotes in that transaction to the user, instead of only view tag matches. This effectively doubles the number of enotes that must be sent to the user.

[UkoeHB]

Ok, overall I am actually happy with the privacy improvements. This is a clean set of solutions to the targeted problems.

The costs are rather painful: 1 more address key, complexity for the view tag bit fiddling, 2x data on remote-scanner client, way slower to scan on the remote-scanner client (probably 100x).

You should go through the changes I made before I merge this. Also, what name and email address do you want to put in the author section?

[jeffro256]

I really like the modifications you made to it. There was a lot of cleaning to do it seems ;)

I just pushed 2 commits which I think make the upfront description flow a little cleaner, and expand on npbits details in later sections or in footnotes.

Ok, overall I am actually happy with the privacy improvements. This is a clean set of solutions to the targeted problems.

The costs are rather painful: 1 more address key, complexity for the view tag bit fiddling, 2x data on remote-scanner client, way slower to scan on the remote-scanner client (probably 100x).

I'm glad you're happy with the privacy improvements. At the risk of being unmodest, these changes are definitely opinionated, but I really like tradeoffs, and these Jamtis changes will probably be good enough for me to switch to a light wallet as my daily wallet (even though I do value privacy strongly). I agree, the costs are pretty painful, but hopefully the computational performance differences these changes bring will be more forgiving in real-world systems than they are on paper (real-world processors having multiple compute threads and mainly being bottle-necked by network I/O). Another personal opinion, but if there comes a time that a majority of light wallet users can not handle a small fraction of the on-chain enotes, that means that full wallets and nodes loads are likely struggling much worse, and there is scaling work to be done elsewhere.

Thanks for going through all the work to review!

[UkoeHB]

Did some slight cleanup on your last commits.

what name and email address do you want to put in the author section?

[jeffro256]

jeffro256 <[email protected]>. Thanks for the credits!