<p>My favorite part of OT is how the <a href="http://agoristradio.com/wp-content/uploads/2011/05/tiki-download_file.php_.jpeg" rel="nofollow">decentralized architecture</a>(*) 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 <a href="http://en.wikipedia.org/wiki/Distributed_hash_table" rel="nofollow">Distributed Hash Table (DHT)</a> (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.</p>

<p>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."</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2017-03-10T23:33:04.883Z
Just wanted to comment on double spending. This is not necessarily true as it depends on various factors that may affect consistency. For example, one of the goals of bitcoin's consensus approach is to fend off race condition attacks, which is not something a DHT is meant so solve on its own; depending on network size and distribution, finality will always be a problem. Lastly, I am not deeply familiar with open transactions, but transaction malleability will always be a problem when there is some value to gain; thus another problem that must be handled.
Just another day
CC BY-SA 3.0
2012-02-01T18:31:34.877Z
2012-02-01T18:31:34.877Z
Andrew Miller
<p>newsflash: <strong>OpenTransactions doesn't have a double spend problem, thus there is nothing to solve.</strong></p>

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

<p>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. <a href="https://github.com/benlaurie/lucre" rel="nofollow">https://github.com/benlaurie/lucre</a></p>

<blockquote>
  <p>"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."</p>
</blockquote>

<p>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.</p>

<p><a href="http://www.wired.co.uk/magazine/archive/2012/01/features/the-rise-and-fall-of-bitcoin" rel="nofollow">http://www.wired.co.uk/magazine/archive/2012/01/features/the-rise-and-fall-of-bitcoin</a></p>

<p>so one could say that Open Transactions is neither:</p>

<p>1) community generated</p>

<p>2) 'just works'</p>

<p>3) makes sense</p>

CC BY-SA 3.0
2013-06-09T23:10:33.243Z
2013-06-10T15:42:14.573Z
2013-06-10T15:42:14.573Z
user5443
<p>When I withdraw 10 clams, my client software generates a random ID:  lkjsdfoiu</p>

<p>It then chooses a random blinding factor, which it keeps secret.</p>

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

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

<p>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.</p>

<p>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.</p>

<p>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.)</p>

<p>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 <em>I</em> and <em>I alone</em> 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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-01-28T17:28:42.250Z
If I am the only one who has withdrawn a 10-clam token in some time frame, can the server use this fact to determine that I am the one who paid Bob?
Meni Rosenfeld
CC BY-SA 3.0
2012-01-29T04:44:53.230Z
Let's say the mint expires every 6 months. If you are the only one to withdraw a 10-clam token in 6 months, then the server will know that 10 clam token came from you. Not because it has any way to link the IDs, but simply because you are logically the only person who could have withdrawn it.
Fellow Traveler
CC BY-SA 3.0
2012-02-02T00:50:22.937Z
There is technically no need for any accounts at all. As long as the server can verify its signature on your cash token, then the server can exchange it for a fresh one. And at that point, no one else has a copy of that cash but you, and it will be untraceable when it is spent. If a server runs in "cash-only" mode, then the token exchanges of the total user base become an anonymizing mix, in addition to the untraceability of the cash itself. (I2P is an essential layer, as are timing considerations, etc.)
Fellow Traveler
CC BY-SA 3.0
2012-01-28T09:49:09.267Z
2012-02-02T00:38:41.313Z
2012-02-02T00:38:41.313Z
Fellow Traveler
<p><a href="https://github.com/FellowTraveler/Open-Transactions/wiki">OT</a> is based on <a href="http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html">digital cash</a>. From the article:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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?</p>

CC BY-SA 3.0
2012-01-28T08:54:08.020Z
How long before we need a OT.stackexchange.com ? (not that I don't want to see and learn more about OT.)
Stephen Gornick
CC BY-SA 3.0
2012-01-28T19:44:43.420Z
@StephenGornick - Yeah, I know. See http://meta.bitcoin.stackexchange.com/questions/236/is-open-transactions-on-topic
ripper234
<doublespend><open-transactions>
How does Open Transactions solve the double spend problem?
ripper234
# How does Open Transactions solve the double spend problem?

(Asked by: username_0 on 2012-01-27)

[OT](https://github.com/username_5/Open-Transactions/wiki) is based on [digital cash](http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html). 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?

**Tags:** doublespend, open-transactions

> **Comments:**
> **username_1**: How long before we need a OT.stackexchange.com ? (not that I don't want to see and learn more about OT.)  
> **username_0**: @username_1 - Yeah, I know. See http://meta.bitcoin.stackexchange.com/questions/236/is-open-transactions-on-topic  

---

## 3 answers

### Answer by username_5 on 2012-01-28. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_6**: If I am the only one who has withdrawn a 10-clam token in some time frame, can the server use this fact to determine that I am the one who paid Bob?  
> **username_5**: Let's say the mint expires every 6 months. If you are the only one to withdraw a 10-clam token in 6 months, then the server will know that 10 clam token came from you. Not because it has any way to link the IDs, but simply because you are logically the only person who could have withdrawn it.  
> **username_5**: There is technically no need for any accounts at all. As long as the server can verify its signature on your cash token, then the server can exchange it for a fresh one. And at that point, no one else has a copy of that cash but you, and it will be untraceable when it is spent. If a server runs in "cash-only" mode, then the token exchanges of the total user base become an anonymizing mix, in addition to the untraceability of the cash itself. (I2P is an essential layer, as are timing considerations, etc.)  

---

### Answer by username_2 on 2012-02-01. Score: 4

My favorite part of OT is how the [decentralized architecture](http://agoristradio.com/wp-content/uploads/2011/05/tiki-download_file.php_.jpeg)(\*) 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)](http://en.wikipedia.org/wiki/Distributed_hash_table) (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

> **Comments:**
> **username_3**: username_3 wanted to comment on double spending. This is not necessarily true as it depends on various factors that may affect consistency. For example, one of the goals of bitcoin's consensus approach is to fend off race condition attacks, which is not something a DHT is meant so solve on its own; depending on network size and distribution, finality will always be a problem. Lastly, I am not deeply familiar with open transactions, but transaction malleability will always be a problem when there is some value to gain; thus another problem that must be handled.  

---

### Answer by username_4 on 2013-06-09. Score: -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
> username_3 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 username_3 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) 'username_3 works'

3) makes sense


---

