Update Friday May 11th, 2018
It’s all about the wallet for the time being, beginning with a large refactoring
I spent quite some time this week thinking of potential designs for how the keychain, and transaction libraries should look and interact, only to throw it all out as it was most probably adding complexity without solving any particular issue. I tend to think that imposing a design on something like this up-front usually leads to unnecessary complexity as you try to impose tiers and add generic this and that or the other to anticipate future needs that you can’t quite put your finger on. I generally prefer to code to what you know now, and then refactor, refactor, refactor, letting the design take shape as more needs come to light.
So that being said, although we still don’t have a particular design for how the final keychain/transaction lib and wallet should look and interact, there are plenty of aspects in the current implementation that obviously need refactoring and cleaning up. To start bashing it into shape, I’m tacking the larger and more obvious issues, and in doing so getting a much better sense of what the final structure should be.
In the short term, I think the goals are:
- Forge a clear delineation between the keychain, transaction building, and the wallet implementation. The Keychain and transaction building can have an awareness of one another, while neither should know a thing about the details of the wallet implementation.
- Ensure all of the functionality is in the correct tier
This week’s large refactoring PR was the first step, and moved transaction building, aggsig functionality, and proof building out from the Keychain and core modules and put them into a new libwallet mod within the current wallet code. This leaves the keychain performing only key management functions (with one or two exceptions that can be cleaned up later), and creates a new module which should hopefully form the basis of the transaction building tier.
The next step, which I’m currently working on here, is to split up the code for the aggsig transaction workflow into a separate reusable library within the libwallet module, as opposed to embedded in the middle of wallet-implementation-specific code concerned with http connections and the like. The lib functions should simply take information from the caller, use it to build and return partial transactions, and then leave it up to the caller to decide what to do with them (e.g. forward to another wallet, output for inclusion in an email, etc). I’ve managed to split the functionality out successfully, but I think the lib functions still have too much awareness of the internal wallet structure, which I think needs to be addressed next.
As the wallet is cleaned up and solidified, better approaches to handling sensitive information should become clearer. What’s more, they should be easier to implement due to everything being in a more logical place.
That’s all that’s in my head at the moment, thanks for watching and have a good weekend!