jeffro256 reported that the Carrot spec and implementation are ready for review. Spec:

GitHub
Fix 2-out sender dox by jeffro256 · Pull Request #16 · jeffro256/carrot
Resolves monero-project/monero#11586. Effectively changes the spec so that legacy key hierarchies use an internal scan where $s_{sr} = k_v$.
Pros:
...
; impl:

GitHub
Build software better, together
GitHub is where people build software. More than 225 million people use GitHub to discover, fork, and contribute to over 800 million projects.
InProofs continue to work for incoming payments; OutProofs work for external outgoing payments. For self-sends, InProofs take a different form (leaking that the enote is internal) and there are no OutProofs. External self-sends in >2-out txs can still have both. The main UX impact is limited to internal enotes. rucknium noted a potential cryptographic audit-trail impact for self-sends and asked whether Carrot view keys still allow a full trail. jeffro256 clarified that without tx-specific secrets (or a new derivation from permanent secrets), outgoing information is lost beyond total amount per tx; giving up the view-balance secret makes the PR 16 change moot. OutProofs can always be made for external enotes (even to oneself). The workaround of external self-sends preserves most current UX. Participants viewed the outcome as reasonable.
rucknium: 3. get_tx_key/check_tx_key doxes sender in 2-out tx (

GitHub
Issues · monero-project/monero
Monero: the secure, private, untraceable cryptocurrency - Issues · monero-project/monero
rucknium: Is jeffro256 here?
rucknium: Anything to discuss on this item for now?
jeffro256: Yes , the spec and the impl are ready for review
jeffro256: I'll drop links rn
jeffro256: Spec:

GitHub
Fix 2-out sender dox by jeffro256 · Pull Request #16 · jeffro256/carrot
Resolves monero-project/monero#11586. Effectively changes the spec so that legacy key hierarchies use an internal scan where $s_{sr} = k_v$.
Pros:
...
jeffro256: impl:

GitHub
carrot_core by jeffro256 · Pull Request #9559 · monero-project/monero
This PR is to implement all Carrot cryptography, as well as enote creation logic and enote scanning logic. This PR should exclude very Monero-speci...
jeffro256: If tevador is here, I'd like to ask whether he sees any incompatibilities of these changes w/ Jamtis
jeffro256: Maybe not, but good review from any parties would be appreiated
jpk68: My bad for the likely uninformed question, but what was the trade-off for the chosen fix, again? Was there an option found to not slow down scanning or remove Janus attack protection?
jeffro256: Good question. InProofs still work for incoming payments. OutProofs still work for external outgoing payments. There is also InProofs possible for selfsends, but they take on a different form. I.e. they leak to the verifier whether the enote is internal.
jpk68: Ah, good to know, thanks. So essentially, the only disadvantage is with self-sends (?)
jeffro256: Yes
jeffro256: Which IDK how often InProofs/Outproofs are used for self-sends, but I'd like to preserve most of the UX if possible even if I never use it
jeffro256: But yeah the main difference is for internal enotes only: no OutProofs, and InProofs look different.
jeffro256:

jeffro256: Although not explicitly recommended by the spec, nothing prevents you from making external enotes to yourself in >2-out txs and having both OutProofs and InProofs like today
rucknium: The possible UX impact is a cryptographic audit trail when you have a self-send somewhere in the trail? Can you still get the full trail with the Carrot view keys?
jeffro256: Define "full trail"
rucknium: I get some XMR. I self-send one or more times. I send it back out to someone.
jeffro256: W/o tx-specific secrets, or a new way to derive tx-specific secrets from your permanent account secrets, then outgoing information is lost, besides total amount per tx
rucknium: Does the lack of outproofs for self-sends affect me?
jeffro256: If you are giving up view-balance secret anyway, then no. The change in PR 16 is moot
jeffro256: You can always make OutProofs for external enotes
jeffro256: Even if they go to yourself
jpk68: As in, an external wallet also controlled by you?
rucknium: Thanks for coming up with the work-around. Seems like a good outcome.
jeffro256: jpk68: Any wallet: current wallet, other wallet held by you, or other entity with unknown key material
jeffro256: Same situation as current. Any "OutProof" you verify doesn't actually mean that the funds left custody of the person making an OutProof
View quoted note →