Update 21 April, 2022

Last week we noted that Digital Bearer Certificates (DBCs) have been around for quite some time but have failed to gain traction as a basis for digital cash. In part this is because they required some sort of centralised governance. We believe that with Safe Network’s unique architecture, DBCs will finally live up to their potential. We explain why below.

General Progress

Membership has now been integrated into the Safe Network. This is the culmination of an epic slog by the whole team and it represents a major milestone.

Membership is the consensus mechanism which ensures elders can keep track of the adults and other elders in their section. Closely related is handover - the process by which data is exchanged between nodes on churns and splits. @qi_ma and @anselme are making solid progress here too. Distributed key generation (DKG), the mechanism by which new Elders reach agreement on the new section key, still has a few glitches to work through (or around) and that’s our main focus now that membership is out of the way.

We’ve set up initial benchmarks for some simple upload paths so we can a) check for regressions, but also b) get some nice visual output on relative performance as PRs are merged.

Meanwhile, new boy @Roland is getting sucked into the code, tightening up the workings of the resource proof module. And @bochaco has been making great progress with the DBC integration into the CLI.

DBCs on Safe Network

DBCs are a key component of the Safe Network, providing a quick, secure, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and offline. They simplify many of the workings of the Safe Network economy.

Most digital cash schemes feature a mint to issue DBCs and to check they are valid when they are presented back to the mint for reissue. They also need a record of transactions called a spend book or spentbook. With centralised systems, the mint and spentbook becomes a single point of failure, which is one reason these schemes have failed to take off.

However, a decentralised network allows ‘the mint’ to become multiple mints, with each section running and controlling its own spentbook. Indeed, this was our original design, but having a spentbook in each section made keeping track of transactions a challenge - we want to avoid having to sync between sections at all costs.

So, given that DBC’s will be used to pay for data-storage, we get into a bit of a chicken or the egg problem for how to store the spentbook on the network. We need to write to the spentbook to spend a DBC, but if the spentbook was backed by the existing data-types, we’d require a DBC payment to spend a DBC!

To circumvent this, we’re looking to introduce a new data type on the network optimised for the spentbook that does not take a payment to update.

When a client initiates a transaction, perhaps to pay for a data upload or to make a payment to someone else, it makes the request to the relevant section. The elders check the operation is valid and that the DBC does not already have a spentbook entry associated with it. Provided all is OK, they sign the data and write the spentbook to the network.

The fact that the spentbook is a piece of data on the network which can be referred to by anyone has some highly desirable consequences.

First, it means data which has been paid for and signed by a section (i.e. valid in the eyes of the network) can be republished any number of times for no extra charge. The elders simply check if there is a spentbook entry for a given chunk (which would have this “Network validation” attached). This allows us to handle lost outputs, machine reboots, elder churn, etc., and if the network needs to be upgraded we can easily revalidate all data.

It also means that we can do away with the concept of a mint, as the section elders are validating the DBCs as part of the process of writing the spentbook, which is a simplification and a burden removed from the busy elders.

The spentbook is linked all the way back to the genesis DBC meaning it can be audited. The design is still being finalised, but it involves having an ordering DAG that represents the spentbook but can be easily traversed. More on that soon.

The design of Safe Network offers intrinsic Sybil resistance, helping to secure transactions. The elders, of course, are the most trusted nodes in the section. Nodes are demoted for bad behaviour (Node Age), and an attacker can’t predict which section his or her node will end up in, so once the network is large, controlling a section would be infeasibly difficult.

Also in Safe we make extensive use of multisig cryptography, which was not a feature of the original DBC designs. It allows us to handle scenarios where, for example, a payment can only be made if a certain number of signatories have signed it off.

Another important advance on the original DBC is unlinkability. We are using Ring Confidential Transactions to obfuscate the sender, the receiver and the amount transacted, making it as cash-like as possible.

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!


Second!!! Err first!!!


I just let you have it this time :wink:


Bronze, once again!


Thank you. I owe you beer.


DBC’s without the Mint. Very cool! Tech journalists need to pick up on this.

So good to hear membership is in too!


Probably a good idea to wait for a working network, once the product is out, with working tech, and impresses everyone we can start showing off what this team has done. Before then, its just hype.


Im not so sure… If we can get decent reults over the weekend with a stableish Comnet and functional wallets and mints then I think its worthwhile making a song and dance about it.

If is working very hard in the sentence above, though…


nit: Chaum’s original blind sig DBCs were truly unlinkable. RingCT are linkable, but obfuscated/mixed (with decoys). This provides very good plausible deniability but finding an optimal decoy selection algorithm resistent to statistical analysis is an active area of research. A more concrete advance of RingCT is that tx amounts are hidden whereas chaumian DBCs were not.


This was the most optimal combination to choose though if I remember, yes? Balancing performance and (that now dirty word) fungibility.

Blind sigs needed denominations or additional amount hiding and had significant computational overhead that negated the speedy benefits of DBC’s?

You guys know what you’re doing and what was chosen sounds like a great implementation that can still be tweaked with future advancements to be improved.


Great work super ants! Things are getting closer each week.

Out of curiosity what was the specific trade-off(s) that made this unpalatable? I liked the idea of denominations on the surface. Seemed like a really unique way of doing things.

Thanks for the hard yards team! Cheers


30 posts were split to a new topic: Where did the denominations go? What about using CRDT for coins and alts?

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


Has it been checked if the bulletproofs is vulnerable to The frozen heart vulnerability that was disclosed a couple days ago?


Thx 4 the update Maidsafe devs

This is always good news :clap: :clap: :clap:

Keep hacking super ants


Sorry missed this, but yes, we did check and are clear there.


Thank you for the heavy work team MaidSafe! I add the translations in the first post :dragon:

Privacy. Security. Freedom