We introduced the idea of the Client writing the Spentbook a short time ago, and have been putting our heads down since then to work out the best way to implement this. This week we’ll explain our thinking so far.
General progress
Some successful bug bashing this week. @Chriso has got the CLI / API tests working properly, meaning the sn_cli / sn_api / safe_network combination is now more or less stable. In fact, the CLI and API are now ready to be merged into the main repo, which will mean no more hassle with having to combine compatible versions. 
On that note it’s fantastic to see folks getting stuck in with the community testnet. Kudos to @josh for getting it off the ground. It flew for a while, which is good to see, and most importantly the log files it generated are a big help with our bug hunting, so thanks for sharing updates so far!
@bochaco has been working on some debugging tools that reads nodes’ logs to check that each message received is being processed to completion. On receipt of a command, a node should (a) do as instructed or (b) return an error, but occasionally they sit and do nothing which (c) can cause odd bugs or even (d) effectively lock up the node. Using this tool they have tracked down and fixed some possible culprits and so far the situation seems much improved. The same analysis can be used for the rest of the team’s bug hunting too, including @yogesh and @qi_ma who are investigating similar occurrences of deadlocking (endless loops) happening with internal commands. We plan to integrate this checking tool into the CI process.
Client Writes Spentbook
Before spending a DBC the client must create a Spentbook entry. This is an immutable data item stored on Adult nodes on the network that contains details of the desired transaction and ensures that once the transaction (DBC reissue) has occurred, the same DBC cannot be spent again.
In our current thinking, the flow goes like this:
- Client creates Spentbook entry and signs it with its public key
- Client sends the signed Spentbook entry to all 7 Elders in the relevant section
- The Elders write this Spentbook entry to the closest 3 Adults to its address
- The 7 section Elders sign the Spentbook entry with their BLS key share and return it to the Client
- Provided the Client receives at least 5 such messages (a supermajority) it combines the BLS key shares to create Spentbook signed by a valid section key. At this stage it is called a Spentproof
- The Client can now ask the Elders (which also run the Mint software) to reissue its DBC. It sends the DBC together with the Spentproof back to the Elders who now sign the reissue.
This process has a lot of attractive features: the network is not involved in the complex process of holding state (current information about account balances, etc); the Client does the hard work; the number of messages back and forth is acceptable; and it should be reasonably simple to implement without any major reorganisations or refactorings.
We’re still working through questions of auditability (proof of payment, etc) and optimisations, but this is the basic structure of how we avoid doublespend.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add them here:
Russian ; 
German ; 
Spanish ; 
French; 
Bulgarian
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!
