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

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!


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

1 Like

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!)


This might be of interest to you:

“Leaking arbitrary many secrets: any-out-of-many proofs and applications to RingCT protocols.”


I’ll take a look, thanks :+1: . 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.


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.

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.

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.

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.


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:


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.


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.


Which part is useless? Can you clarify?

1 Like

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.


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.


I would say that the ringct system is essentially both (and neither?) of these

Every dbc has a unique keyimage. In your terminology this means the money unit itself has a “known address”.

Also, every dbc has an owner public key (owner address). The publicly visible key is always unique (one-time use). So the “real” owner is hidden.

So it is not so much that DBCs are flowing through a single wallet address or that wallets addresses are flowing through a single DBC. But rather one DBC is being destroyed (marked spent) and another created, and likewise a new wallet address is created for each.

also, just to reiterate the ringct money supply is considered to be auditable. The difficulty is just an engineering/design challenge in terms of doing it efficiently across sections/shards.


I see this as a clever way to handle divisibility (and merging) of unique money units. The minting process allows anyone to “make change” or “cast bars”.

“Ownerless” DBC seem like an ideal method for typical transactions involving common denominations. If you don’t need to “make change”, but only transfer an existing DBC quantity, why not have the transaction bypass the mints and be direct p2p, online or off?


There are no fixed denominations with ringct system, so I’ll disregard that comment.

Ownerless dbc (called “bearer”) are supported by including the secret key with the DBC. So anyone in possession can spend it.

Tx do not involve the spentbook until they are reissued. so you can think of a DBC like a bank cheque. The payer makes the check out to the recipient and hands it to the recipient. The recipient can hold onto it for an arbitrary time period and later go to the bank in order to deposit/exchange it.

So in this very limited sense, the dbc is usable offline.

A “bearer” DBC could be passed around indefinitely offline, however anyone that ever possessed it could spend it, not only the latest recipient. So in practice bearer usage would likely be quite rare, and any wallet receiving one would immediately reissue it for an owned dbc.

caveat: a tamper evident hardware device like opendime that can be passed around is certainly possible.

David Chaum had a patented scheme for true offline DBCs but that required a user’s identity to be known by the central bank, and the ID would be revealed if they ever tried to double-spend, so “the bank” could presumably then go after the double-spending user. It doesn’t seem applicable to what we are doing. The late Hal Finney made a writeup about it here: Hal Finney Essays: Detecting Double-Spending


Thank you for making this more clear.

Yeah, I understand that part. Bank and cheque analogs are fine. The concept I was trying to convey earlier was a little different. I think that if one also pursued some payment methods according to a money-centric paradigm, we’d also get something more like physical coins on the network which simply change ownership p2p. Regardless, all of the recent developments are looking good.


It seems (and I’m probably wrong on many levels), that people could create their own money/tokens on SN by simply creating a xor address with a ledger with particular denominations numbers that point to particular other xor addresses. So xor address 1 = 10 tokens; address2 = 100 tokens … then just create as many as needed. Then people who had keys for those xor addresses could trade the keys. The ledger address can be checked to verify that any particular xor address is valid and is worth ‘x’ tokens.


but how do you trade the keys and prevent double-spends? Say I buy an ebook from you and I pay with the key for A. now you have the key for A and I do also. Now I buy another ebook from Bob and pay using the key for A. I’ve just double-spent…

1 Like

Hmm, well I guess that you would publicly crypto-sign the xor urls belonging to your account and when you trade it the new owner checks to see that you are the LAST one who signed it, then when they take ownership, they immediately sign it.

Of course if you have a slow connection then a double spend is possible. So I suppose this would be a system for at least semi-trusted partners.

to be clear, I’m not advocating such for SN as the SNT, just a possible novel way to create new tokens on SN.

thinking more on this, it seems there would need to be some more fundamental method in the ownership transfer to prevent outright theft. … I did say from the outset that

… probably I’m just a fool wasting people’s time.

Some best practice or standard will need to be engineered for altcoins or tokenization on SN.

Who says the plug-in/oracle idea @AntiFragile had for Elders to run couldn’t also use the DBC code with slight alterations much like people fork blockchains?