Update 5 May, 2022

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 :eyes:

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! :bowing_man:

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:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: 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!


Could I, could I… be first?!

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.



Great update, thanks to all involved for the hard work. Nice to get a concise explanation of DBCs and how they will work on SAFE. Special thanks to @chriso for the unglamorous but essential work of getting the licensing correct. Also looking forward to reading @JimCollinson on the philosophy of the network.

Cant wait to get testing with the ELK stack and to exploring the Node-GUI from @davidrusu when it is a little more mature.


I’ll take bronze as always thanks to all the team :slight_smile: each week it feels like more and more pieces falling into place!!


Thanks for the update as usual

How fast should this take?
And what happens when 3 elders timeout? And how long is this timeout?


How fast should this take?

As fast as the big bang.


I think I can answer this one. Once the transaction is signed by the section it’s valid data and can be resubmitted any number of times (although it will only be processed once). So if some elders go offline it would just be a case of resubmitting it shortly afterwards when new elders have been appointed (max of a few seconds I’d imagine).


I am happy to see nice progress

So what are the options to discuss ?


Thanks so much to the entire Maidsafe team for all of your hard work! :racehorse:


Like the MAID-eMAID conversion, a LOT of hard thinking will be going into this.
Once the decision is made to take the SAFE network live, I imagine one option will be to launch with a fairly large number (1000s perhaps?) of well-specced DO droplets that will form dozens of sections. The genesis section will hold the genesis DBC presumeably and this will be subdivided into each section. As real users burn their MAID/eMAID for SNT they join these sections and receive their SNT from the section mint. Once a sufficiently large no of real users create nodes and we see that the network is large enough to defend itself, the DO droplets can gradually be dropped…


looking forward to the discussion on this and any misconceptions I have made above getting corrected.


Thanks for a week more hard work again!

Unrelated to today’s update, my spying the work in GH has led me to a view, that every little thing happening in the network is somehow signed, authorized, verified… And I like it a lot, feels like a solid system.


Any excuse :slight_smile: Bob Marley - Everything's Gonna Be Alright - YouTube


Another suggestion was to distribute everything to MAID/eMAID holders, the benefit of this being that sections don’t control large purses, meaning that taking a section over would have low rewards and not be a way to damage the network.

Controversial aspects of this are that distribution happens all at once rather than over time through farming, and that the initial distribution goes entirely to existing holders.

I think the latter feels worse than it is, and that the security of the network is a strong point in favour which benefits everyone. There have already been some discussions of this.

I don’t know if there are any other options under consideration.


Beautiful job, Maidsafe—it’s so great to see this progress!

Thank you for your work :pray:


ok, but who keeps track of that? Me as person, do I get an error and should I just try again till it works (I hope not) Or is there some safe magic taking care of this?


How would that work with 1MAID/eMAID == 1SNT ? Or has that been dropped? Should we be “rewarding” Poloniex (other bawbags exist) for their theft/misappropriation of MAID?




You would not have an agreement (enough sigs) and the section has changed. They tell you that happened so you retry. Your app will do this, not the human.


COOL things like that only in a Safe Update!