On 10/20/05, Daniel A. Nagy <[EMAIL PROTECTED]> 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