Is there any serious discussion about using blinding intermediaries in digital currency scenarios?

Question

A digital currency system like Lucre (OpenTransaction) creates a coin by a mint blind signing the output of a hash function, which the payer then unblinds and pairs with the input to the has function.

In this way, the coins themselves cannot be used to identify the payer; however, the payee and the mint are free to correlate their information about the payer's identity through side channel information, such as IP address and rebuild the payer's identity. There are afaik two orthogonal partial solutions to this problem :

1. The payer may reduce side channel information, say by using Tor, not giving one party a real name, etc. This potentially offers good security, but imposes a great burden upon the payer.

2. The protocol and payer may instead insist upon an intermediary between the payee and the mint, i.e. the payer blinds the coin using his intermediary's daily public key, the payee blinds the coin using the mint's key, and the intermediary unblinds the coin before delivering it to the mint. This prevents the mint form ever reestablishing that the payer held that particular coin.

I could imagine a few uses for #2 but I haven't seen much discussion about it. Is it interesting?

Answer 1

It may be an interesting avenue to explore. I've read the highlight reel of the digital cash literature but I do not know it well enough to know how well these issues have been addressed.

A few things to consider for #2:

1. In a quick read of Lucre, it seems that the payee does no verification before passing the coin onto the mint. It seems, if the mint has a known public key, that the process may be improved if the payee can do some basic verification (is it actually signed?) before asking the mint if it has been double spent. Your solution #2 would make any payee verification difficult since it is working with a blinded value.

2. As I understand it, the payee submits the coin for verification but does not consider the transaction complete until they hear back from the mint that the coin is valid. For this reason, the verification must be realtime. This creates a timing attack problem (the same basic one that exists in all proxy systems including Tor) where a corrupt payee sends the coin at time $t_0$ and the corrupt mint receives the coin from the intermediary at $t_0 + \Delta t$. If $\Delta t$ is small and not many transactions happen within the window, the mint and payee can still trace the coin through the intermediary. In particular, the payee could adjust when they send the coin if it would help the attack. There are countermeasures in the Tor and mix network literature on this.

3. The #2 attack is made worst if there are more than one intermediary and users choose whichever they trust. The payee knows which intermediary the blinded coin is sent to and the mint knows which one it has received a coin from, so this information reduces the anonymity set of the possible origins of a given coin. It is now the set of coins per intermediary sent within a small window of time, and this is more likely to be a singleton set. Perhaps there is an alternate architecture where the user sends the coin to the intermediary instead of the payee, however be mindful of the next consideration.

4. Since the mint and payee are no longer directly communicating with each other, they can not mutually authenticate. How does the mint establish who the payee is? The mint has to credit the amount to the payee. It seems the user would have to sign a transaction saying to credit the coin to the payee, and only the user can do this because this singed transaction itself would also have to be blinded (alongside the coin). In this case, it seems the payee can be cut out of the first part of the protocol. The user sends the coin and transaction through the intermediary to the mint, the mint verifies everything and then credits the payee, then the mint informs the payee the amount that has been credited, and the payee releases the purchased goods to the user.

Anyways, the fact that there are maybe a few challenges with using an intermediary actually makes the question more interesting, rather than less interesting. It is no longer a simple clean-cut solution; it requires some thought and would make a better contribution if you could iron out all the issues.