You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GUI uses the wallet API, and the wallet API is tightly woven with the wallet2 object (see m_wallet in wallet/api/wallet.cpp).
Proposed plan
Step 1: wallet API
Stop using the wallet2 object directly in the wallet API, and instead use the Seraphis lib, except to construct legacy txs.
Benefits:
Takes a heavy load off reliance on wallet2 to manage state, keys, settings, and scanning.
Establishes a clean path to deprecate wallet2 once we no longer need to construct legacy txs.
Maintains the wallet API's existing functionality that wallet devs currently rely on.
Wallet devs that currently use the wallet API can start using the Seraphis lib sooner rather than later without needing to overhaul their wallets.
Challenges:
The wallet API is tightly woven with the wallet2 object (references m_wallet 193 times).
Will still need a "house" for wallet state and settings.
Will still need to be able to read a wallet2 keys file and wallet cache and migrate it over to a new file structure (related to 1 and 2).
Needs care to avoid turning the wallet API into another wallet2.
Estimated full-time work to complete: 3-6 months.
Step 2: CLI and RPC wallets
Stop using the wallet2 object directly in the CLI and RPC wallets, and instead use the wallet API.
Benefits:
Cuts off major dependencies on wallet2.
Minimizes time and maintenance burden to develop features for all of the GUI/CLI/RPC wallets in the future.
Enables reusing the suite of functional tests for the RPC wallet for the Seraphis lib.
Charts a path for wallets like Feather that also use the wallet2 object directly to use the wallet API exclusively.
Challenges:
Both CLI and RPC wallets are tightly woven with the wallet2 object (CLI references m_wallet 724 times, RPC 368 times).
Will likely need to extend functionality of the wallet API to allow for some of the behavior that the CLI and RPC wallets need.
e.g. the wallet API doesn't support wipeable strings when passing secrets around, which the CLI relies on to keep sensitive key material out of RAM. On this note, the wallet API actually keeps the wallet password in memory too which needs to change as @tobtoht proposed here.
Estimated full-time work to complete: 2 months.
There is a lot of logic in CLI and RPC that the wallet API duplicates, so it should mostly be a matter of replacing high level calls, rather than deep changes.
Note: technically the above 2 steps can be done in parallel, but I figured it would be a cleaner process to prioritize 1 first.
Why keep the wallet API?
Significantly reduces time to develop functional GUI/CLI/RPC wallets that maintain existing functionality.
Makes it significantly easier for wallet devs who currently use the wallet API to migrate to Seraphis.
Gets the Seraphis lib used by devs sooner rather than later.
Goals
Challenges
m_wallet
insimplewallet.cpp
andwallet_rpc_server.cpp
).m_wallet
inwallet/api/wallet.cpp
).Proposed plan
Step 1: wallet API
Stop using the wallet2 object directly in the wallet API, and instead use the Seraphis lib, except to construct legacy txs.
m_wallet
193 times).Step 2: CLI and RPC wallets
Stop using the wallet2 object directly in the CLI and RPC wallets, and instead use the wallet API.
m_wallet
724 times, RPC 368 times).Note: technically the above 2 steps can be done in parallel, but I figured it would be a cleaner process to prioritize 1 first.
Why keep the wallet API?
The text was updated successfully, but these errors were encountered: