Where did the denominations go? What about using CRDT for coins and alts?

[jlpell]

@maidsafe

We are using Ring Confidential Transactions to obfuscate the sender, the receiver and the amount transacted, making it as cash-like as possible

Where did denominations go? Denominations were a real winner imo. Blind signatures are rather elegant. Seemed like the perfect combination for a safe network…

[happybeing]

They had some limitations. From memory I think one was around anonymity or tracking, but don’t recall the detail. There were threads about these questions.

[TylerAbeoJordan]

@jlpell

Blind signatures are rather elegant.

Yes, it was all interesting work as I recall. I think it was @danda who worked out the ring sigs that replaced it? So I presume it has to do with fungibility/history/tracking?

I’m curious though as to the specifics here myself. I’ll have a look in the old threads, but if anyone can say specifics here, then my thanks in advance.

[Nigel]

As I recall denominations caused way too many reissues which caused too much overhead for elders.
I’ll let someone more knowledgeable correct me, if I am wrong about that.

I too liked denominations, very novel for crypto and also familiar for the masses in fiat. Perhaps it could be L2 though much like Wasabi wallet does?

[TylerAbeoJordan]

Yes, I just found this post by @danda that explains the decision:

Update 02 December, 2021

Our goal is (and has been) to make the most fungible and efficient token that we can. As such, we have looked at and experimented with any technology that is promising in that direction including blind signatures, ring signatures, and even (a little bit) zk-snarks. Blind signatures are neat because they offer provable unlinkability. Unfortunately they require the use of denominations, which expose the transaction amounts, make the anonymity set smaller, and require many more DBCs (and network…

Seems that blind sigs needed denominations and the latter had high overhead for the network and exposed transaction amounts. I’m still curious for more specific details, but perhaps there isn’t any as it was mostly theoretical work (no working models to compare).

edit: Also found this regarding denominations which I found interesting:

@maidsafe

It is therefore important to keep the total number of denominations small. One could for example define every integer value to its own denomination. While this would work technically, it is bad for privacy, as people will often use very unique amounts. Instead of merging into an ocean, a single drop wanders by itself.

[jlpell]

@TylerAbeoJordan

just found this post by @danda that explains th

Thanks for pointing this out.

[davidrusu]

We tried quite hard to make Blind Signatures work but in the end we could not crack auditability.

That is, we could not find a way to detect if a faulty Mint had issued a new DBC from thin air.

[jlpell]

@davidrusu

we could not find a way to detect if a faulty Mint had issued a new DBC from thin air

Out of curiosity, how is this different from a faulty section writing junk or destroying chunks?

[davidrusu]

For DBC’s, auditability is a matter of building trust with the folks putting their money in the system. If they can’t verify for themselves that mint’s are not printing money (and therefore devaluing the currency) then it’d be a hard sell to convince people to trust the Safe Network with their funds.

Section’s writing junk / destroying chunks

This would require co-ordination between both elders and adults (adults can validate all requests themselves, i.e. writes need to be signed for by the clients, Elders can’t spoof these updates), it should be vanishingly difficult for an attacker to get that much control over a section!

[jlpell]

@davidrusu

mint’s are not printing money

Isn’t money printing impossible due to the conservation laws enforced during dbc transfers? (in == out)

[davidrusu]

With Blind Signatures, there was a way for dishonest elders to skip the in == out check, they could simply sign some new DBC’s into existence and since the DBC’s were unlinkable, no-one could tell the difference between these freshly minted DBC’s and any other DBC.

We tried lots of tricks to enforce the in == out check, but we either lost unlinkablity, or the results was unnecessarily complex (i.e. we had explored an option where we tried to combine RingCT with Blind Signatures, but… RingCT works just fine on it’s own!)

[jlpell]

This might be of interest to you:

“Leaking arbitrary many secrets: any-out-of-many proofs and applications to RingCT protocols.”
https://eprint.iacr.org/2021/1405.pdf

[davidrusu]

I’ll take a look, thanks . The monero folks are also busy working on their next gen RingCT system as well. These things take quite a while to implement and test out so we’ll likely be sticking with the tried and true RingCT system for the time being.

[danda]

@TylerAbeoJordan

Out of curiosity what was the specific trade-off(s) that made this unpalatable? I liked the idea of denominations on the surface. Seemed like a really unique way of doing things.

The blind sigs approach required denominations to avoid distinguishing amounts and the more denominations available the smaller the anonymity set is. Also very large value tx tend to stand out as they may have an anon set of eg 1 for any given time period if wallet is not careful. Also denoms usually required many DBC reissues to achieve a desired payment amount. So while the blind sig reissues are individually smaller and faster than a ringct reissue, they would be larger/slower in aggregate to affect a typical value transfer. (ie not enough smaller/faster). As DavidR said though, the straw that broke the camel’s back is that we could not find a solid solution for auditing the money supply (at any point in time) to prove no inflation has ever occurred.

@TylerAbeoJordan

I think it was @danda who worked out the ring sigs that replaced it?

No that was 100% the brainchild and hard work of @davidrusu. Once he had all the tricky things working with bls cryptography (bulletproofs, ringct) I just took them and integrated into the sn_dbc crate.

@Nigel

I too liked denominations, very novel for crypto

yeah, it’s pretty neat/novel. especially the infinite divisibility and nearness limits. I think there is room for an experimental crypto to try out that kind of system yet. But at the end of the day, people just want to transfer value (privately) right? So how it is accomplished technically “under the hood” shouldn’t matter to the regular user.

@davidrusu

That is, we could not find a way to detect if a faulty Mint had issued a new DBC from thin air.

here “faulty mint” could mean a rogue section that has somehow been taken over by an attacker. In theory it shouldn’t ever happen, but we wanted to be able to say with certainty that it had never happened, and for users to be able to verify this for themselves by examining all historic spentbook tx.

[jlpell]

@danda

As DavidR said though, the straw that broke the camel’s back is that we could not find a solid solution for auditing the money supply (at any point in time) to prove no inflation has ever occurred.

IIRC one of the nice properties of “classic” safecoin was that the 2^32 addresses held ownership information of current and previous owner only, known only to the current and previous owner, and mutable only by the current owner. There was a single denomination of 1 SC. I have always found this to be a rather elegant approach. Seems trivial to audit when coin addresses are known from the beginning (although perhaps a rogue section could destroy coins)? I was hoping that the dbc with blind sig approach, combined with your denomination upgrade, could regain some of this simplicity/elegance and also achieve near infinite divisibility.

p.s. A fun read on divisibility limits for typical money systems:
https://www.sciencedirect.com/science/article/pii/S0378437120305975

[neo]

@jlpell

p.s. A fun read on divisibility limits for typical money systems:

The paper does not explore the ability of digital storage to have the situation where the quantity is stored with one limit and the minimum transaction amount is much higher than that.

For example have the “money” recorded to 1,000,000 decimal places but you cannot transact anything less than 18 decimal places. Crazy situation but its to illustrate the point.

• some “bank” (loan company) gives interest at some rate. When interest is sent to your wallet, it is accurate to the million decimal places but always equal to or over 0.000000000000000001 (18th decimal place)
• splits are accurate to a million decimal places
• while its possible to have 0.0000000000000…0001 (millionth decimal place) you could not use it due to the limitation.

The point is this allows dividing the “money” a lot further than the energy to store one bit because the transaction amount must always be a much higher. This allows accurate accounting and if allow a special wallet transaction to consolidate addresses in the wallet then its possible to never leave dust in unused addresses.

[danda]

thanks for this link. The paper touches on many of the issues/considerations I was looking at with regards to denominating currency using a 10^x + offset system (essentially rational numbers). Fun to see the limits really explored. As some will recall, our prototype blind sigs denomination system dealt with the problem of receiving dust amounts by introducing a sliding window such that all Tx inputs and outputs must be within a given range by exponent. This allowed for smaller units to come into common usage over time as the real value of the money increases but without any fixed limits, such as bitcoin’s hard-coded dust limit.

For ringct, we have private amounts and are constrained to a u64 by the bulletproofs, so the above is useless. fun memories though.

[jlpell]

@danda

so the above is useless

Which part is useless? Can you clarify?

[danda]

the entire denomination system is unnecessary and not used in the current RingCT impl. because the purpose of it (in blind sigs impl) was to hide each individual DBC amount among others of the same denomination – like nickels in a cash register. But with ringCT, the amount is entirely hidden, so there is no need for such schemes. A single DBC (aka utxo) can have a totally unique (thus identifying) amount and it doesn’t matter because no one knows it except sender and receiver.

[jlpell]

@davidrusu

We tried lots of tricks to enforce the in == out check, but we either lost unlinkablity, or the results was unnecessarily complex (i.e. we had explored an option where we tried to combine RingCT with Blind Signatures, but… RingCT works just fine on it’s own!)

Did you and @danda ever consider a “money-centric” perspective for DBCs rather than a “wallet-centric” perspective?

The following is an oversimplification but what I mean by this is that for a wallet-centric approach, the wallet addresses are specified and unknown balances of money flow through them. In the money-centric approach, the money units themselves have known addresses with known amounts but hidden/unknown owners flow through them.

This perspective may significantly simplify auditability since the money units are unchanging, and move with section splits. The total amount of money allowed in a section can be determined from the section prefix and is reduced by half on each section split (2^32 / 2, 2^32 / 4, etc). Thus anyone at any time can count up the known money units in the current section to make sure it equals the amount that should be in the section.

These perspectives on money flow are analogous to Lagrangian formulations vs. Eulerian formulations in computational fluid mechanics. The same underlying objective phenomena are described, but one representation is preferred or less error prone depending on the computing paradigm and class of physical phenomena under investigation. In this case, wallet-centric is the Eulerian analog, and money-centric is the Lagrangian.