SafeNetwork DBC Technical Series

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

Does anyone know if this is correct?

1 Like

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?

Very thanks @JPL


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.


Good point! Thx @Nigel


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.

spend_key = input_dbc.owner.derive_child(sha3_256(input_dbc))

This data is stored by the three adults closest to that XOR address.

Once this immutable data exists, the DBC is considered to be already spent.


Yep, public

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.

@JimCollinson Is that correct?


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.


That’s my understanding, but @danda or @davidrusu would be the guys to ask for all the juicy detail


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

Is this something that will be done during normal sending SNT? (well the receiving and spending it I suppose)

If so what is the expected penality in processing due to that?


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.


@davidrusu So to be sure, the mints, elders, sender, nor receiver has to do that sort of checking? Just check the parent.

Good to hear cause it could get quite lengthy process for one of the actors.


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.


This is where auditors will live IMO.


This is a quantum leap in the network’s security. Using more than one section to complete a transaction has always been my biggest dream.


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. :tada:

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 :tophat::clap:


A good basic summary of ring signatures from 40m37 to 42m00

More technical details about ring signatures at 61m27 to ~73m (really nice explanation, and imo well worth watching the whole video!)