As I move ahead with the BTC provider/wallet bounty, it's starting to feel like a "virtual hardware wallet" is doable and desirable in Urbit, although there may be implementation/security considerations that I'm unaware of.
It's turned out to be easier/faster than I anticipated to port BTC transaction building and signing functionality to Urbit; I have pretty much everything working now that is needed to handle standard transactions (i.e. non-multisig/exotic scripts) from/to any of the 3 address types. We can also now derive any address type from xpubs internally.
The win here is that everything except address balance querying and transaction broadcasting can now be done inside your Urbit. This allows for a lot of potential schemes to eventually obfuscate the source of broadcasts and address balance queries, and also makes RPC providers more fungible/less load-bearing.
Given how much can be done internally, it seems logical to implement functionality in Arvo that:
- stores a keypair
- allows calls of the form: (hash, pubkey), where hash is a hash to be signed, and pubkey is the pubkey of the keypair (for lookup in that Arvo module)
- returns the signed hash
One could also, if desired, give the module access to Bitcoin transaction logic, so that it could tell the user the proposed inputs and outputs before consenting to signing. This part may be overkill if the core BTC userspace app is vetted, trusted, and infrequently updated.
This seems similar-ish to Jael, although I don't think that that has a generalized interface of this kind.
Obviously hardware wallets would continue to the be the standard for wallets with larger balances, but for wallets in the < $2K value range, this scheme would be a useability win imo, and also conceptually makes sense. It also would dovetail with proposed ideas to generate wallets from the Azimuth master ticket.
I'm guessing there has been internal thought on this already, so very open to input. I'm probably also missing some security concerns, so let me know what comes to mind.