We’ve dug into the workings of digital bearer certificates (DBCs) a fair bit of late, investigating how they work and why they are such a good fit for the Safe Network, but what actually happens when you pay for a data upload or transfer some SNT to another person? DBC transactions are the topic of this week’s update.
General progress
Handover is now done and dusted and integrated into sn_network, thanks to some solid work by the team, particularly @anselme who has been chipping away at this for the past few weeks. As a reminder, handover governs processes like splits and node dropouts, where we need to be sure data is being replicated to the right places with sufficient copies for redundancy.
@Chriso has completed the first version of licence verification automation. Having recently rationalised the licensing of our code, we want to make sure it stays that way, and ensure that our code is only used as we intend. The GPL3 licence is ‘copyleft’, which prevents ‘sublicensing’, i.e., people who derive anything new from the original code are not permitted to change the licence type on their fork; this ensures any Safe code will remain open source. For generic libraries, we’re being less restrictive.
Why BSD-3-Clause? As with MIT and Apache, it’s pretty liberal, but the additional third clause, which prevents endorsement of the original authors with any derived products, is useful to protect MaidSafe’s reputation. We used to have dual licences on many repositories, but there doesn’t seem to be much benefit in that, and it’s easier for an automated process to enforce the use of one.
On the system monitoring and visualisation front, @yogesh has been tinkering with the ELK stack and it should be ready for the community to try out very soon. Watch this space 
And @JimCollinson has been putting into writing the strategic aims of MaidSafe and the Safe Network, looking at the key measures we need to take to achieve our goals as well as identifying any potential hurdles, giving us time to plot a course around them.
Also a hearty thanks to @stout77 for providing this weeks cover image! 
DBCs in action
What happens when you spend a DBC on the Safe Network? What are the elements of a DBC transaction? Before we dig a little deeper, a very brief recap…
A DBC is a digital file that encodes a number of factors including its parent, the amount, and an authority such as a signature or key to show it’s valid. To spend a DBC you first need to have it reissued by the elders.
A transaction is also a digital file. In this case it encodes the input DBC(s) and the output DBC(s).
A simplified version of a transaction on the Safe Network goes as follows:
A client (a person or an application) creates the desired transaction, for example “take this 100 SNT DBC from my wallet and create two new DBCs, 90 as payment to the shop and 10 as change to me”. The client signs the transaction and sends it to the appropriate section according to its XOR address.
The section elders validate the transaction, ensuring all inputs are valid DBC’s that have never been spent, and then write it to the spentbook.
Each elder checks the transaction is in the spentbook and that the sum of input and output DBCs is zero (so money is not created or lost, just transferred to new DBCs), and returns the transaction to the client with its signature share.
Once the client has collected a supermajority of signature shares (5 out of 7 elders) it resubmits the transaction with the completed signature to the elders, after which it will be reissued. Double spend is prevented by the fact the transaction with its outputs is already recorded in the spentbook. Each output DBC can only be reissued (spent), so it doesn’t matter how many times it is resubmitted.
Checking and obfuscation
The above is all well and good. It prevents double-spend and removes the need for sections to sync spentbooks between themselves. However, it can be improved.
First, we use the Rust bulletproofs library to check that the range of the DBC amount is positive - negative amounts would allow money to be created from nothing - an obvious no-no.
The second important measure is obfuscation. We use ring confidential transactions (RingCT) to hide the owner and the recipient keys. Although the owner key is hidden, the elders can still tell whether the transaction recorded in the spentbook is valid. Similarly, bulletproofs hide the amount, but they can still check that the input amounts balance the output amounts.
The obfuscation steps occur before the transaction is written into the spentbook, effectively breaking the link between the parent DBC and its outputs. If we didn’t do this it would be easy to trace all transactions, since all DBCs link back to the genesis DBC, and there would be no privacy.
The genesis DBC
We end at the beginning, in that the precise details of how we distribute DBCs to farmers and Maid holders are still being worked through. Current thinking is that all SNT will be encoded in a single genesis DBC - one with no inputs.
So, all SNT that will ever be created will be in this one form, like the universe before the big bang. Once the network launches for real, the genesis DBC will be reissued and subdivided and spread across the firmament. The best mechanism for this distribution is what we’re looking into now.
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!
each week it feels like more and more pieces falling into place!!
