[118412] in Cypherpunks
Re: Sander & Ta-Shma's ecash is revocable
daemon@ATHENA.MIT.EDU (Anonymous)
Sun Sep 26 23:06:20 1999
Date: Mon, 27 Sep 1999 04:43:27 +0200 (CEST)
Message-Id: <199909270243.EAA28375@mail.replay.com>
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net, dbs@philodox.com
Reply-To: Anonymous <nobody@replay.com>
Adam Back writes:
> 1. A spends coin:
> 2. B deposits coin (note in the paper the depositor must identify
> himself to the bank)
> 3. A revokes coin
This is not actually the blackmailing scenario considered by Sander and
Ta-Shma, at least not in their Crypto 99 presentation. Their scenario
was:
1. A withdraws coin from the bank
2. Bank revokes coin
3. A tries to spend coin
In that scenario, if step 3 happens before step 2, there is nothing that
can be done. Adam is correct with regard to his scenario that after A
spends the coin and B deposits it, A can recognize the deposit transcript.
He is also right that this can be fixed by having B immediately withdraw
and deposit a new coin. That step brings us back to the second scenario
above, which cannot be traced.
> Therefore I think their claim that the protocol is resistant to the
> blackmail attack is incorrect. Also my earlier claim that it is
> revocable is wrong, if you use this 2 step deposit protocol. And,
> with 2 step deposit it is again a final settlement; the blackmailer
> doesn't release the hostage until the 2nd step has completed.
Yes, this point was brought up informally with the authors, but they
suggested that in the case of massive amounts of blackmail, it would
be suspicious for some two-bit hood to suddenly show up with a million
dollars. The preference on the criminal's part is to keep the money
and spend it gradually over a long period of time, and this cannot be
done if the money will be invalidated soon. Hence the blackmail is
harder to do successfully.
> > No, once the coin is deposited there is no way to invalidate it after
> > the fact. The ZK proof was only offered in the context of the list as it
> > was at that moment, and there is no way to say, "the list has changed,
> > let's go back and see which ZK proof transcripts are now invalid".
>
> If the ZKP is non-interactive, the force of the proof against the
> state of the list it was issued against remains in perpetuity. Yes?
The verification procedure would conceptually take the ZKP transcript
and the coin list as it was when the transcript was issued, and produce
"accept" or "reject". So in that sense, yes, the proof remains valid
forever. But if you input a different list than the one used when the
proof was created, the verification will no longer work (in general).
Once the list changes you can no longer go back and see which if any of
the ZK proofs would work with this different list; generally, none of
them will.
