How does Open Transactions solve the double spend problem?

Question

OT is based on digital cash. From the article:

To tackle the double spending problem, the payee has to verify the coin with the bank at the point of sale in each of the transactions. This verification of the legitimacy of the coin requires extra bandwidth and is a potential bottleneck of the system especially when the traffic is high. The real time verification also means there is a need for the synchronization between bank servers.

This is not clear to me. Does the bank know who owns each coin? What exactly does the bank verify? If I try to send the same coin to both Alice and Bob, where exactly would this fail? What knowledge do any of the parties (Alice, Bob, the Bank) gain during this transaction?

Answer 1

When I withdraw 10 clams, my client software generates a random ID: lkjsdfoiu

It then chooses a random blinding factor, which it keeps secret.

It then blinds the random ID using the blinding factor along with the server's 10-clam public minting key, producing (say): 897345jh

This random, and now blinded, ID is then sent to the OT server along with my withdrawal request.

Once the server verifies that it has successfully withdrawn 10 clams from my account, it uses its 10-clam private minting key to sign the blinded ID: 897345jh SIGNED: Server.

The server returns this to me. My client unblinds it using its secret blinding factor along with the server's 10-clam public minting key: lkjsdfoiu SIGNED: Server.

When you ask, "Ah-ha-ha, but how can the server's signature still verify, when the ID has changed from 897345jh back to lkjsdfoiu again?" (since it was unblinded) ==> The answer is, that is the whole point of blind signatures. They still work, even after they are unblinded. That is the whole magic of digital cash. (I encourage you to Google "homomorphic encryption" to learn more about the applications for this concept.)

At this point: 1. My client now has a random ID with a valid server signature on it. 2. The server has no idea what that ID is, since the ID was blinded when it was signed. 3. Therefore I and I alone am the only person who knows that ID. 4. When I give the token to Bob who redeems it at the server, the server can see that the token is good (since it has a valid signature.) The server also knows that it's worth 10 clams, since only the 10-clam public key can verify that signature. But the server has no idea where it came from.

Once the server redeems the token for Bob, it records the token's ID (lkjsdfoiu) in a spent token database. This way, if the token is ever redeemed twice, the server can see that it is no good, because it has already been used.

OT expires and rotates cash tokens and mints, in order to allow the server operator to erase its spent token database every few months. Otherwise, the server operator would be forced to store a growing database forever, which is not feasible for a server operator.

Answer 2

My favorite part of OT is how the decentralized architecture(*) prevents double-spends, even when the OTServer itself (i.e., the bank) isn't trusted. The way this works is that clients don't connect directly to the OTServer, but rather use a public Distributed Hash Table (DHT) (such as Freenet or Tahoe-LAFS) as a middle layer. This means any attempt at a double-spend would be detected, evidence would be preserved, and the OT server could be held accountable.

Let's suppose Debbie Doublespend has 1 "clam" (an arbitrary OT currency token) on DebServer, an OT Server that colludes with her. Her goal is to fraudulently purchase two T-Shirts (worth 1 "clam" each), one from Alice, and one from Bob. Since there's only 1 "clam", DebServer has to trick both victims into thinking they received the same coin. So, the server signs two conflicting transactions, "D->A" and "D->B."

Without the DHT layer, Alice connects directly to DebServer and sees "D->A" while Bob connects to DebServer and sees "D->B". They both ship T-Shirts, so Debbie's plan succeeds. Eventually Alice and Bob go to spend their "clams", but clearly one of them will be unable to do so. The server would likely feign network problems or "play dead" rather than admit it double-spent. Unless Bob and Alice get in contact with each other and combine their receipts, they'd have a difficult time proving the server cheated.

With the public DHT in place, the two conflicting transactions would be preserved and propagated. Signed copies of "D->A" and "D->B" are prima-facie evidence of DebServer's involvement in a double-spend. Alice and Bob shouldn't trust an OTServer unless A) it has something to lose (i.e., an insurance policy against double-spends) and B) they use a DHT layer so receipts/evidence are preserved.

(*) this diagram is from vouchersafe, which has the same architecture as OT

Answer 3

newsflash: OpenTransactions doesn't have a double spend problem, thus there is nothing to solve.

'double spend' is a problem for P2P decentralized systems not client server systems. Open Transactions is a client-server system.

Guys: look around you. Do you see any serious adults gathered here? That's because FellowTraveller is a joke. It seems as though in his response above he is actually taking credit for Chaumian e-cash? Not only did he not invent it, he didn't even implement it. https://github.com/benlaurie/lucre

"One of the core challenges of designing a digital currency involves something called the double-spending problem. If a digital dollar is just information, free from the corporeal strictures of paper and metal, what's to prevent people from copying and pasting it as easily as a chunk of text, "spending" it as many times as they want? The conventional answer involved using a central clearing house to keep a real-time ledger of all transactions. The ledger prevents fraud, but it also requires a trusted third party to administer it."

Open Transactions adheres to this traditional 'central clearing house' model. To say that Open Transactions solved the problem of double spending is just absurd. It's like saying an automobile has 'solved' the problem airplanes have of getting off the ground. Much of these misconceptions are due entirely to FellowTravellers 'creative' use of language, complete absence of any legitimate peer review of his claims, and total lack of any actual users.

http://www.wired.co.uk/magazine/archive/2012/01/features/the-rise-and-fall-of-bitcoin

so one could say that Open Transactions is neither:

1) community generated

2) 'just works'

3) makes sense