Getting ecash without an MTB account

Suppose I want to give ecash to somebody who don't have an account with
Mark Twain Bank, and I want the receiver of the coins to know that the
coins are genuine.

I would have two accounts at MTB, one for savings and one for transactions.
I want to give away a million bucks, so I deposit that amount in the
transactions account. Then I give the account password to the receiver, he
withdraws the money, and I change the password so he can't get any more
money from me. I trust the receiver not to change my password, but if he
does change it, then I can simply ask MTB to change it back, explaining
that I lost my password.

Would this work?


Mike.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremey Barrett wrote:
>BTW, there are better solutions to operating without a mint account,
>but they are not widely available yet.

Are you referring to the receiver anonymous protocol?

This is how I understand that protocol,

Alice wants to receive e$1 from Bob. She creates a random number, blinds
it, and gives the blinded number to Bob. He shows the number to the
Mint, asking for a withdrawal of e$1 with a signature on this coin
number. Bob gives the signed and still blinded coin to Alice. She
unblinds it and spends it, end of story.

I thought that in this scenario, Bob can spend the coin before he gives
it to Alice, so she runs the risk of receiving a coin that has already
been spent. Is it impossible to spend a blinded coin if you can't
unblind it? Or are you thinking of something totally different?

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBM/Rda8Uc8bdD9cnfEQI0wgCfQJb5KR0P+F0zfRqD+r0v98tKHrYAn2gF
rmIGdBzCyeZnzIjuVVa+hQGy
=gXCF
-----END PGP SIGNATURE-----


Mike.

On Fri, 15 Aug 1997, Mike wrote:

> Jeremey Barrett wrote:
> >BTW, there are better solutions to operating without a mint account,
> >but they are not widely available yet.
> 
> Are you referring to the receiver anonymous protocol?
> 
> This is how I understand that protocol,
> 
> Alice wants to receive e$1 from Bob. She creates a random number, blinds
> it, and gives the blinded number to Bob. He shows the number to the
> Mint, asking for a withdrawal of e$1 with a signature on this coin
> number. Bob gives the signed and still blinded coin to Alice. She
> unblinds it and spends it, end of story.

Actually the coin is intercepted and spent by Mallet.  Alice gets pissed
at Bob because she feels cheated by him.  She implements a blinding
protocol on him with an ice pick, as described by Dr. Thomas Dolby.
("Blinded with Ice Picks and/or Science")

> I thought that in this scenario, Bob can spend the coin before he gives
> it to Alice, so she runs the risk of receiving a coin that has already
> been spent. Is it impossible to spend a blinded coin if you can't
> unblind it? Or are you thinking of something totally different?

My understanding of the protocol is that the identity of the purchacer is
revealed only if the coin is double spent.  What prevents the person
wanting to find out the identity of Bob from just spending the cash more
than once?

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.

At 03:15 PM 8/15/97 -0400, Mark M. wrote:
>There are two ways of handling the double spending problem.  One is online
>clearing where the bank keeps a database of all deposited coins.  
.....
>The other protocol is very complex and involves an interactive protocol
>to reveal one half of the payer's identity which is split using a simple
>XOR.  When a coin is double spent using this protocol, the payer's identity
>is revealed.  I don't know if this protocol can be used for double-blinded
>coins, but even if it could, there wouldn't be many advantages over
>online clearing.

The advantage is that it doesn't need to be online, and being online
is sometimes inconvenient, and sometimes increases your transaction costs.
For some applications, such as wallets, being online means trusting the
telecom facilities provided by the person you're exchanging money with,
which also requires more protocol support.

There is another approach, which is the observer stuff from Stefan Brands,
or whatever he's working on these days, using some sort of "trusted" 
processing component in the wallet to prevent double-spending.


#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#   (If this is a mailing list or news, please Cc: me on replies.  Thanks.)

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 15 Aug 1997, Alan wrote:

> > I thought that in this scenario, Bob can spend the coin before he gives
> > it to Alice, so she runs the risk of receiving a coin that has already
> > been spent. Is it impossible to spend a blinded coin if you can't
> > unblind it? Or are you thinking of something totally different?
> 
> My understanding of the protocol is that the identity of the purchacer is
> revealed only if the coin is double spent.  What prevents the person
> wanting to find out the identity of Bob from just spending the cash more
> than once?

There are two ways of handling the double spending problem.  One is online
clearing where the bank keeps a database of all deposited coins.  The
merchant immediately deposits the coin and the bank compares it to a
database of all spent coins.  If the coin has already been spent, the bank
sends an error message to the merchant, and presumably, the transaction
is halted.  If the coin has not been spent, the bank adds the coin to its
database of spent coins and credits the merchant's account.  This simply
prevents double spending and does not attempt to identify the person
responsible.

The other protocol is very complex and involves an interactive protocol
to reveal one half of the payer's identity which is split using a simple
XOR.  When a coin is double spent using this protocol, the payer's identity
is revealed.  I don't know if this protocol can be used for double-blinded
coins, but even if it could, there wouldn't be many advantages over
online clearing.




Mark
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBM/SqvyzIPc7jvyFpAQHvnAf+I0M5S/SIurUtHVtnuGha/k/AjhkCocJJ
iRxXti3Gqn5ifs05NU9VvR7G0eNTuPBMHfvFveR5uanc222iOKZzCpgJKSqxPHU2
MvcK6e76q67NGHf3ypadZsqAU7GAcT6DGWWt8chq7FKtzAZg9Nv1VIyof2Mw68dw
R9UiQEh7NX6YvvJa7I9tcALbCvJUEvhMPV6WEu7lKCKTNchdSdEOth5EZrgvvQAZ
bx3pqa+yPhzRn2AJ62HmhMxqEtDfKWyIfB7lvmXJ6a1P/BzMfo+ZELa1qlmd6X+u
C0+qzBqEtvxgxWmFm5CwKD02dRv/KuxNIIE/83Z216lTT8WTnoG9JA==
=GrB9
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

At 09:26 AM 8/11/97 +0200, Mike wrote:
>
>I would have two accounts at MTB, one for savings and one for transactions.
>I want to give away a million bucks, so I deposit that amount in the
>transactions account. Then I give the account password to the receiver, he
>withdraws the money, and I change the password so he can't get any more
>money from me. I trust the receiver not to change my password, but if he
>does change it, then I can simply ask MTB to change it back, explaining
>that I lost my password.
>
>Would this work?
>

Should work just dandy, with this note: You must destroy your wallet
on disk for the transactions account and recreate after every
"transfer" is complete. This is because the sequence numbers on mint 
messages will not match and the MTB client will complain about it and 
reject the messages. However, you can re-create your wallet with
no problems at all. 

(Note to Digicash developers, if you're reading, please allow any
sequence number greater than or equal to the expected value in future
wallets. There is a really obscure and damned difficult attack that
can be mounted against this, but the alternative is a non-portable
wallet. Not being able to have an arbitrary number of wallets for 
the same account is mucho annoying).

BTW, there are better solutions to operating without a mint account,
but they are not widely available yet.

Regards,
Jeremey.



-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBM+7IYS/fy+vkqMxNAQHKHQP/WMtgWY5rswZjpNRvk56f0LY/DVe078xC
09Z8DG1dmIZbBCWlTqO5fujZlH83B2S7covw8K3YtVeCF74IlOI5TeOEVVgVZHnp
0/iLafMjEWQBy8/PHxy6IOJeWy0LX2kgJozWTztu6AlcCGvRJx3gRUK14UxMz1mJ
HY3wiupNPfg=
=Laum
-----END PGP SIGNATURE-----

--
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64