Update July, 29th, 2021

This week we’ll be taking a deeper look at DBCs, which have the potential to revolutionise online payments and simplify many aspects of the Safe Network economy. They really are that big of a deal, but in their standard form they have a few drawbacks when it comes private transactions.

One issue is that a mint can see the transactions passing through it and could, in the case of compromise, publish those transactions. This week we’ll take a look at a way to hide transactions from a mint - Pedersen commitments - and also a way to stop Pedersen commitments being gamed by bad actors - range proofs.

General progress

@danda and David Rusu are leading the design of confidential transactions and adapting DBCs to enforce one-time-keys. @danda goes into it in more detail in this post.

On the client side, @yogesh has been hammering away at the code to make it possible for clients to talk directly to sections where chunks reside, which is much more efficient than routing everything through one section.

Routing: @lionel.faber has been in touch with the quinn team who have offered some suggestions as to what’s causing some of the timeout / reset issues that testnet users will have experienced. We are also moving aspects of the routing functionality to qp2p to reduce complexity.

The great messaging rationalisation continues apace, with a merciless culling of little-used messaging types, which will reduce errors and result in cleaner code. As mentioned in last week’s update, messaging needs to be kept to a minimum for efficiency, and the same applies to the contents of the messages. Using CRDTs and having clients aggregate signatures allows us to eliminate a lot of the cruft and reduce the donkey work performed by the network.

One of the newer MaidSafers who’s up to his eyeballs in the message refactoring is @Chris.Connelly. Here’s an intro from Chris:

I’m an Edinburgh based software engineer with a background in developing web service back-ends and cloud infrastructure automation, but I’m now looking to broaden my horizons into distributed and decentralised systems. I’m passionate about holistic engineering (considering the whole system and avoiding specialist roles), and writing reliable software using Rust (and sometimes Elm on the side), and I’m hyped to be doing that here at MaidSafe!

Pedersen commitments and range proofs

Pedersen commitments are a form of zero-knowledge proof designed to hide the values in transactions. They allow the receiver to verify that the sum of all the numbers input in the commitment is equal to the sum of all the numbers output in the transaction, without revealing the numbers themselves.

So if I have 30 tokens, pay you 20 and someone else 10, this transaction can be verified by a third party (do the input and output values add up, true or false?) without them knowing the values involved.

In order for DBCs to be spent they must be authorised by a mint. Pedersen commitments make it possible for mint to check that input and output values of the DBC add up (i.e. it’s valid) and sign the transaction without having any knowledge of the amounts transacted.

One weakness of Pedersen commitments when used for validating transactions is that they can be fooled by negative numbers. A transaction with an input of 20 and outputs of 30 and -10 would be valid, but since ‘negative money’ can’t exist as a token, effectively the payer has turned 20 tokens into 30 tokens. Magic! (But not for the economy.)

Range proofs make it cryptographically impossible for an output value to be outside of a certain range, say 0 - 2^32. We enforce this by saying a transaction is only valid if each output also contains a range proof.

So, if I have a DBC for 30 tokens and I want to pay Alice 20 and Bob 10, the process goes like this:

I submit my DBC to the mint along with a Pedersen commitment with the (encrypted) input as 30 and the (encrypted) outputs as 20 + a range proof and 10 + a range proof. The mint checks the input and output values add up and that each output has a valid range proof, signs the transaction and reissues the DBCs to Alice’s and Bob’s (obfuscated) public keys.


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!

70 Likes

Foist!!! [goddam character limit nonsense]

24 Likes

Second. Body too short

15 Likes

Turd!!! So ah um

12 Likes

Great data!! Thanks.

10 Likes

Thx for the hard work Maidsafe devs

Banks/people are perfectly fine, with fractional-reserve banking (in the “real” economy) :exploding_head: might come as a surprise…

14 Likes

Soo its coming soon…:fire::fire::fire::fire:

10 Likes

Nice. Thanks for the 1000ft view of the DBC-Pederson-Range-proof work! Makes sense to me now.

Welcome @chris.connelly – may this welcome message arrive without too much refactoring. Thanks for your efforts and may the coding Kami be with you.

12 Likes

Soon can be 4 years if we are lucky, relax. I’ve heard soon since 2017

Just sell up then and stop moaning.

2 Likes

Have we hindered deliverable speed in any way by going down this DBC route?

1 Like

Eleventh! Great work team, and as a long time Monero enthusiast, I can only say that if their pioneering work makes SAFE better, then I will be a happy camper. Also, I do love hearing about complexity reductions and offloading some work from the network to the clients.

14 Likes

No, tenth because @Southside has spoken twice.

11 Likes

Sorry for distorting the count, folks

9 Likes

And you have just made things worse, and so do I

7 Likes

DBC’s have been a part of the plan for a long while so i personally i would say no.

Thanks for the effort team, appreciated as always.

8 Likes

DBCs bring so much more to the table that even if they added a couple of months more it would be well worth it.
IIUC the simplicity and flexibility of the DBCs turns the SAFE network from a really useful tool for privacy security and freedom into a total new way of transacting value globally at all scales that just happens to be a breakthrough for privacy security and freedom as well.
Aaaaand because of the greater takeup of the network driven by DBCs the network will grow much faster thus enhancing PS&F

Or am I getting carried away here?

EDIT: of course, absolutely no pressure on @JimCollinson to come up with DBC implementation workflows and UI to match the above mentioned simplicity and flexibility of the concept, no pressure whatsoever…

20 Likes

Even if I want to sell I can’t as a US citizen.

DM me - there is always a deal to be done somehow…

5 Likes

I have too, but if you see things on roadmap , core functionality is almost complete

4 Likes