jeffro256 reported that the Carrot spec and implementation are ready for review. Spec: ; impl: 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 ( 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: jeffro256: impl: 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 →
↑