Update 22nd July, 2021

Yeah me too! :smile:

I’m all seriousness, the (re)assembled UI will come a little down the track, as we are neck deep in the masses of work that comes before that: market research, user needs analysis, mucho planning… It’ll come though!

And I have to say, I’m pretty damn excited about the prospects. It can’t be misunderestimated just what things like DBC, CRDT, pre-upload encryption, storage quotes etc bring to the table. Hopefully that’ll largely go unnoticed by the user. But there’s an elegance to it… a Safe (and the network) is now no-longer in the sole preserve of the online space.


I sincerely hope you find a good solution to unlinkability features soon.

I think this as a very important development. Thx. @danda


I think we agree, the past is over


Thx for the update Maidsafe devs.

Can’t wait for another testnet, would be fun if more people participated and if a testnet stayed online to be constantly bombarded.

:rofl: bravo

Keep up the good work super ants


Receipts seem like such a good feature but it should probably be a choice. An either or scenario. And if you choose to keep a receipt on Safe, there is a lack of anonymity in the real world too that I think most would understand. Can’t say receipts or some level of public verification of a tx is a bad thing but the ability to have one should not hinder the other either so I see the difficulty you have to engineer out of this.

Question. Do reissues have to be kept by a mint to be able to perform a future reissue of the same DBC or could a reissue be considered ‘settled’ and forgotten/deleted?

Edit: I think my answer is

I hadn’t thought of the fact you would have to go through this process again but I can’t wait to see how you present the elegance and possibility, Jim. Best of luck and keep those creative juices flowing!


No, I feel we should not (keep the re-issue, so here I agree with your conclusion) and for bad elders that do we might have a slight worry, but I don’t think so. For single use keys, we only need to write a Key Revocation Packet. Lots of internal discussions on this but I an very very keen we have revocation and use a form of it as SpentBook.

Here’s a snippet

Key revocation

Is a mechanism to identify no longer usable keys. The existence of a key in a revocation scheme means the key is no longer trusted and we should not accept any signature from it. In Safe parlance, it carries zero Authority .

Key recycling

Is a mechanism that effectively revokes a key and replaces that key with a new key. In Safe parlance, this means to carry over the Authority .

Key types on Safe

We have

  1. Data keys (a BLS key that Authorises mutations to the Data network).
  2. Node key (an ED25519 key that identifies a node)
  3. DBC key (a BLS key that represents a Dbc “owner”)

Each has differing revocation requirements and we will explain these next.


Data key revocation

These are always only revoked by the “owner” of the data. However, the choice is to revoke or rotate . Rotation allows the owner to move to another person or simply a new key, in case of possible security issues and users wishing to update keys, i.e. we can carry over the Authority . Revocation means this key can no longer authorise mutations.

Note: This key can be that one given to apps to mutate data and revoking this effectively kills the app for that user.

key == BLSPubKeyName + tag(01) // XorUrl
content ==
enum { Revoke: Signature // of key,
       Rotate: NewBLSPubKey, Signature // of key + new key, 

The Signature in both cases is produced by the key being revoked/rotated. i.e. only the key owner can revoke these.

Node Key Revocation

This is primarily a key rotation mechanism and we insist nodes rotate keys when being relocated, promoted or demoted. This gives us a trace of a node key history from its first Join . As above, but note the network can Kill the key.

key == EDPubKeyName + tag(02) // XorUrl
content ==
enum { Rotate: NewEDPubKey, Signature // of key + new key,
       Kill: (SectionKey, SectionSig), 

Here a node can rotate his key (only once) proving to any network section he has done this exactly once. The network can kill this key in the case of bad behaviour. ( @qi.ma this prevents the Sybil attack on relocation/demote/promote). Note: a new node joining will not have rotated a key and this packet will not exist as there is no previous key. On the first promotion, this packet has to exist to rotate from his initial key.

DBC key Revocation

Here we assume single use keys. This means a key is spent exactly once, although that may mean several DBCs with the same owner being re-issued, that key is then dead. We assume all DBCs have a nonce along with the owner field, this allows owners to derive keys for their DBCs without knowing anything except the nonce and their base secret key.

This packet contains the Hash of all inputs + outputs. This is used to link the spend against a particular set of transactions.

key == BLSPubKeyName + tag(03) // XorUrl
content == Spend: TransactionHash, Signature, // of key + hash,

The client will create the DBC KRP as follows:

FOR EACH input
  CALL hash_extend

FOR EACH output
  CALL hash_extend

CALL hash_complete
CALL create KRP
CALL store KRP

When this packet is stored then the client can request a re-issue. For many different input “owners” then this packet need stored with the same TransactionHash at the location of each key and signed with the appropriate key.

Mint re-issue

IF sum inputs == sum outputs
  AND EVERY input owner has a `KRP` with the correct TransactionHash
  AND EVERY output key has NO `KRP`                  
  AND EVERY input `parent key` has a `KRP`
THEN sign all output DBCs  

eliminating data loss!!! let’s have the wayback machine copied on here asap!


Maybe dumb questions but

  1. Are Pedersen Commitments considered discrete log contracts? Which I believe lightning network uses. I may be way off base there.

  2. I very curious how batching will work!?

1 Like

They are of a similar niche, but not exactly the same. You can do more than just confirm sum inputs == sum outputs with the partial homographic parts of pederson and more so with more homomorphic libs. So you can start to create a contract language from this. So kinda really :smiley: (btw easy answer is they are an important part and the discrete log issue comes from these commitments when using ECC and not RSA)

For us, self encrypt a ton of data, get store cost then pay for them all in 1 single re-issue. Then upload all data with payment (this is a 10,000 foot view though)


You know, when I heard Buchanan say homomorphic encryption I started wondering if you guys were clearing a path to pave later :smirk:.
My imagination started reeling a bit and I was wondering, if it’s using homomorphic, which should preserve privacy, could this feed into Big Data about the Safe Network economy? How money flows, supply, etc? Maybe I have that wrong about the computed results being anonymized?

The fact you could create a contract language is music to all of our ears and possibly a necessity in this market. Although smart contracting can be janky, dangerous, etc and should use formal verification IMO, it does still seem a necessity.

Thanks for taking the time for these responses @dirvine and @maidsafe team. They are really insightful.


Aye. In the current state it’s not looking too bad. I think the messaging refactor has had a fair impact here. (I think the consistency can be traced to the 0.7.14 release)

I’m hesitant to say fixed until it’s been proven in a public test net. But certainly it’s looking a lot better on that front. In fact on local test nets it’s never been looking better IMO.

But we’ve been hunting down some other issues with dropped messages (at the network layer) which we’ve been seeing when we go WAN. So your success isn’t reproducible on a public test net as yet, sadly!

You should hopefully see the downloads via cli much more robust too.


It says right on that page that they are using ring signatures and RingCT, both of which monero has been using for years. They mention some bulletproof optimizations, but I don’t see claims of anything fundamentally new…


Interesting but confusing. Pederson commitments is a form of homomorhpic algebra, I wonder about these claims (i.e TLS bulletproofs etc.) as many do use these now. In any case be good to know what advances in homomorphic encryption they do use and why? (ability to say sum inputs == sum outputs is homomorphic and pederson can do that, but need bulletproofs to say no output was negative and they still need bulletproofs).

A project I am tracking right now is GitHub - zama-ai/concrete: Concrete Operates oN Ciphertexts Rapidly by Extending TfhE where you have full range of homorphic algebra and looks like wont need bulletproofs. In any case it’s a bit muddy, I need to investigate Dero a bit more to see why they claim these things they do, wary it’s marketing though and some of these features are well known/used already. Then the roll your own crypto etc. The balance in crypto innovation and safety is a cautious but exciting one.


Thx for the link.

