|Previous||Table of Contents||Next|
This protocol assumes that the merchant cannot change the identity string once Alice writes it on the money order. The money order might have a series of little squares, which the merchant would require Alice to fill in with either Xs or Os. The money order might be made out of paper that tears if erased.
Since the interaction between the merchant and the bank takes place after Alice spends the money, the merchant could be stuck with a bad money order. Practical implementations of this protocol might require Alice to wait near the cash register during the merchant-bank interaction, much the same way as credit-card purchases are handled today.
Alice could also frame the merchant. She could spend a copy of the money order a second time, giving the same identity string in step (7). Unless the merchant keeps a database of money orders it already received, he would be fooled. The next protocol eliminates that problem.
If it turns out that the person who bought the money order tried to cheat the merchant, the bank would want to know who that person was. To do that requires moving away from a physical analogy and into the world of cryptography.
The technique of secret splitting can be used to hide Alices name in the digital money order.
Amount Uniqueness String: X Identity Strings: I1 = (I1L,I1R) I2 = (I2L,I2R) .... In = (InL, InR)
This is quite an amazing protocol, so lets look at it from various angles.
Can Alice cheat? Her digital money order is nothing more than a string of bits, so she can copy it. Spending it the first time wont be a problem; shell just complete the protocol and everything will go smoothly. The merchant will give her a random n-bit selector string in step (7) and Alice will open either the left half or right half of each Ii in step (8). In step (10), the bank will record all of this data, as well as the money orders uniqueness string.
When she tries to use the same digital money order a second time, the merchant (either the same merchant or a different merchant) will give her a different random selector string in step (7). Alice must comply in step (8); not doing so will immediately alert the merchant that something is suspicious. Now, when the merchant brings the money order to the bank in step (10), the bank would immediately notice that a money order with the same uniqueness string was already deposited. The bank then compares the opened halves of the identity strings. The odds that the two random selector strings are the same is 1 in 2n; it isnt likely to happen before the next ice age. Now, the bank finds a pair with one half opened the first time and the other half opened the second time. It XORs the two halves together, and out pops Alices name. The bank knows who tried to spend the money order twice.
Note that this protocol doesnt keep Alice from trying to cheat; it detects her cheating with almost certainty. Alice cant prevent her identity from being revealed if she cheats. She cant change either the uniqueness string or any of the identity strings, because then the banks signature will no longer be valid. The merchant will immediately notice that in step (6).
Alice could try to sneak a bad money order past the bank, one on which the identity strings dont reveal her name; or better yet, one whose identity strings reveal someone elses name. The odds of her getting this ruse past the bank in step (3) are 1 in n . These arent impossible odds, but if you make the penalty severe enough, Alice wont try it. Or, you could increase the number of redundant money orders that Alice makes in step (1).
Can the merchant cheat? His chances are even worse. He cant deposit the money order twice; the bank will notice the repeated use of the selector string. He cant fake blaming Alice; only she can open any of the identity strings.
|Previous||Table of Contents||Next|