[fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

On 10/20/05, Daniel A. Nagy <nagydani at epointsystem.org> wrote:
> On Thu, Oct 20, 2005 at 03:36:54PM -0700, cyphrpunk wrote:
> > As far as the issue of receipts in Chaumian ecash, there have been a
> > couple of approaches discussed.
> >
> > The simplest goes like this. If Alice will pay Bob, Bob supplies Alice
> > with a blinded proto-coin, along with a signed statement, "I will
> > perform service X if Alice supplies me with a mint signature on this
> > value Y". Alice pays to get the blinded proto-coin Y signed by the
> > mint. Now she can give it to Bob and show the signature on Y in the
> > future to prove that she upheld her end.
>
> I like this one, though there might be a problem if Alice does everything,
> except giving Bob the signed version of Y in the end. I can imagine scenarios
> where this might be a problem.
>
> However, it can be relatively easily solved if the mint publishes every
> signed proto-coin (instead of being handed to the payer, it goes to the
> public records, from where the payer can retrieve it). There's no reason not
> to.

Good idea! Even without this, if there is a problem then everything
will come out in the dispute resolution phase, where Alice will be
forced to reveal the mint's signature. Bob may claim at that time
never to have seen it before, while Alice may claim that she had sent
it earlier, but once they get this far both sides will be forced to
agree that Bob has now been paid so the contract can be completed. So
this method would be OK for contracts where timeliness is not an
important issue. But your idea of having the mint publish its
signatures could help even more.


> > A slightly more complicated one starts again with Bob supplying Alice
> > with a blinded proto-coin, which Alice signs. Now she and Bob do a
> > simultaneous exchange of secrets protocol to exchange their two
> > signatures. This can be done for example using the commitment scheme
> > of Damgard from Eurocrypt 93. Bob gets the signature necessary to
> > create his coin, and Alice gets the signed receipt (or even better,
> > perhaps Bob's signature could even constitute the service Alice is
> > buying).
>
> This one requires additional infrastructure which needs to be rolled out,
> which is expensive. Simultaneous exchange of secrets is an elegant
> cryptographic feat, but the required tools are not available to the general
> public right now and the motivation to obtain them are insufficient. Thus, a
> system relying on this cannot be phased in cheaply.

I'm not sure what costs you see here. There are two main technologies
I am familiar with for signature (or general secret) exchange. One is
purely local and involves bit by bit release of the signatures. Both
parties first commit to their signatures and use ZK proofs to show
that the committed values are in fact signatures over the required
data. They then release their sigs a bit at a time, taking turns. If
one party aborts prematurely he has at most a factor of 2 advantage
over the other in a brute force search to find the missing bits of the
signature. While this takes many rounds, it is still pretty fast. Of
course the users don't manually initiate each round, it all happens
automatically under control of the software. I saw some code to
implement this a couple of years ago somewhere on Sourceforge. It
actually exchanged PGP signatures, of all things. It does not take any
new infrastructure.

The other technology is so-called "optimistic" exchange, where the
signatures are provably encrypted to the public key of a trusted third
party. The two parties each exchange such encryptions and prove they
are valid. Then they exchange the actual signatures in the
straighforward manner. If one party does not send his sig, the other
can go to the TTP and get it. Since this option exists, there is no
incentive for the parties not to complete the transaction and hence
the TTP will in practice almost never be used. This one does require
the TTP to exist and his public key to be available, but that should
be no more new infrastructure than is required for the cash issuer and
his key to be distributed. In fact the issuer could be the TTP for
dispute resolution if desired.

> The desirability of a payment vehicle depends on the assortment of goods and
> services available for it. Now, the lack of non-reversibility might be
> either a show-stopper or a significant additional cost in the case of some
> goods and services, while receipts are required in the case of others.
>
> Both might be required for transactions in the $100 ... $1000 range between
> a power-seller and one-time buyers in a low-trust environment. From the
> seller's point of view, the risk of a reversal might not be acceptable
> (basically, he cannot assess the probability of it, while the cost is
> substantial), because the value is too high, so he needs irreversibility.
> From the buyer's point of view, the risk of losing the money is not
> catastrophic, but highly undesirable; he wants to be able to name-and-shame
> the fraud. This would provide the seller with enough incentives to deliver
> and enough security to go ahead with the deal.
>
> The "legal system" in this case is just provable reputation-tracking, which
> in case of non-performance deprives the seller of future custom.

Yes, that's a good example. A reputation system could be enhanced by
provability of payment, although unless there is also provability of
performance (i.e. providing whatever was paid for) there is still a
he-said-she-said issue. Presently, reputation systems like eBay rely
on the idea that if someone cheats, they probably cheat a lot, so
there will be many complaints against them. Your technology would
eliminate some forms of false complaints, namely those where someone
did not pay but claimed that they did pay and demanded the goods. That
is such an audacious fraud that I question how often it happens, but
eliminating it would indeed have some value.

CP

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com