Skip to content

Conversation

@jeffro256
Copy link
Contributor

@jeffro256 jeffro256 commented Jan 13, 2025

This PR tracks of all the Monero-specific code required to integrate Carrot. Depends on #9559

  • cryptonote::transaction storing and loading of Carrot info
  • Fee carving
  • wallet2 scanning integration
  • wallet2 construction integration with FCMP++ signing
  • Payment proofs, reserve proofs, etc
  • Rewrite input selection heuristics for a post-FCMP++ privacy environment
  • Hardware implementation support libraries to rederive the signable transaction hash
  • Hardware implementation support libraries to avoid dishonest-scanner burning bug
  • Detached SAL proofs
  • Detached FCMP proofs
  • Deterministic output pubkey rerandomizations
  • Hybrid address devices
  • Test extra payloads
  • Deterministic FCMP++ output rerandomizations to support some refund address schemes
  • Multisig?

@jeffro256 jeffro256 marked this pull request as draft January 13, 2025 05:22
@jeffro256 jeffro256 force-pushed the carrot_impl branch 4 times, most recently from 1710070 to 84b48bc Compare January 29, 2025 05:01
@jeffro256 jeffro256 force-pushed the carrot_impl branch 3 times, most recently from baf632d to 0c13242 Compare January 31, 2025 06:10
@tobtoht tobtoht added this to the FCMP++ HF milestone Feb 27, 2025
Changes the `operator[]` method so we can get mutable
references to elements even if the span is `const`.
The operator is now also `constexpr`.
This behavior matches `std::span`.

C++ standard reference: https://en.cppreference.com/w/cpp/container/span/operator_at
Fix five issues with wallet_keys_unlocker:
1. It won't decrypt if there are unlockers open simulataneously on multiple `wallet2` instances
2. It won't decrypt if the first unlocker was disabled (i.e. `locked=false`), even with a second non-disabled unlocker
3. If a destructor of an earlier unlocker is triggered before the destructor of a later unlocker, it will re-encrypt too early, while the second unlocker is still in scope
4. We shouldn't attempt to encrypt/decrypt for any background wallets, even if not currently syncing
5. Calling the 3-parameter constructor with `locked=true` after an unlocker already exists will "double-encrypt"  the spend key after its destructor since the local variable is `locked=false` and the field member is `locked=true`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants