Update 09 December, 2021

Thx 4 the update Maidsafe devs

This is great news, can’t wait

Maybe staking could help or delayed pay out to the key :stuck_out_tongue_winking_eye:

Keep hacking super ants


hi @Nigel. No I was not aware of Mir. Thanks for bringing it to my attention.

I read over their ‘About’ page briefly and it seems quite interesting provided their claims hold up.

One big red flag for me is that they are using proof-of-stake.

proof-of-stake blockchain that uses the Tendermint consensus algorithm

Perhaps they have not read this analysis of POS vs POW. I highly encourage anyone wondering about POS security to read the article.

I don’t see POS as fatal for the tech though, because one could always fork their code and release a version that uses POW or (in our case) node-age + proof-of-storage.

I don’t know enough about Tendermint to comment on that.

It is exciting to me that more projects are coming out that focus on privacy, scalability, and decentralization. Hopefully our DBC implementation will see great success, but if not, it’s good to know there are options.

Another interesting project is Tari, which is building a token/asset system above Monero, and also written in Rust.


Thank you for the explanation, it was good. I gather its using something similar to/same as the deterministic keys that many wallets use, or am I wrong there.

Now not having delved into the crypto maths much I am unsure if sG is meant to be ‘s’ concat ‘G’ or multiplied. One way makes sense to me the other doesn’t, but I wish to be sure. Thanks


If it all relies on tender mint, AFAIK tender mint is very fast but is meant for PoS, though it is considered asynchronous, it apparently makes strong assumptions.

What I’m trying to understand is the recursive proofs article that I added to my post here.


Thanks team! I can feel that it is getting close and close!


Wow, it’s wonderful.

In link, it says that “which allows for hidden amounts, origins and destinations of transactions with reasonable efficiency and verifiable, trustless coin generation.”

My question is as follows.
The ring CT hides only the amount(contents), not the sender and the recipient in the transaction. I thought that anonymity is to hide all three of them, and privacy was to hide only the amount. Example is email, in which only the content of the email is hidden.

Also, TCP and UDT never hide sender and receiver. TLS hides only contents of the messages. Then, does the anonymity in SN only hide the amount out of the three? Is it correct? Very Thx all…


Is quantum-resistant ECC being considered/developed for RS? I don’t know anything about it, but I did have a look and apparently there is more than one way to do ECC and not every way is quantum-resistant. – Just thinking about down the road here.


One time keys hide the recipient.
RingCT hides both the sender (tx history) and amount.

So we should have pretty good fungibility and privacy, hiding all three.

CT alone (without ring sigs) hides only the amount. That was the very first privacy feature we implemented. RingCT is much more complicated.


Aha, Amazing. Thx @danda


Oooh almost there! Exciting times. Good luck squashing the final bugs, I am already warming up my fingers for some serious testing :computer:


I remember last year we were looking forward to a Christmas Present (Testnet). Here’s to hoping this year’s present is orders of magnitude more robust. My humblest gratitude to our “hacking super ants.”


Great news that a testnet is close. Well done tenacious M.


This is an interesting development @Nigel


How does the client get a bunch of random decoy keys?

Presumably the client doesn’t have a full list of the existing keys the mint knows about (they could since the spentbook / dag is public, but they probably don’t because it’s potentially a lot of data to retain locally).

Does the client store a partial list of keys for this purpose?

How would this work for a ‘fresh’ client with nothing in their pool? Can they request some random portion of the key pool and select from that?

Just checking my understanding of terminology…

It sounds like blind sigs are no longer being used (replaced by ring signatures), so there will be (very weak) links between transactions. Now the spentbook is a DAG (directed acyclic graph) which can be audited all the way back to the first transaction ever made. Am I understanding this correctly?

Any ideas on how many decoys will be used in practice? I guess more decoy keys is more private but also more computationally costly, and vice versa? Curious to hear more about the tradeoffs and scaling properties of this in the real world.

My understanding is monero uses ed25519 for their ring signatures, but we’ll be using bls for ours. Are there any other projects using ring signatures with the bls curve?


Great news MaidSafe


not that I’ve heard of. That’s why DavidR had to implement from ground up bls ring sigs then mlsag then bls bulletproofs then ringct.

I will defer to DavidR re your other q’s.


The safest way to do it would be to ask clients to have a copy of the spentbook, but that’s clearly not ideal. We need to be careful about having clients request random decoys from the network since a dishonest Elder might be able to de-obfuscate a transaction if they see the same keys in a transaction.

We can probably safely stay in a middle ground where clients request the latest 1MB of the spentbook from a few sections and pick a few decoys at random.

Yep that’s right, we have a DAG now, the audit is verifying that all paths up from a transaction leads to the genesis DBC.

Monero uses a ring size of 11, the computational cost isn’t bad, it’s the size of the signature which is most concerning. The signature grows linearly with the ring size.

Since we aren’t as worried about blockchain size, we could bump that up higher, but 11 is probably a good place to start.

I couldn’t find any unfortunately, it would have been nice to compare test-vectors.


Is there any insight into how fast TPS or settlement is with RingCT? Compared to say Monero or the other end of the spectrum, a plain centralized mint DBC implementation?

Also curious about how much storage space might be required for the spentbook to process x amount of transactions, say ~1million?


Also curious if it would be more scalable or faster if the entire supply was released at once, so that it wouldn’t be necessary to audit the money supply?


Good question but wouldn’t you still need to have the ability to have ongoing auditability to know it’s working as intended over time such as no double spends or inflation bugs?