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 →
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:
...

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.
GitHub
Issues · monero-project/monero
Monero: the secure, private, untraceable cryptocurrency - Issues · monero-project/monero
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:
...
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...

xkcd
Workflow
#monero-research-lab