  1. The many-out-of-many Proofs paper looks quite interesting and possibly related to some thinking I’ve been doing this weekend regarding combining blind sigs with commitments. I wlll have a read.

  2. Pedersen commitments, which we are using (and monero) utilize homomorphic encryption.

  3. The linked page contains the following text/example, which indicates that whatever they are doing, it still utilizes ring signatures somehow, presumably for plausible deniability. (ring sigs are not unlinkable in the way that eg blind signatures are and typically have smaller anonymity set than eg snarks).

Fixed transaction sizes of ~2.5KB (ring size 8) or ~3.4 KB (ring size 16) based on chosen anonymity group size (in powers of 2), which have logarithmic growth.

| Ring Size |     TX Size    |
|     2     |   1553 bytes   |
|     4     |   2013 bytes   |
|     8     |   2605 bytes   |
|     16    |   3461 bytes   |
|     32    |   4825 bytes   |
|     64    |   7285 bytes   |
|     128   |   11839 bytes  |
|     512   |   ~35000 bytes |
  1. It says they are using an account based model, which means that their transaction model would likely not be very similar to DBCs, which is input/output based, and so might not translate well to what we are doing.

Wee note, not wanting to derail your points here.

This is a really nice thing we are doing, breaking that chain. So Dbc’s are just independent digital certificates. You can keep them anywhere. So there is no debit 1 account and atomically credit another. Hare we just atomically take some input DBC and output another one. (can be many <-> many). So no account, just like cash or bearer bonds etc. No accounts to then have to “hide” what’s in them and history etc. We don’t have accounts and I really feel it’s much more natural to not have accounts.


I think it’s even simpler. Each DBC has an amount the owner knows. He can re-issue that to new DBCs/amounts only him and new owners know.

The mint just needs to re-issue this if it’s certain the input DBC can be atomically marked spent. We will do this very easily though where the owner kills his own DBC with a transaction hash. The transaction he makes (in->out) matches that transaction hash and passes business logic (sum inputs == sum outputs) and signed by owner and then the re-issue works.

Really simple and no need to think unspent tx etc. Just I have a cert for 20 and I can split it into 2 for 10 each etc.


For more context on this part see Update 22nd July, 2021 - #27 by dirvine


Yes in general dbc is closer to utxo than accounts.

But importantly dbc mints do not keep a list of unspent dbcs. They only have a list of spent dbcs (or rather the hash of the spent dbcs). A utxo list is the list of everything that hasn’t been spent yet - this list doesn’t exist with dbc mints! This is kinda unintuitive coming from a blockchain perspective, but there’s a good section on it in smuggler’s guide to dbcs. This difference with utxo vs dbc mints affects privacy and fungibility so is fairly important.

DBCs can still be kept together in a wallet by people, but that’s not ‘an account’, it’s a wallet.

There’s a pretty neat comparison of utxo (and wallet) vs account in this reply to What are the pros and cons of Ethereum accounts vs. UTXOs


You can happily give them the key as it’s a one time key. The transaction was done and the key was spent. To where though is the question and here there are a few points to consider

Assume the mint node kept a record of input keys and output keys (worse case). What they would know is you spent it, but not to whom? There would be several output keys, some may be yours and some not, we cannot tell.

Now, how many mint nodes will be bad and colluding? With node age this is unlikely after the network starts, our research showed that section of over 60 nodes with churn every 5 mins and net size starting at 2000 can take decades to get byzantine nodes as Elders, so with many hundred sections then this is increasingly unlikely, but not impossible.

So say worse case they can, all they know is keys went in (they may know the value a key had if you told them as in your question(similar to having marked bills in cash) ) and a number of keys went out. So they would, in that case, say, you had 100 and spent it so you need to pay the tax and that’s fine. However, if they did not know then you need to tell them. Also they don’t know which keys received which amount.

I think this is fine, large merchants will need to pay tax presumably and it’s likely the authorities can say, hey you posted a key, how much did you receive? From there then it’s cash really!

Hope that makes sense