At 10:37 PM -0800 3/2/00, dmolnar wrote:
>On 3 Mar 2000, Secret Squirrel wrote:
>
>> If all payments are for different amounts, then this would no longer
>> work, as a chain of $123.45 payments would be easy to track. It would
>> therefore be necessary for the system to use a single standard payment
>> size. If people wanted to pay more, they would send multiple messages.
>> If these can be spread out over a period of time, it should be possible
>> to hide who has paid whom.
>
>Note that cash payments can have a property which encrypted messages
>usually do not : you can have the mix break up the payment into
>random-sized chunks, or aggregate several payments into a single
>transaction between servers.
Indeed. The financial chunking is different. (And therein lies some
additional security, as "testing" (pinging) can easily be done. More on
this in a moment.)
But before we get too excited about "payment mixes," not that anyone should
be discouraged from implementing them!, payment mixes are essentially
identical to moneychanging. And moneychanging is essentially identical to
simply treating digital money as just another thing to be bought and sold.
A la Goldberg, if Alice has payer untraceability with Bob, and pays 100
digidollars to Bob to "buy" 100 other digidollars, Bob's payer
untraceability with Alice means that the resultant cash is essentially
mutually untraceable.
(Sure, the delivery has to be untraceability. As always, if Alice and Bob
are using mundane e-mail mechanisms then any supposed untracebility of the
money is ipso fact lost.)
If this "using digidollars to buy digidollars" moneychanging example seems
contrived, recast it in terms of _change_. Alice spends 100 digidollars
with Bob for a 1 digidollar item. Bob uses the very same payer-untraceable
features to send Alice 99 digidollars untraceable to him.
More generally, digidollars can circulate as cash. Not the "same"
digidollars, for mathematical/blinding reasons, but as the same "promise to
pay."
(Which is all digital money really is. Comparable to a warehouse receipt on
marks, francs, dollars, gold, silver, whatever.)
...
>That example may not be so great, but I wonder if we can get anything from
>this kind of dynamic recombination.
It's worth studying. But bear in mind that the latency of current or
near-term remailers (not counting Freedom) makes online clearing (of these
bearer instruments) a bear, bearishly speaking.
(Forgive me...I had a Hettinga moment.)
>
>It seems that doing this requires some kind of trust in each server.
>More specifically, we would trust each server to combine payments
>correctly and split them correctly. We would have to enforce this trust
>via some kind of audit protocol, such as public posting of encrypted
>receipts. Maybe this overhead would eat up any possible gain; it's not
>yet clear to me one way or the other.
Trust in remailers is a whole topic.
At one level, one can send messages to oneself, to at least establish a
crude measure of confidence. Time-consuming, and correlatable to later
activities. (Doncha think the snoopers would see the correlation between
someone using a remailer in test mode for the first time and a "real"
message (threat to President, for example) just a few minutes later? Those
who use remailers usually send test messages to themselves.)
At another level, ratings serviices. Raph Levien used to run one, circa
1993-96. It reported latencies (delays), dropped messages, encryption and
other polices at the site, etc. Very useful. Both in terms of helping users
decide which remailers to use in a chain and in terms of motivating
remailers to be more reliable.
However, I have not seen nor heard of this remailer stats report in a long,
long time. As with so many other things involving the Net, Raph presumably
moved on to other projects and nobody took over.
Ideally there would be many such rating services, some free, some charging.
Just like bank ratings, credit ratings, etc. Someday.
Another approach is to construct much more sophisticated remailer routing
systems to provide frequent pings of remailers. No reason, for example, why
thousands of users cannot test a subset of the remailers _themselves_, via
scripts which run daily or hourly. They could share the results, or just
use their own results. Even more sophisticated "packet switching routers,"
to borrow a phrase, could be developed.
Remailers are really in their infancy. After a flurry of developments in
the 1992-5 period, stagnation has set in.
Commercial remailers are of course the real answer. We've known this for
many years. See the archives for literally hundreds of articles on
pay-per-use remailers, etc.
No digital money system is going to work until better obfuscation of
Internet connections is available (e.g., commercial-grade remailers,
perhaps Freedom). All the math in the world about Alice and Bob and
blinding and all is meaningless if Bob knows the relevant TCP/IP stuff
about Alice.
>
>> Current remailer networks are not very reliable.
>
>That's an understatement. :-(
They are currently so flaky and so ill-reported on that they are
essentially useful only for "casual-grade remailing." I attribute this to
the lack of commercialization.
>
>> A system like this
>> would obviously increase the temptation for remailer operators to receive
>> payment for some messages but not pass them on.
>
>fair exchange problem or something weaker? can we build a protocol which
>commits to a payment when the remailer operator gets a message, then
>follows through when the message is passed on?
There are ways to ping the system. Cf. discussions about how one tests
whether a digital bank has defrauded its customers.
(The neo-Chaumian, neo-Brandsian method is to establish elaborate tracking
logs which the issuers are perhaps mandated to reveal, etc. The "market"
solution is trivial: walk into a digital bank, figuratively speaking, buy
100 digidollars, which are untraceable to the buyer of course, and then
"test" the bank by redeeming one or N of them. The bank cannot know whom to
"burn." Sort of like a drug purchaser testing coke by picking a packet at
random and checking it. This can be formalized as a cut-and-choose
protocol, but the basic idea is that the very untraceability of digital
money makes many testing options easy to construct.)
>
>> Remailers could profit
>> by cheating. Chaum proposed making remailers publish logs of the messages
>> they had handled, such that it would be possible to see that each remailer
>> sent all the messages it received, and the next remailer in the chain
>> received all the messages it was sent. This would reveal the source of
>> any problems, narrowing it down to the interface between two remailers,
>> which should allow for a fix.
This is what I meant by the neo-Chaumian, statist approach. Market
solutions to "bad actors" (those who don't pass on messages, those who
don't redeem cash properly) are much more robust and scalable. (This is
fundamental economics, and the fact that Chaum and others are attempting to
do in the core protocol what is better handled by standard things like
reputations, credit ratings, etc. is...scary. Perhaps this is an obvious
reason Digicash foundered.)
Enough comments from me for now.
--Tim May
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May | Crypto Anarchy: encryption, digital money,
ComSec 3DES: 831-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets,
"Cyphernomicon" | black markets, collapse of governments.
