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
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…
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
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?
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.
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.
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.
Why can’t they? A mutable datatype is typically not addressed by it’s hash. Regardless, it all comes down to how permissions are handled by the network.
The object doesn’t go anywhere, it is a fixed xor address on the network. Once permission is granted to the new owner by the old owner, and permission revoked for the old owner by the old owner, then the old owner is essentially locked out from doing anything. The double spend attempt might be to trick the CRDT from not converging or delayed convergence by issuing many different permission changes simultaneously. The whole point of a BFT-CRDT is that it is guaranteed to eventually converge, no? The payee just needs to wait for N replicants of the CRDT to converge. At that point the transaction has cleared, and no one has access to the xor-address except for the new owner.
Out of curiosity, how would this system switch to new cryptography primitives? A Blockchain can “fork” and enforce new rules for everyone. If I understand this correctly, transactions live in a DAG (somewhat similar to nano?) With no central record to enforce changes.
I’m asking because post quantum cryptography is an active area of research, and even though practical quantum computers are still a ways off, transactions last forever and the transaction graph could be discovered at some point in the future.
Current development is “Fleming” after that is “Maxwell” and post Maxwell is beta. Working out how the network upgrades is the main part of Maxwell and I think they have a few things to figure out in regards to that, but it’s not on the burner right now.
That sounds a bit dubious to me. Post quantum cryptography is still being looked into. There area few NIST candidates coming up, but I’m not sure cryptography experts have come to any consensus yet.
To be clear. The data encryption uses several steps and is symmetric (AES, chunking, plus an xor step) and is quantum-proof. The signature schemes though are asymmetric (ed25519and BLS) and these are not quantum-proof.
