feat(wallet): make wallet single mint and unit #199

Merged
thesimplekid merged 1 commit from refactor_wallet_single_mint_uni into main 2024-06-27 11:20:21 +00:00
thesimplekid commented 2024-06-25 16:20:15 +00:00 (Migrated from github.com)

This changes the wallet to be for a single mint and unit, simplifying the core library logic and allowing it to be more flexible for users. Multiple wallet can be created by the user to enable multi mint and multi unit.

This changes the `wallet` to be for a single mint and unit, simplifying the core library logic and allowing it to be more flexible for users. Multiple `wallet` can be created by the user to enable multi mint and multi unit.
davidcaseria (Migrated from github.com) reviewed 2024-06-26 12:58:36 +00:00
@ -140,3 +78,1 @@
.and_modify(|ps| *ps += proof.proof.amount)
.or_insert(proof.proof.amount);
}
let balance = proofs.iter().map(|p| p.proof.amount).sum::<Amount>();
davidcaseria (Migrated from github.com) commented 2024-06-26 12:58:36 +00:00

Is it safe to re-use the same seed for different mint URLs?

Is it safe to re-use the same seed for different mint URLs?
davidcaseria (Migrated from github.com) reviewed 2024-06-26 13:02:08 +00:00
davidcaseria (Migrated from github.com) left a comment

I didn't do a thorough review, but I am generally supportive of this effort to simplify. Before releasing 0.1, I think we should add a multi-mint wallet struct. That is how my wallet works right now and I imagine that will be a more common use case.

I didn't do a thorough review, but I am generally supportive of this effort to simplify. Before releasing 0.1, I think we should add a multi-mint wallet struct. That is how my wallet works right now and I imagine that will be a more common use case.
thesimplekid (Migrated from github.com) reviewed 2024-06-26 13:10:40 +00:00
@ -140,3 +78,1 @@
.and_modify(|ps| *ps += proof.proof.amount)
.or_insert(proof.proof.amount);
}
let balance = proofs.iter().map(|p| p.proof.amount).sum::<Amount>();
thesimplekid (Migrated from github.com) commented 2024-06-26 13:10:40 +00:00

Yes, wallets shouldn't really care about the mint_url other then how to access the mint. When generating secrets the keyset_id is used so as long as the mints have different keysets different secrets will be generated. Similarly if a mint is exposed on two endpoints the wallet should treat it has the same mint in terms of deriving secrets.

Yes, wallets shouldn't really care about the mint_url other then how to access the mint. When generating secrets the keyset_id is used so as long as the mints have different keysets different secrets will be generated. Similarly if a mint is exposed on two endpoints the wallet should treat it has the same mint in terms of deriving secrets.
thesimplekid commented 2024-06-26 14:13:10 +00:00 (Migrated from github.com)

I didn't do a thorough review, but I am generally supportive of this effort to simplify. Before releasing 0.1, I think we should add a multi-mint wallet struct. That is how my wallet works right now and I imagine that will be a more common use case.

I'll add it today

> I didn't do a thorough review, but I am generally supportive of this effort to simplify. Before releasing 0.1, I think we should add a multi-mint wallet struct. That is how my wallet works right now and I imagine that will be a more common use case. I'll add it today
davidcaseria (Migrated from github.com) reviewed 2024-06-26 19:14:18 +00:00
@ -0,0 +1,299 @@
//! MultiMint Wallet
davidcaseria (Migrated from github.com) commented 2024-06-26 19:14:18 +00:00

I don't think Wallet needs to be wrapped in an Arc since it is already Clone.

I don't think `Wallet` needs to be wrapped in an `Arc` since it is already `Clone`.
davidcaseria (Migrated from github.com) approved these changes 2024-06-26 20:25:41 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cashubtc/cdk!199
No description provided.