How we might market a DBC’s (Digital Bearer Certificate) Unique/Cash-like features

No wallet needed. So a Dbc has a parent Dbc hash in it. You can check the parent hash is in the spent book (it’s been split and this Dbc is a child). You check this Dbc is not in spentbook and bobs yer uncle.

So no blockchain and no transaction history. Transactions don’t really exist. Dbcs are not stored on the network. Only the hash of spent ones are.

Ownerless Dbc (cash) have no notion of belonging. Like cash, the holder owns it. The network does not need to know the owner, just to check it’s valid and re-min or re-issue it.

Now we might ask, if it’s cash can the network not just keep it or issue to themselves, but no. As it’s given for re-issue the Elders note the inputs and output (hashes) and sign it. No Elder itself can sign it over (it’s threshold sigs). So the client gathers the sigs and completes the transaction by handing back the network signed SpentToken. That’s stored and we are good.

This is where we mixed AT2 and Dbc together to provide a mechanism that gives us atomic transactions.

Note though a transaction is per Dbc NOT per wallet. So you can have a million Dbc’s and spend them concurrently.

So take the speed of AT2 with the hassle of spend one at a time plus the benefits of Dbc with the problem of atomic re-issue and add to spend book at the same time and we have a neat system.

i.e. Take the benefit of AT2 and throw away the bad bits (one at a time transaction plus distributed ledger - i.e. traceable) plus the benefits of Dbc (untraceable) and concurrent and throw away the bad bits (atomic re-issue)

22 Likes