Below is a list of dev-updates (or other articles) that describe how the DBC system works.
Update Mar 30, 2022: Last fall we implemented RingCT, which enables good fungibility, amount hiding, and a way to audit the money supply without need for denominations. As such, it was decided to go ahead with the RingCT (amount hiding) fork and abandon the blind signatures fork.
There is presently no writeup of the RingCT functionality. However, our implementation follows Monero RingCT pretty closely as documented in Zero to Monero, although we use BLS cryptography rather than ED25519. Also, @davidrusushared a diagram below.
The DBC architecture continues evolving so the above articles may be somewhat out of date. Further documentation will be forthcoming at a later date.
At this time (Oct 21, 2021) we are maintaining two forks of the code with different tradeoffs. A final decision has not yet been made which to go with.
The intent of this topic is to have a single starting point for anyone interested in learning how these work. It may also serve as a starting point for a future whitepaper.
If I’ve missed any useful articles, please let me know in the comments below.
In primer (SAFE Network Primer), I read that “Before spending a DBC the Client must create a Spentbook entry. This is an immutable data item stored on Adult Nodes on the Network.” I think this means the spentbook is blob data type.
But when I read this I thought that the Spentbook saves the combination of the blob (binary large object) and the multimap. In this case, since the multimap is a mutable data type, so it must eventually become a mutable data type.
Otherwise, I wonder if Spentbook is new improved blob with a list type. Very Thx @danda
As I understand it, the actual spentbook data is immutable - it would need to be so spent transactions can’t be manipulated, so a blob - but pointers to that data are stored as mutable data in a multimap structure.
I agree. In my opinion, the spentbook will be private and only the elders can see it. And I think that the immutability of it will be maintained by the elder’s super majority.
If it is also true, it uses multimaps and is not immutable. Thus it is only protected by consensus of elders in section. Is it correct?
I could definitely be wrong but I thought it was actually public so that the money supply is auditable but obviously every transaction still hides amounts with Pedersen commitments and sender/recipient with use of ring sigs and one time keys.
As far as I understand the main trick is that each entry in the spentbook is stored, as immutable data, in a unique XOR address that is deterministically derived from the hash of the DBC.
But the issue here for third parties to see the transaction they need the address in order to even see this spendbook entry if I understand the logic. An address is derived from the DBC for the spend book entry which is known by the sender and receiver, and the mints when asked to do something (its given/derived).
From what i also understand somebody is not able to go and look at all the DBC transactions and their corresponding spend book entries simply because its impossible to know where to find them, the address space is just too large to do sequential/random searches.
I believe you are correct, and that there was some possibility being considered of providing a way for the spentbook to be traversed to allow audit of coin supply.
I suspect that might not be feasible though because it will grow so large so fast it should become impractical to traverse it in a reasonable time.
Even now, downloading blockchains is impractical for most people, and once only a select few are able to audit you are back to trusting the word of others on that, and might be better trusting (and proving / testing) the technology.
With the present design (CT), the spentbook is traversible from a given DBC back to the genesis DBC, because each DBC encodes the reissue transaction (inputs and outputs) that generated it.
With RingCT, things get trickier because the inputs are obfuscated. I will need to check with David R for details on how auditing money supply can work, but I think it shouldn’t be too different from how monero does it. We are also considering use of a DAG. I expect we will make a writeup about these things in a future dev update.
I’ve tried to illustrate the obfuscation of the transaction graph: Here we have each transaction happening in sequence, building up the transaction graph.
The bottom sequence shows the true transaction graph, where as the top shows the decoy inputs in grey. Here we are padding each transaction with 3 decoy inputs.
The final obfuscated DAG is what you’d see when you look at the spentbook.
Auditing the spentbook:
within a transaction, we can always verify if the sum(inputs) == sum(outputs) and that all outputs are positive (this relies on Pedersen commitments and range proofs)
from within a transaction, we can’t know if an input is a fraudulent DBC, we need to go to the spentbook for that. i.e. Someone may have convinced some dishonest mint to sign an invalid DBC.
To check if a DBC is real, we need to check that all paths up the DAG starting at that DBC leads to the genesis DAG
We’ve decoupled the section that mints a new DBC with the section that writes it to the spentbook DAG so you will need Elders from two sections to be dishonest and collude to get a fraudulent DBC added to spentbook (anyone watching the spentbook will be able to see that the fraudulent DBC doesn’t pass validation).
So what this means is that it is often enough to check that a DBC appears in a spentbook to be confident as a receiver. I’m sure we’ll see spentbook explorers (ala. blockchain explorers) to make this quick if you’re doing it by hand.
If you suspect cross-section collusion, you could stream the Spentbook DAG from the network so that you might validate the DAG yourself all the way to the genesis DBC.
The mints are doing this check on an ongoing basis when they add new transactions to the Spentbook, but this check is cheap for them since they can trust the existing spentbook entries they’ve already validated.
It’s similar to miners only checking the latest block since they’ve already checked the chain when they bootstrapped
The mints are just doing 1 spentbook lookup for each transaction input.
Senders / Receivers don’t need to check at all if they trust each other
if they don’t trust each other, but trust the mints, it’s 1 spentbook lookup per input.
if they don’t trust the mints, they need to get a copy of the spentbook and validate from genesis.
I get excited reading this because it is getting more real and it seems to me, better than I had hoped (eg two sections as @digipl said). Thank you @davidrusu for the vital work you have done and for the explanation.
We seemed to lose some important qualities when things moved away from SafeCoin as a data type but I think MaidSafe have managed to get them back and create a better more capable solution which is quite something. Very rare in my experience so to everyone who has been wrestling with these ideas I take my just of to you
