DBCs and payments Wiki

An editable Wiki covering the workings and characteristics of DBCs and their implementation on Safe Network.


@dirvine’s post copied from a recent Update



10,000 foot overview (remember from the eternal optimist and simplicity seeker :smiley: :smiley: )
Please critique and poke at this as viciously as anyone wishes, it’s for the good of us all

Cryptocurrencies have all followed the following pattern (blockchain or DAG currencies)

Corrolate a bunch of transacitons into a Block and then somehow agree on which block of transactions are the next block.

Because of that they then

Append the block to the chain/dag

There are many reasons for that, but I feel its follow the leader, BTC did it (for good reason, i.e. slow processing of a block).

SAFE took a different approach

SNT is also a DAG based framework. However each transaciton is a single transaciton and the `chain’ or proof of validity comes from the fact the transaciton was an output form a previous transaction. You can follow that all the way back to genesis. However following it back one transaciton in a network that is secure and decentralised (sybil resistant) is enough.

People will run audits on full transaciton history etc. and that is good. It should be no differnt to other currencies.

However, this is the interesting part. As each transaction depends on just the previous valid SNT then we just need to check that previous SNT (parent). This means we have something quite special (and arguably obvious).

SNT does not write to a chain/dag of transaction blocks, each transaction is its own block if you like, where the block is the current SNT and its parent.

In short, this means we parallelise transaction across the whole network. Each group can transact circa 20,000 transactions per second. In a network of say 1000 groups that is 20,000,000 transactions per second.

If group size ends up at 5 (which I feel it can) then that is a network of a few thousand nodes (groups are interlinked like a Venn diagram, so each node may belong to 5 or more other groups, depending on distance).

We need to measure, but a network of 5000 nodes could reach multi-million tps easily, but a network of 5000 nodes is likely a failure as we use small nodes. So networks of several millions is much more likely (where many folk run 1-200 nodes each). This can lift the network into billions of transactions per second and all happening in parallel.

This is what is exciting and, again, obvious, but it feels like this is how digital currencies should work. At minimum, it makes nano payments possible and could usher a completely new set of protocols and networks.


@dirvine not clear to me from this, will the network ship with a means to do this.
The Safe Network version of a block explorer.


The means to create this is already there. Whether we do it or somebody else will just be time we can allocate. It’s probably best many do it


Although transactions can be audited, that doesn’t mean those who performed the transaction can be identified, correct?

Well you can identify the key, but using one time keys helps a lot there. Also using just a direct download to the SpentBook to get your DBC could show folks your IP, perhaps.

However, this is where I like mixing in simpleX, it’s decentralised, uses different protocols and can go via tor etc. as well. So using that to transmit the DBC could be very useful, but we have to play around with it. Its a case of having many ways to transact, of course dragons live in software with too many options, but I think there are safe routes for more privacy, we need to test these out.

If you are in the UK though it’s tough, HMRC can insist you almost AML your contacts who paid you (otherwise they can charge 100% tax), it’s really dodgy territory with more economic privacy. A big area to consider as we move on


This thread has been much needed for a long time :ok_hand: :wink:
It would only be appropriate to include a link to a previous thread on the principle of DBC.

Its a wiki, so anyone can add that link with say an appropriate title


So in general my node is never only in “a” group it is typically part of multiple groups?

And it’s role in each of those groups is equal?


Yes atm the role is equal in all these groups. We can take it further as we go past launch and perhaps use some of the language of the network patterns wrt a nodes role in different groups. Essentially though in terms of store and get data, the role is the same in each of the groups you are in.

This is where we can at last use the power of the xor distance to do some very clever things, but for launch we won’t need to. It just gives us more strength as we move forward.


Damn, I kind of feel like I have just opened my eyes for the first time.

The cogs are smoking trying to visualize, which for me is very much needed for thorough understanding, yet I think I see!

I know folk do not find it easy, but they are there all over the place inter-lapping, constantly changing and deterministic (well if you can stop time and just analyse the network fully, you may be able to identify the state, but like Zeno’s arrow it will give more questions than answers).

:point_down: On my way here but I think, I need to think more to have an idea of whether my thinking is correct.

People will (and should) look at this now and say, well that’s obvious. I can assure you, it only is after you see it (like a wheel or boat).

I don’t know how far I will get but may try using blender for a static 3D render.


A couple of questions about DBC’s…

Was it so, that there are some sort of fields for information in DBC’s? If so, what fields are there, and how much information can be placed there? Can that information be fetched from some public “ledger”? Is that information open to anyone, or only the owner of the DBC’s?

And is it possible to somehow “mark” DBC’s so that they can only be used to upload a certain file, for example? If so, could I then pass both the DBC and the file to another person / account / wallet, who can only use them to upload that file?


Yes a reason field

A 32 byte integer IIRC

Yes, but the DAG is not indexed by the reason field though


The reason field can help there, but likely we won’t use it like that.

You would need to pass the secret key to do that and if that is the case then just give them money directly would be easier.