feat: P2PK key storage and auto-sign on receive#1053
Conversation
|
Should the wallet use the seed to make deterministic secrets instead of randomly generated secret keys (e.g., using BIP32)? |
edcae79 to
acf5421
Compare
Great question — and I think we’re talking about two different classes of secrets:
In this PR, the “secret keys” in question are of the first type, so I kept them random by design. |
acf5421 to
4681ce9
Compare
4681ce9 to
b043747
Compare
c1aedcb to
1c63195
Compare
|
Fixed error conversion and rebased. |
- Resolved conflicts in database.rs by accepting modular structure - Moved SQLite-specific implementation to sqlite.rs - Added P2PK methods to sqlite.rs and postgres.rs - Moved SecretKey and P2pkSigningKey types to types/keys.rs - Removed duplicate SecretKey from types/wallet.rs - Fixed imports to use modular types structure
- Convert SecretKey from uniffi::Record to uniffi::Object for better encapsulation - Implement Drop trait to ensure secure cleanup via zeroize - Wrap secret keys in Arc across FFI boundary for safe sharing - Update WalletDatabase trait to use Arc<SecretKey> and Arc<P2pkSigningKey> - Add zeroize to workspace dependencies - Improve test coverage for secret key conversions and byte handling
|
Should there be a wallet function to create a p2pk payment request that generates and saves the key as a convenience method so users don't have to remember to save it themselves? |
Yes that's why I haven't merged. I don't think user should have to generate a secret key like they do now; should call a fn as you suggest. |
|
superseded by #1466 |
Implements #1029
Followed development guide: formatted, typos, clippy; validated pure tests.