From: Hal <hfinney@shell.portal.com>
Date: Wed, 21 Dec 94 08:10:40 PST
To: cypherpunks@toad.com
Subject: Re: No privacy with DigiCash
In-Reply-To: <199412210316.WAA00684@orchard.medford.ma.us>
Message-ID: <199412211609.IAA11143@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


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

Bill Sommerfeld writes, quoting me:
>> Is there something I am overlooking, some way to buy things
>> privately with DigiCash?

>Yes... at least one TCP/IP proxy system (socks) lets the client
>receive incoming connections (the client makes a second connection to
>the socks server, and the socks server informs it of the addr/port
>that it's listening on; when a connection comes in to that port, the
>two incoming connections are gatewayed to each other); that's how
>socksified FTP works, by the way.

I read about socks last night, and while it has some nice features I
don't know if it is suitable for a process which you want to have
persist and be able to accept connections on an ongoing basis.  With
socks, the ecash process would tell the socks server to open a listening
socket on its behalf.  Then when a connection comes in from a merchant,
it gets forwarded to the ecash process.

This is the problem: the socks server probably cannot generally get
the same port number as the ecash process.  I don't know if it even
tries.  So you have to note the port number.  Well, you have to do this
already because the ecash process may not get the port number it wants if
somebody else already has it.  But, with socks you only get one incoming
connection and then the socks server closes.  The ecash process would
have to request another listening socket each time it got a connection.
And each of those could have a different port number.  So this would be a
constantly changing bit of information that you would have to keep in
mind.

If the ecash process were integrated with the web client, this would not
be so bad, as the new port number could be supplied to the merchant
server automatically.  But with the current implementation this would
have to be done manually.

I was thinking of a socks-like model where you could have persistent
servers running behind a socks firewall.  The socks implementation is
really designed for ftp transfers, where the ftp server has to make a
connection back to the ftp client, and these are pretty transient.  For a
persistent server you would need a more complex structure.  Probably
there should be a persistent connection between your process and the
socks server, separate from a listening socket that your process sets up.
When a new connection comes in to the socks server for your machine, it
does a connection of its own to your listening socket.  Then there could
be multiple connections to your server active at one time.  The
persistent connection would just be a "lifeline" so that if your server
exited then the socks server would know to close down the proxy socket it
holds for you.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLvhTBRnMLJtOy9MBAQHSCAH8DEC7mPaFDNSRQ6bV5TMs75pRrYd6M7x5
4xlVpVq/K3jKm76wAhJVZou6Vx6lGCHwwwYb3kU0CeE33SkPyzHJrA==
=ILoI
-----END PGP SIGNATURE-----