From: iagoldbe@calum.csclub.uwaterloo.ca (Ian Goldberg)
Date: Thu, 23 Nov 1995 10:23:39 +0800
To: cypherpunks@toad.com
Subject: Re: ecash protocol: Part 1
In-Reply-To: <199511212146.NAA11456@cory.EECS.Berkeley.EDU>
Message-ID: <490jct$11k@calum.csclub.uwaterloo.ca>
MIME-Version: 1.0
Content-Type: text/plain


In article <199511230103.RAA15911@jobe.shell.portal.com>,
Hal  <hfinney@shell.portal.com> wrote:
>Ian Goldberg <iang@cory.EECS.Berkeley.EDU> writes:
>
>>Last week, I was taking a look at the ecash protocol (no, I don't have a copy;
>>I have a binary, which I can't even run...).  
>
>>I've managed to decipher a useful bit of the first message sent from
>>the shop to the payer.  It's the Payment Request, and contains the following
>>information:
>
>>o Header identifying packet as Payment Request
>>o The integer 4
>>o The payment amount, in cents
>>o The time (seconds since 1970)
>>o The integer 79
>>o The name of the shop (payee)
>>o A description of the item being paid for
>>o An empty string
>>o The integer 0
>>o End of Record marker
>
>That's very interesting work!  What are the string formats, are they null
>terminated or Pascal-style with a preceding count byte?  How did you
>identify "an empty string", wouldn't that just be a byte of 0?  How did
>you know it was an empty string rather than just a 0.

See below.

>Did you get this by inducing a shop to send a payment request message to
>some program you wrote which was listening on the ecash port?

Yup.  I just had a program sitting on the ecash port that hexdumped
anything fed to it.  That, and a copy of the binary to read...

>I wonder if it would be legal to write shop software which sent such a
>payment request, took the resulting coins, and deposited them in the bank
>(if we could figure out all the protocols necessary).  This particular
>sequence of operations would not appear to infringe anybody's patents -
>there are no blinding operations involved.  It's not clear how useful
>such a program would be but at least it would be one step away from the
>DigiCash monopoly.

 From what I gathered from Doug's posts a little while back, the _client_
stuff is perfectly fine; only the _bank_ stuff is Chaum-patented.

Here are the messy byte-details:

The data encoding:
---
Header:  2 bytes

0xa0 0x80+type

where type is:

0x12: Payment Request
0x0a: Payment
0x29: Length of Message
0x13: Dummy Message
(there are others)
---
EOR: 1 byte

0xa1

End of Record indicator
---
n-byte Integer:

0x90 0x80+n followed by n bytes of data, MSB first

n should probably be 1 <= n <= 4.
---
Date: 4 bytes

0x91 0x84 followed by 4 bytes of time since 1970
---
String:

0x92 0x80+(length) followed by (length) bytes
---
Data:

0x94 0x80+(length) followed by (length) bytes
---
There are other types, like 0x93 (Multi-precision integer) that I
haven't decoded yet.

=====

The first message from the shop:

a0b9 9083 0000 37a1                         # ......7.

a092 9081 0490 810a 9184 30ad 1930 9081     # ..........0..0..
4f92 8c65 7368 6f70 4063 322e 6f72 6792     # O..eshop@c2.org.
9063 6769 2d62 696e 2f64 6f72 656d 6169     # .cgi-bin/doremai
6c92 8090 8100 a1                           # l......

What it means:

a0b9: Header (Message length)
9083 000037: integer = 0x37 (length of following message)
a1: EOR

a092: Header (Payment Request)
9081 04: integer = 4
9081 0a: integer = 10 (cost in cents)
9184 30ad1930: time
9081 4f: integer = 79
928c "eshop@c2.org" : string (payee)
9290 "cgi-bin/doremail" : string (description)
9280 : empty string
9081 00: integer = 0
a1: EOR

   - Ian