DBCs - Crypto with the convenience of cash.
I was not aware of that as an issue or possible issue without DBC. Thank you.
Pure speculation on my part! So please don’t take my word for it.
Why is this being worked on before a test net?
The thing I can’t see how is done is the offline double spend protection. In essence, as far as I’ve seen, spendable crypto balances are conceptually mappable to a ‘right to direct funds from’ account, whether it’s like a 1) custom dedicated account (e.g. btc paper wallet, original cascasius coins, etc.) or 2) like a cashier’s check (pre-allocated balance). Either is trivial to achieve with SAFE, and 1) is trivial with any other crypto. What is hard is to guarantee is that if you accept either variant, what’s to stop the person who sold it to you from simply copying the relevant permissions and emptying before you can make use of it. Depending on the time limit it maps to (t=0 -> a regular crypto transaction, to t=mucho -> you’re relying completely on a third party).
My thoughts are too limited to square this circle, but if you need internet access to exchange them and SAFE is instant and private, then DBCs add nothing… put another way, if SAFE is private and no history is kept, then SAFE is a DBC without the offline quality.
A semi solution (e.g. not full offline exchangeable) would be something like the phone credit receipt model, where a retailer (or any balance holder) could transfer to a key and print out a token/signature. If you trusted the retailer, e.g. 7-11 or the person who sold you the 7-11 phone credit receipt, then you could get a digital token, and then any SAFE client with access to the information could immediately upload to the network… not unlike bitcoin ATMs that print a paper wallet… you trust it as long as it takes to plug in and sweep.
Would love to hear thoughts on this topic.
I guess, thinking further after @dirvine 's post, that another evolution of it could be as a network-held account with a re-keyable private key…
So, you could have a piece of paper with an address to a server … you could scan it, go to the page on your phone, put in your new password, and have the last owner put in theirs… then the balance would be yours to pass on or to redeem…
- Don’t need an account to use it/transfer it. Essentially making a wallet out of any password manager.
- Even if SAFE privacy is breached, not traceable to anything until redemption, e.g. like lightning network on top of SAFE (with however a need to be online to switch keys)
- Damn close to bearer cash in a world with smartphones
- Suceptable to key loss ( use a password manager)
- Phishing attacks, e.g. a website that looked exactly like an official transfer site
- SAFE cash app? e.g. done with an official app that connects to the safe network, no account and can present the key switch interface…
This could have legs…
It would settle via AT2 I would reckon so one wins and one loses, there is no double spend. I would guess it’s whoever runs is back online first if it’s offline.
Good point. I know the physical bitcoins that came with a balance had a “tamper proof” sticker that hid the private key so maybe a similar solution. Let’s try and think of ideas on how this could be achieved.
This reminds me, I think I remember Jim mentioning having Safe Network gift cards with preloaded balances, maybe a scratch off to a priv key QR or something or url to a preloaded wallet/account etc. like where you find preloaded cards and gift cards in a convenience store. AFAIK this could be done either way but maybe not anonymously without DBC.
This does. We’re just limited by our imaginations. I really like your pro and con list!
I love this. If you or anyone else has others keep them coming!
I found this section interesting as Safe utilizes Asynchronous Trustworthy Transfers (AT2).
“ We went from trusted, to verifiable, to possibly trustless. The word I am missing in that enumeration is “trustworthy”. So far, we have failed to build systems that are worthy of our trust. When we have trustless however, do we really need trustworthy anymore? My view is that building trustless systems is very limiting from perspectives on complexity, economics, privacy and adaptability. Trustless systems are necessarily huge, needing many persons to cooperate according to the same protocol. This makes them vulnerable to error of specification and a changing environment. They are also inherently expensive to operate and likely will never be as fast and cheap a DBC systems. Let alone that they are likely never going to achieve the same strength of privacy - anonymity and untraceability - then blind DBC systems can reach.”
In this section I wonder if there could be a network DBC token standard and “swaps” could be done easily by the network with little overhead? I’m just imagining platform tokens, physical assets being tokenized, wrapped coins from outside of Safe and every asset would be universally swappable!
“Multi-currency Mints and advanced ownership
DBC systems are flexible and easily extended to support further use cases. While the ownership feature described above is powerful, it can be adapted for more complex protocols. An example for that is the experimental extension developed for eCache.
Instead of simply recording the public key for transaction signatures, the hash of a “contract” was recorded in the DBC. A contract is a boolean expression describing the conditions under which a DBC will be reissued.
Furthermore the contract can apply to more than a single DBC transaction. eCache supported “combined” transactions in which two or more DBC transactions could be presented to the mint at the same time, the conditions of each of the input DBCs referring to the output DBC templates of the other transaction. This allows creating schemes that allow swapping the ownership of two certificates presented by two different users.
For example, a DBC issued for the denomination “gold” for owner A and another for the denomination “EURO” for owner B can be simultaneously processed if and only if the respective output DBCs would be “gold” for owner B and EURO for owner A. This essentially implements a swap or sales.
To facilitate processes like these eCache in addition implemented an “Issue Book” which cached newly issued DBCs created in combined transactions. It allowed anybody knowing the output DBC template to retrieve the signature for it. That way a user could pre-sign a transaction, give it to another user for combining it with his transaction and sending it to the mint, and then ask the Mint for the signature to be able to recreate the result of the transaction.”
Imo, its important to keep it simple. The basic DBC should just be viewed as a physical safe coin that has been emitted from the network into the real.
So how do we prevent the double spend off-network? (Imo a sticker hiding the private key isn’t good enough.)
The combination of ownership and publicly verifiable mint signatures allows for transactions in which the recipient can do a check against double-spends without having to communicate with the mint. The recipient only has to keep record of the DBCs sent to it that have a specific owner. If a DBC is presented twice a double spend is detected, if the DBC is unique and carries a valid signature by the mint the recipient can be sure that the DBC will be accepted by the mint for reissue at a later point in time. Since DBCs can include two owners that are exclusive to each other and cover two defined time spans, it is also possible to pre-generate DBCs to be used in an offline manner at a later point in time. The user simply generates DBCs for the intended recipient that after a certain time fall back to be reissue-able by the user’s key. This allows transactions between two parties in which both can be offline for a defined, possibly very long, time span without needing to interact with the mint. This makes the system very usable for scenarios of mobile point of sales transactions and simple hardware implementations, such as in the case of payment cards, public transport tickets, etc. Furthermore it makes the system much less vulnerable against denial of service attacks. To clarify: There are only two cases which require one of the transaction parties to talk to the mint during the transaction: The recipient is unknown, or the payment amount is unknown. In all other cases the transaction can be structured so that no communication with the mint is required during the transaction.
To me this kind of reads like you have to know the recipient but I thought that DBC doesn’t require accounts. Also when we speak of double spend, I don’t believe there is any issue with double spending in the system itself but maybe what we are referring to is someone handing off a DBC offline saying it holds value and the recipient possibly being duped before redemption as the details or keys of the DBC were recorded and the value already swept. Is that what we’re talking about here @jlpell? You have any ideas? When I have more time soon I plan on seeing if there are any previously used solutions.
We already have “working” examples in the current banking system that rely on a central authority. The first is coin/cash, the second is a cheque. A model similar to these by analogy that replaces the central authority with a network section might be a winner.
When you go to an ATM (bank-o-mat) you sometimes request that your electronic funds are converted to physical funds (cash) that you use to pay for your morning cup of coffee. This DBC circulates freely in the economy until someone at a later date wants to deposit the physical funds back into “the bank network”. This return to the bank is possible because of the various anti-counterfitting measures built in to the physical coins/cash proves that no double spending has occured. The same physical cash/coin is intended to circulate and be used for many transactions.
Physical cheques can be written at will by buyers of goods/services and are redeemed by sellers at a bank. If a malicious person double spends on their account there are consequences. First the counterparty is harmed because they rendered services to the double spender which now need to be recovered. Often this is where escrow services come in to minimize risk with untrusted parties. A single cheque is only good for a single transaction.
Both of these methods have pros/cons for serving as a model for an analogous SAFE DBC. Personally I do like the idea of physical/trusted objects that are durable and reusable with physical double spend anti-counterfit protection built in (but more than just a sticker). However the cheque issuance model is probably easier to implement since the physical object can be a plain piece of paper. It is also easier to secure since the network is involved for every transaction.
My intuition tells me there is a third approach with the benefits of both and none of their shortcomings. Need to think on it a bit more though…
Safe Network is already totally anonymous. Almost everyone carries around their smartphone with them. If a transfer is done on a smartphone through SAFE Network, it is anonymous and just like cash. There are also paper wallets as well. Why do we need anything else? I’m afraid that fooling around with side projects will delay the Network.
Because it isn’t totally anonymous yet, it doesn’t exist. Nor is it secure etc. There’s a design being implemented which we’ll be able to test and try to break during tests.
DBC, if feasible gets us more confidence in the level of secure anonymity the network can achieve, and as a bonus will makes for a more efficient solution (less work for sections, more done by the clients), and the added functionality of offline transactions.
Given this is being explored without distracting any developers from getting the testnets up and running, I don’t understand why some folks are concerned about it. We’ve known MaidSafe wanted to look at DBCs as a potentially better solution for some time, and IMO it’s great that they are so close to the testnets that they have the spare capacity to do this.
More in this topic:
So if SAFE Network is not totally anonymous, how will you create a DBC that is better than the underlying Network that supports it? Why not just put those same resources into making SAFE Network more anonymous instead?
They aren’t separate as noted, and even if they were it’s no good having something underneath that’s anonymous if what you build on it isn’t. They have to work together.
I still trust you but I don’t understand why you have to build this new DBC feature and how you think it will not take critical resources. Can’t someone else build it later?
I feel like you are moving the goalposts of the originational specifications.
I trust you guys and this is all OK. But be ready for a big uphill battle if you want to market this to the general public.
Maybe the functionality will be so fantastic that anyone who uses it will see right away why this is so great.
DBC’s in itself isn’t a feature that the general public needs to know about, the implementation of DBC’s will help the network and Safecoin to do the things it should do better if I’m correct.