On Tue, Apr 09, 2002 at 06:17:06PM +0200, Anonymous wrote: > Adam Back wrote: > > [...] You could if you wished, rather than putting identity in the > > coin, put an anonymous escrow account number in the coin. [...] > > If they double spend they are not identified but their escrow > > account is frozen. > > Two problems with this escrow idea. First, as noted before, there is no > limit on how much can be double-spent in a short time, hence the escrow > account can't cover it.
Indeed. > And second, because the deposit is unlinkable to the withdrawal, there is > no way for the bank to know when it can safely release the escrow amount > back to the withdrawer. How long is the bank going to hold onto those > escrowed funds? A week? A month? I suppose the bank would have to hold onto the funds until the coins issued using that account as guarantee expired. Normally coins anyway expire to allow the bank to put a cap on the size of it's double-spend database. This makes ecash inconvenient for long-term off-line value storage, even if they are denominated in for example Intel stock or something. Software would automate the process of exchanging old epoch coins for current epoch coins -- for example Pr0duct Cipher's magic money works like this. One approach I think might be interesting for value storage is to offer longer validity periods for high value tokens. Small change can expire more quickly, as you're typically spending that so it's less of an inconvenience. > And how many people are going to want to use a bank which makes them > set aside an equal amount of every withdrawal for some extended > period? That is absolutely impossible given how most people and > businesses manage their cash flow. Aside from the problem with limit you identify, I think generally the precedent is already set by the non-electronic world: to engage in transactions which typically require reputation and identity for contract violation enforcement anonymously, you have to pony up cash up-front. (eg. my secured credit card example which I can only presume is because they worry that an untrusted foreigner will run up the card and leave). > > With Brands off-line coins you _can_ anonymously exchange off-line > > coins at the bank if you choose to set it up that way. > > > > Technically how this works is using an attribute hiding refreshing > > protocol which issues a new fresh coin with the same attributes > > (identity, denomination) as the previous spent coin while revealing > > only some negotiated sub-set of the attributes of the old coin (in > > this case denomination), so the new coin is unlinkable for the bank > > and yet the bank is assured that it will contain the same identity > > that was certified originally so the bank will be able to recover the > > identity if it is later double spent. There is a description of this > > protocol in section 5 of [3]. This works for off-line coins. For > > transferable off-line coins you need additionally to update the > > 0-value last holder coin to match the value of the coin being > > exchanged, using the updating protocol (see section 5.2.1 in [2], or > > probably [1] may have some discussion). > > Are you saying that if Alice pays Bob, he can anonymously exchange the > coins and end up with new fresh coins with ALICE's identity in them? > That's great, he can double spend all he wants and she ends up going > to the pokey. No thanks. No that is prevented. The user (the person who most recently received the cash which now looks like [A_v-coin B_0-coin ... F_0-coin] where v-coin is the original coin with value withdrawn unlinkably from the bank by Alice, then Alice spends to Bob by binding to a 0-value coin with Bob's identity in it, and Bob spends to Charlie... until Fred gets the coin, and Fred decides to exchange it for a fresh coin from the Bank, only Fred would prefer not to show this transaction in his account, and doesn't want to identify himself to the bank again either. So when Fred wants to exchange this coin for a fresh coin he first has to convince the bank that he knows that coins private key by answering a challenge. Then the bank uses the refreshing protocol to issue a new coin which shares attributes with the F_0-coin it is being exchanged for. Fred's identity is in the new coin, however the bank doesn't learn Fred's identity, though it is just assured that it is the same identity as that encoded in the F_0-coin. But if this is all we did it would not be useful because the new coin would also have a 0-value as it's undisclosed attributes are cloned from F_0-coin. So in combination the bank must use the updating protocol to change the value from 0 to the value v from the A_v-coin. Note also the refreshing protocol could be used to get a batch of fresh 0-value coins so the user would not need to identify himself beyond whatever identity were leaked by his communication link to the bank. A correction on something I said earlier about Chaum double-blinding: | (There is the double blind Chaum variant, but it is even less | convenient as both the payer and payee have to be online at what | becomes a simultaneous withdrawl, spend and deposit time.) This is innacurate, it is actually a simultaneous withdrawal and spend, followed by an arbitrarily later spend by the payee as the payee knows the payer does not see the coin due to the extra blinding. It's still less convenient of course because the payer and payee have to be simultaneously and interatively online, where as normally with online Chaum, and with off-line and off-line transferable protocols the payer may for example send a payment via email. Off-line and off-line transferable also allow more anonymity for payer where the payee also wishes to be anonymous. Adam
