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

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

9 Likes

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.

13 Likes

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.

19 Likes

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:

5 Likes

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.

3 Likes

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.

8 Likes

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.

12 Likes

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.

6 Likes

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.

4 Likes

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?

4 Likes

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

7 Likes

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.

7 Likes

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.

2 Likes

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?

3 Likes

Yes, the plugin idea was a good one and I think it’s definitely going to happen as it can enable consensus mechanisms for whatever people want without being a burden on the core network.

3 Likes

You get it Tyler. This is essentially what I was alluding to, but for both alts and SNT. (ie. xor_address3 = 1 SNT, xor_address4 = 0.001 SNT)

I think “trading keys” may be the wrong perspective here.

Yes, something like this, or direct encryption with public key of the payee. Regardless, ownership permissions would change on a mutable data object/chunk with fixed xor address (ie. the owners flow through fixed money objects). It would be based on how chunk/file ownership is managed on the network, or perhaps the data object just gets reencrypted with the public key of the current owner, so that only they have write permissions to the underlying data. To redeem the “coin” back to a normal dbc at a mint, the current owner would need to write some tombstone marker in the data stored at the xor address along with their owner address. A payee would know that the coin hadn’t been tampered with if there is no tombstone marker.

CRDT based money could handle double spends on permission changes, no? Payer sends payment by writing a permission change to the data stored at a fixed xor address, the transaction is confirmed when all N replicants (8?) converge to this update. Payee is then notified of the xor address they now control. The only time you would need to revisit a mint and write the DBC spentbook would be to “cash in” some “coins” for a “cheque” or split/merge the coins into different denominations.

Imo this option looks like the classic Safe Coin first described by dirvine, but with infinite divisibility.
(DivisibleSC == permissionedCRDT + DBCwithRingCT.)

This brings with it a lot of nice properties… simple, familiar to layman, untraceable, unlinkable, as secure as any other data on Safe.

The same process to mint denominated SNT “coins” allows the creation of classic altcoins/tokens, or vice versa. If you spend 1 SNT_dbc for a 10,000 denomination of your alt, there is a minimum par value associated with the alt at 1:10000 SNT/Alt. The alt could increase in value based on its own utility or popularity, but it will never be worth less than the par value. If you do the same thing and spend 1 SNT_DBC to create 1 SNT_CRDT “coin” denomination, then it’s simply a different form of the same thing (like eMAID vs oMAID).

The “coin” version of SNT can then be traded on Safe Network in a p2p fashion (and treated just like a data chunk) ad infinitum without ever needing to interact with mints until the current owner wants to go back to a mint to recover the DBC.

I thought the same thing about myself until you chimed in and showed you naturally understood the whole point I was trying to make. :sweat_smile:

4 Likes

The problem with the idea that I’m stuck on is that the keys to access and write to the original xor url aren’t changing, just a signature stored in the xor url. I’m not sure if they could be changed or not (by the new owner) … otherwise, the old owner can simply sign it again after giving it to someone else … then rinse wash repeat.

I like the idea in principle, but there must be a way for the new owner to change the access keys to lock out the old owner. I’m not sure how safe network handles ownership of xor urls.

It is a relatively simple idea overall though. The devil might be in the details - that’s what I fear to be the case anyway.

3 Likes