Re: Anonymous digital cash, on top of bitcoin

"Goss, Brian C., M.D." <Goss.Brian@mayo.edu> writes:

> I'm a little uncertain how this setup is different from Chaum's
> Digicash of 20-30 years ago, aside from using Bitcoin as the backing
> rather than traditional currency.

Not much different. Bitcoin just makes it a lot less bureaucratic to get
started. And I think bitcoin may also help with building a decentralized
system, with several interoperating but mutually untrusting banks.

> I also don't understand why, in your
> system, banks don't need to know any "real names of their users."
> Banks always require knowing the names of their users (at least in the
> US); and even true Swiss professional banker - customer
> confidentiality is a thing of the past.

I mean that there's no technical/economic reason they need names.
Regulation is a different matter.

> What didn't work well about Chaumian digicash (specifically, his
> second version that disclosed identity upon a double spend) was that
> digicash was like toilet paper (single use only) and no better than a
> check (it can bounce and all you have is an identity to collect from).

Except in the system I envision, you don't even get any "real" identity.
You identify the bank account, and the bank can seize any money in that
account, do discourage double spending. And you could have a bank policy
that you have to deposit at least x bitcoins at the bank when you create
an account.

But sure, if you have received digital cash, and have not yet deposited
it, you're running the risk that deposit will be refused. I imagine that
if you sell things with a real per-unit cost, you should make sure to do
a batch of depositing received coins before shipping the goods. While if
you don't have a per-unit cost (say, you're essentially accepting
donations/tips, or selling mp3 files, whatever), you can do the deposit
batch job whenever convenient.

There's also the observer extension to Brands' system. In this case,
each user gets a supposedly tamperproof "observer" device from the bank.
To pay, you do a protocol where this device takes some part. And it's
designed so that the device can prevent doublespending from ever
happening, and without getting any further information (even if the bank
collects and analyses all observers later). And the after-the-fact
identification of doublespenders still works, in case a user is able to
break and manipulate the observer device. I'm not sure how realistic
this is realistic, but it helps in the case where you want to accept
payment, *and* deliver the goods, before you can get a chance to connect
to the bank and deposit the received coins.

> 3) Pseudonymous identities, such as you describe here (If I'm reading this correctly), are easy to make by the dozens.

Except it gets costly if you require a deposit at account creation.

> For example, if Merchant Madeline receives 1 unit of
> a hypothetical currency called W3C credits from Buyer Beatrice, and
> Beatrice tries to also use that same 1 credit to pay back Creditor
> Claudia, then Beatrice loses the (variable amount of) excess W3C
> credits backing the 1 credit she issued twice (perhaps each recipient
> could deduct the up to the amount they were owed from these "excess
> backing credits").

The bank could take this from the account deposit. But it's maybe not
discouraging enough in case a user can manage to (1) spend the same coin
not twice, but thousands of times, and (2) really receive something
valuable for a reasonable proportion of those transactions.

> I don't see any way around an/pseud-onymity that doesn't cost the
> Buyer something.

I think it should work to also place some of the risk on the sellers, as
long as that risk can be bounded and managed.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Received on Wednesday, 30 October 2013 13:37:24 UTC