Re: e$: e-cash underwriting

At 12:57 PM 8/28/94 -0700, Hal wrote:
>hughes@ah.com (Eric Hughes) writes:

>>One solution is clear and direct: charge for each redemption attempt.
>>In that situation, multiple attempts get rejected, and the issuer is
>>recompensed for the attempt.  No morality need be invoked.
>
>The problem is, the fraud doesn't occur (typically) when the note is
>redeemed at the bank, it occurs when the note is exchanged at the
>market.  Is this proposing to charge the merchant when he in good faith
>turns in the cash which was given to him by the customer, and it turns
>out bad?  What cruel irony!  Here he is already cheated once, and the
>bank will charge him an extra fee as additional punishment?
>
>I must be misunderstanding.  This seems not to deter double-spenders at
>all.

The more I think about this, Eric, the more I think I caved in too early.
Can you explain exactly how charging a back-end load on a digital cash
certificate prevents double-spending?

>>There remains an issue as to the size of this redemption fee, which
>>would have to be small.  In order to optimize the transaction costs of
>>charging this fee, a bank might be willing to accept identity in
>>escrow for the transaction and to remove the fee for good
>>transactions.  Identity might be a pseudonym revealed after 10 bad
>>attempts, say.  This system removes the requirement for identity and
>>substitutes it for an economic optimization based on identity.

This reminds me of the previous discussion of holding a person's cash bond
hostage for good behavior.  In this case, you're holding unencumbered
redemption rights hostage and reducing transaction costs in relation to the
person's relative risk. I think I get it now. I sort of took it on faith
before, but I'm not so sure all this is necessary, see below.

>Here I am lost completely.  Whose identity is in escrow?  The person to
>whom the coin is given in the first place?  But I thought we were
>referring to a double-spending protocol in which users revealed their
>identity to the bank.  Apparently not?  Is the idea here that the bank
>doesn't know the user's identity, but some other escrow holder does, and
>it gets revealed only if the user double-spends 10 times?  But that would
>still be identity-based, just with different rules about when it gets
>exposed.  I really don't follow this at all.

I think that the business model I've been proposing may handle this a bit.
In order for someone to cash out, they need to be able to speak to an ATM
machine, which implies a bank-acceptable identity (whatever that means).
It allows for nyms to trade offline, and it banks on being able to catch
the nym by police work (Ace Ventura, Nym Detective!) if a
"self-credentialed" nym double spends. Since most fraud schemes require a
nym to do it, web-of-trust stuff would have to apply in the case of
transactions with nyms. It's ugly, but it should work.

>
>To me, there is no problem with revealing identity in certain situations
>as long as it is unlinkable to my other activities..  And I will be much
>more willing to lend credit or other forms of trust to pseudonyms if I
>know that they are willing to pay the ultimate price of punishment to
>their own very physical bodies if they cheat me.  What more assurance
>could I want?  And yet, as long as all parties are honest, we have no
>fear of our identities being revealed against our will.

I'm pretty sure I'm a little more loosey goosey about this. I think that
there may be enough of an enforcement mechanism even if nyms remain
completely anonymous.

Cheers,
Robert Hettinga

-----------------
Robert Hettinga  (rah@shipwright.com) "There is no difference between someone
Shipwright Development Corporation     who eats too little and sees Heaven and
44 Farquhar Street                       someone who drinks too much and sees
Boston, MA 02331 USA                       snakes." -- Bertrand Russell
(617) 323-7923

Can you explain exactly how charging a back-end load on a digital cash
   certificate prevents double-spending?

In an online system, double spending gets immediately rejected, so the
only loss incurred by the bank is the cost of a database query.  So
the bank gets reimbursed for the cost of that query.  From the point
of view of the double spender, they pay something in order to get
nothing, although perhaps they can convince someone else to pay that
little something for them.  In either case there is no direct benefit
to a double spender, and there is a waste of time incurred.

Now, in an offline system, this doesn't work the same way, because
presumably goods or services are rendered before payment clears.
Remember differential time lags, and Herstadt risk--same issue,
different context.  So the fairly simple solution of charging for a
deposit attempt doesn't work.  (Regardless that the end of my previous
message said that it might.)

Chalk one up to the efficiency of online transactions.  A simple
product change, with very low impact, can entirely eliminate to
participate in an identity regime.

Of course, if you've got your heart set on offline...  Have I
mentioned how much more computation and communication those systems
require by all parties?

Eric