Update 14 April, 2022

If you Google Digital Bearer Certificates (DBCs) you’ll find that this forum comes up in the first page of results, which is pretty amazing when you think they date back to the 1990s. This week as we prepare to integrate DBCs with the rest of the codebase we’re going to do a quick review of the history of DBCs, what they are and what they aim to achieve. Next week we’ll go over how we’re tailoring DBCs to take advantage of the unique architecture of the Safe Network. We’re breaking brand-new ground here folks!

General progress

@yogesh has tidied up the last bits of automating the Metricbeat service on testnets and we now have a dashboard that visualises all our testnet nodes’ metrics (see this PR). We’ll be testing this internally asap, and then hopefully opening it up to the community thereafter.

Meanwhile @JimCollinson has been updating crypto exchanges and listing sites including CoinMarketCap to update them about the ERC20 eMaid option and also highlight the potential of DBCs. In parallel he’s been working on the new whitepapers, with a focus on Token distribution in particular, which we look forward to hearing with you all via the Request for Comment (RFC) process in due course.

@Bochaco is working on wallet commands and the wallet API, and has a PR merged there. Next step will be to get the node side of the equation going.

@joshuef has merged a large refactor of some of the node internals, pulling sn_interface out of sn_node as this is common code used for both nodes and clients. The end goal here will be to get a separate top level crate for both nodes and clients in the safe_network repo. Somewhat similar to our prior modular repo structure… but everything in the monorepo to keep updates smooth. This should help keep the code modular and more easy to test, as well as (hopefully) make it a bit easier for newcomers to the repos to get into the code.

There’s been good progress on the membership front. We’re seeing where some issues lie with different elders having a slightly different view of section members, which looks like it has been the sticking point for section startup and splits. There’s a couple of angles of attack there, so we’re investigating those now.

And last but definitely not least on the engineering front, @anselme and @qi_ma have made some positive steps with handover consensus (the process by which elders pass on their data/knowledge on changes to section membership) and are currently working with @davidrusu to get this working properly on section splits.

Finally, you’ll have noticed that eMaid is now available :tada:. Many community members have been asking for this option for a long time, but this apparently simple move is actually extremely complex and would have taken too much time for the MaidSafe team to organise, to the detriment of the network. So huge thanks to @Sotros25, @SwissPrivateBanker, @Bamboogarden and others for stepping up and making it happen. A fantastic achievement.

Digital Bearer Certificates

DBCs aren’t new, but amazingly, given their potential usefulness, they are not well known even in the crypto space. Because of that, as we start to integrate DBCs into the network we thought a little backgrounder would be in order.

They provide a quick, safe, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and offline. They simplify many aspects of the Safe Network economy and remove the need for section wallets or similar mechanisms to manage SNT transfers. Transactions using DBCs are very quick and low on resources - unlike blockchain transactions.

DBCs were first proposed by Nick Szabo in 1997 as a way of digitally transferring and storing value. They’re not much to look at, just a long string of characters, but those characters encode important information such as the value, the owner’s key, the recipient’s key and the signature of the mint that issued or reissued it.

DBCs can be transferred to another party online (e.g. email) or offline (QR code), split into multiple DBCs or combined into a new one.

A DBC has two important characteristics (1) it needs to be valid (2) it can only be spent once. The first of these is achieved by requiring each DBC to be signed by a mint, and the second by requiring a DBC to be reissued by a mint before it can be spent.

A mint is a simple application for issuing and reissuing DBCs, and for checking they are valid and have not already been spent.

The mint keeps a record (often called a spend book) of all the DBCs it has reissued and each time a DBC is submitted for reissue it checks this record first. The other check that the mint does is to verify the signature encoded in the DBC. In the ‘classic’ DBC design, only the mint that issued the DBC can check this signature. So long as the signature is OK the DBC will record it in the spend book.

Some DBC designs use blind signatures, which allow DBCs to be verified without the mint or the receiver of a reissued DBC being able to know its value, the sender’s identity, or other factors.

The beauty of DBCs is that they are simple, quick and flexible. So long as you have access to the mint you can split them, combine them, pay for goods and receive change, similar to cash.

One downside is that they are hard to secure, as the mint is a single point of failure.

For one reason or another, DBCs have failed so far to live up to their potential. Digital Money and DBCs [PDF] is a great non-technical read on attempts to create digital cash.

But the design of Safe Network, with autonomous sections each capable of performing the issuing, reissuing and auditing of DBCs gives us a unique advantage.

So, we’re taking this centralised concept and leveraging the Safe Network’s secure decentralisation to shard the central mints, allowing for a decentralised distributed ledger.

More on that next week.


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!

76 Likes

First

Omg it’s been a looooong time since I was first to comment on a weekly update!

Congrats to the Maidsafe team for the constant progress !

43 Likes

Second. Now to read.

21 Likes

Ill take the bronze then

20 Likes

out of the podium

well done team!

17 Likes

Pardon my language but it feels like shit is getting real again. I mean that feeling we all got in 2017 but better and more real.

Huge thanks to @Sotros25 @SwissPrivateBanker @BambooGarden

So looking forward to the SNT RFC and white papers :+1:

26 Likes

“Digital Money and DBCs”

“spendbook is the only element of a Mint that has to be tightly synchronized and
access to it has to be strictly serialized.”

How will it be tightly synchronized, serialized over a large world wide decentralized network with huge amount of nodes and sections? Sounds like DBC requires a centralized national bank style entities, or only a few highly synchronized and serialized banks.

“Failure at this can lead to race conditions
which allow double spending of DBCs.”

10 Likes

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

And congratulations for the rollout of the ERC20 MAID. :racehorse:

11 Likes

image

10 Likes

Several reasons. Elders need to see inputs parent DBC is spent. They see that to sign the mint request.

However, we do a neat trick (this is easily overlooked). We have the client write the spentbook too. So the transaction already has the client’s authority, and the input DBC is spent by the client. That means groups of elders can sign as many times as they wish as the transaction contains the output DBC’s (and that is reflected also in the spentbook). This means the client is responsible for the tight sync, and all we need is a network that holds data permanently. We got that :wink:

24 Likes

Hat off the team. Hello DBC world.

14 Likes

Thanks @Sotros25 @SwissPrivateBanker @BambooGarden and @maidsafe !

I was wondering if there are already projects starting from the bamboogarden fund?

Also, is SNAPP and the browser still on the table or is this for after launch? @JimCollinson

9 Likes

Happy to help! :smile:

Just to reiterate, eMAID did not draw from the BGF. That being said, there are (potential) BGF projects / initiatives in the works.

13 Likes

Very much this!

I like it! Noun + noun. :wink:

7 Likes

Going to reply here because I dont want to be a downer in that thread.

but it is not a statement in an official manner regarding accepting eMaid.

It is a one way conversion which makes it so much more important that Maidsafe explicitly and formally state that they will honor eMaid.
Soton linked a comment in a thread and that is far from sufficient in my opinion when very large amounts of money is at stake.

7 Likes

Good news!

Well done all involved in getting the eMaid stuff together.

While I’m never that bothered about what’s happening with the token price, 'cause I’m just looking forward to the network going live, I’m guessing more trading volume will raise the project profile again.

11 Likes

Beautiful job, folks—thanks as always for these updates!

:ant: :ant: :ant:

12 Likes

So much happening all at once; eMAID, DBCs, listing sites etc. Far beyond my expectations, amazing work! :smiley:

10 Likes

I think DBCs are a very important innovation in asset transfer. So, I am very interested in DBCs. Thx @maidsafe team and all.

13 Likes