@oetyng can speak for himself, I don;t want to tread on toes, but this DBC work will be in the public API as it’s a simple who to pay (re-issue) in the background. So you will get a set of encrypted blobs from a re-issue and these blobs are a DBC for the recipient. You can send these as a single blob encrypted to that recipient or probably reed Solomon distribute parts to his elders (more complex and assumes elders don’t change, which they do).
A problem with DBC is a recipient can say, you never sent me the cash. However there is a solution to this, a commitment hash. so you store the hash of a payment to X, if he spends X he will have his payment spend stored at hash of that DBC. If the commitment hash you stored matches the spent hash then you can prove paymetn was made, just nobody can see how much!
There are a few tricks we can do here, but anonymous cash should be anonymous and that does have a price. Commitments though help a lot.
I think I’m following you now… but maybe not. So do you mean that the balance is stored in the client’s account as private data and kept safe by network redundancy and ownership creds just like other files, chunks, and blobs?
Man you are lucky. When I explain the same things to the people I know, they still don’t understand it. Either you are better at explaining these things, or you have smarter friends.
I’ve tried to explain Bitcoin a little bit to an old retired fisherman, whom I consider a friend, but he is skeptical. People here have never trusted banks and such authorities. That’s just tradition. They have always made their own vodka and hidden their weapons, regardless of what different governments have said throughout the centuries. It’s hard to explain virtual currency to a person who has hardly even seen a computer in his life. But the man is intelligent. He had never heard about prime numbers, but I think he understood when I told him about them, and that numbers can have special qualities that can be significant for other things beside tallying fish, trees or bank notes. The fact that he even bothers to listen to a city boy like me makes me proud.
Yes or offline totally. This with the moves to make data consistent with crdt type functions means the actual network has less authority over our data. It’s more limited to store only and not mutate.
So AT2 + DBC means you have a bunch of digital certificates like bearer bonds. You can get these signed over to another id (this is the re-issue) where the mint/bank signs the reissue blinded. SO think more bearer bonds than just cash really. You can store these encrypted blobs wherever you want, but there is a god network that will do it for you.
That analogy and the DBC moniker is another potential quagmire for US citizens and possibly Europe too. If I understand you correctly then imo it is far better to think, say, do “next generation crypto currency with online storage, online transaction, offline storage, offline transaction, and network restart protections based on AT2 + Blind Signature Technology.”
Same as @Secretariat415, I think that this DBC stuff is a waste of time simply because cash like transfers cannot be implemented in off-line mode: Nothing prevents the sender to grab the money before the receiver connects to the network.
If it is acknowledged that the receiver needs to be connected to be sure to receive the fund, then there is no need to develop anything because this is already implemented with SafeKeys:
The sender gives the receiver the secret key of a SafeKey having the agreed amount
The receiver connects to the network and creates his own SafeKey preloaded with this amount (minus the cost of the new key) and paid by the sender secret key: safe keys create --preload <amount> --pay-with <sender secret key>. This a cli command but it can be more user friendly with an app on a smartphone that scans a qr code representing the sender secret key.
The end result is that the sender cannot take back any money because the first SafeKey is now empty and the secret key of the second SafeKey is only known by the receiver.
In turn, the receiver can send it to another user. The denomination can remain the same if users accept to cover the small cost of a SafeKey creation. This way it would be similar to a bank note circulating among users.
The only drawback is that the receiving user must be connected at the time of the transaction or trust the sender to not use the balance before he connects. But it can’t be otherwise, so no need to develop something complex that won’t do any better.
If I understood correctly, DBCs improve privacy since not even the receiver knows where the coins are coming from, but I see problematic the inability to show the amount paid in the proof of payment, it could be a major hurdle for safecoin based commerce.
I could be mistaken, since my knowledge im the topic is limited.
Think I saw an idea like this mentioned though I’m unsure if it’s feasible. If a receipt was necessary the payment could fall back to pure AT2 but then I’m guessing it would only be applicable to an online payment. Other options would likely be, anonymous online transfer via DBC, anonymous offline transfers via DBC. @dirvine@oetyng is this possible? I could see the need for receipts as well. Choice is freedom
The issue is where were those funds? They were in a network stored balance controlled by Elders. The elders need to agree the payment and as now they credit the receiver’s balance.
I think so, mainly splitting off the holding of “coins” “tokens” “dbcs” really.
The fact you are seeing this though shows how close both systems are. In terms of code,
it’s simpler with DBC (as the network has much less to do). This is why we reckon it’s a worthwhile venture to test that out.
Yes, receipts for anonymous cash are a weird one (we want our cake and eat it ) However I think proof a DBC was spent is possible, it actually needs to be stored on the network as spent (the hash of the DBC). The sender could keep a copy of that DBC and if necessary unblind it (exposing him and the identities of the receivers in doing so). Unblinding means show the DBC that hashed to that spent token.
Now there’s a thing, what if you as a receiver (or sender) never wanted somebody to expose you?
Is it safe to say that these new concepts regain some of the properties that were classic Safe coin which we all loved before section balances and wallet balances arrived? Where one, many, or partial coin denominations exist as unique digital objects (data blobs)?
Will DBC allow the option to choose where the SAFEcoin is stored, either in the network or offline? I’m thinking about it like an ATM, I can see uses for both withdrawing as well as storing in the network and transacting within it.
Well we aren’t exactly there(multi-section) yet, but the underlying logic that we are building completely takes multi-section into account. Our upcoming incorporation of tech/features like AT2, DBC & CRDT all function under the basis/context of a multi-section network. So for the moment, it may physically seem to be a single-section network, the intuition behind is that almost every part of the network that is working/in the works supports multi-section. And when we make the switch from a single-section to multi-section network, we’d have already made a head start by doing the above^ with minimal work to convert.
