R&D wallet module design and possible refactor

[GlenDC]

Currently the wallet module is one big black box, ok-ish for our standard purposes, but pretty bad as soon as you need something out of the ordinary. On top of that it doesn't help light client developers in building their offline wallet, given nothing is exposed, and thus no logic can be reused.

This strikes as odd to me, given that the concept of a wallet is pretty simple and shouldn't really differ that much whether is the wallet of a full node, a light client or anything in between or else.

• What is a wallet?
• What are the different parts of a wallet?
• ...

All questions to be answered using the docs and our knowledge that might help with this. On top of that it might also be worth to (again) investigate the current wallet standards (think BIP32) and see if can perhaps integrate them in our wallet design, as an alternative option. Existing wallets should still work as they are I would think.

As a first phase it would already be nice if a refactor can flow out of this issue, that gives us a nice wallet pkg, on which the wallet module is built, but also a light client can flow out off.

On top of that it is probably also time that the wallet starts to have its own persistent DB so it doesn't have to sync from scratch each time, reducing the startup time of daemons (plain or encrypted-but-unlocked).

[GlenDC]

The rivine wallet documentation already explains all the prerequisite knowledge: https://github.com/threefoldtech/rivine/blob/master/doc/wallet.md.

If we agree that a wallet is simply a collection of private/public key pairs, than that part is already common to all wallets.

What is also common to all wallets is that they want to be aware of the things linked to their addresses:

• coin outputs
• transactions
• block stake outputs
• blocks (for payouts)?

Of this information it can be also be known how much the wallet has spent, how much assets are currently unspent and which part of it is is liquid. Aggregated it is sometimes referred to as balance.

What can be different is the data source of this information:

• In the case of a full daemon node this would come from a persistent DB, populated by subscribing to the consensus set;
• In the case of a light client it would come by searching for the addresses in the explorer;

This is all simple enough that it could be abstracted away.

⚠️ we'll need to think how we keep this abstraction once we subscribe, it probably means we need to somehow provide our own subscription model for our full daemon internally and specific to the wallet module (to be used only for that module, not the wallet lib logic).

Further what is common is that things can be signed.

Finally there is also the transaction pool (as a wallet concept) to which can e pushed to actually create a transaction.

All in all, it seems that it should be easy enough to abstract most of this away, that it should become quite trivial to share this logic between a light client wallet implementation, full node wallet and custom chain (full node) wallets.

⚠️ We do need to ensure that primitive stuff like the transaction builders can be overwritten as well, without too much hassle, as for example the goldchain requires this for its custody fees.