Update Friday July 20th, 2018
This week was about adding more feature completeness to the wallet, and this roughly went as follows:
I forcefully shoved everyone onto using the LMDB Backend for their wallets via a small and automatic migration feature. It seems to have gone smoothly enough and I haven’t heard too many complaints, so let’s just assume all is going well there and everyone is now using a more robust and easier-to-develop-for LMDB backend for their wallets.
The Transaction Log has been added and appears to be more or less working in the initial instance.
With all of these changes in place and all of the previous refactoring work, it’s past time to update all of the wallet-related documentation, which I intend to address at some point next week. In the meantime however, I’ll give a bit of a tour of the new Transaction Log and why I thought it was very important to get this in place.
First, every wallet operation that adds or spends outputs (i.e. all of them) now logs the event in the transaction log. You can get a dump of the entire transaction log with the command:
grin wallet txn
The output of this command looks something like this:
As you can see here, each entry logs the time, amounts debited, amounts credited, number of associated outputs, and other information which makes it much easier to see what’s actually been happening with your wallet.
The above entries are the result of mining a new chain for a few blocks, then sending a transaction for 60 grins into the same wallet. You can see there that there are 2 resulting log entries, 6 and 7, that logged the creation of the transaction (regardless of whether it was actually posted to the chain, hence the status ‘unconfirmed’). If I want to dig a bit deeper into what’s going on with a particular transaction, I can now go, for instance:
grin wallet txn -i 7
Which shows a single transaction along with all of the related outputs:
In this case, you can see that outputs were locked and added to the transaction and a change output was created. They’re all at unconfirmed, as you can see, as the transaction hasn’t been posted to the chain and mined yet. Let’s wait a little bit and run the same command again:
Whoops, something went wrong here and the transaction wasn’t posted to the chain for some reason or another. Maybe the sender didn’t send it, there was a communication error or it’s just igno’s fault. In the pre-tx log days, this meant either going through your wallet data manually reverting the status of each locked output, or restoring the wallet, however, with the TX log I can now reverse the transaction out of my wallet by running:
grin wallet cancel -i 7
and check again with
grin wallet txn -i 7
Lo and behold, the unconfirmed change output is gone, and my previously locked inputs are now available to the wallet for spending again.
Now of course, this is the first pass and we have some eventualities to think about, particularly around not making a mess of someone’s wallet if someone does go and post the transaction after the receiver has cancelled the associated output. (On the sender side, a transaction won’t be valid if it’s posted after they’ve gone and spent associated outputs, but the receiver will have the output missing). We’ll deal with that in time, but at least going foward everyone should now have the transaction data accumulating in their wallets to deal with these sticky situations and reduce the need for wallet restores on every send failure.
Also, it’s much easier now to produce a usable web wallet with this in place, as it should be able to show a usable transaction log of what when in and out and when. You might point out that every other crypto wallet can already do this, but with MimbleWimble this doesn’t come for free; most other (BTC and clones) chain formats out there allow wallets to deduce this info from the chain, but since MW transactions are a pile of anonymous outputs, wallets need to keep this (very private) information separately. It will be a bit of a challenge ensuring this information is kept consistent on all sides, but very doable.
Right, that’s it for now. I’ll get fuller documentation up next week and hopefully make some progress on other smaller issues starting to pile up as well as another round on the default web client itself.