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:
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!
might come as a surprise…