Open Transactions 如何解決雙花問題？
為了解決雙重支出問題，收款人必須在每筆交易的銷售點向銀行驗證硬幣。這種對硬幣合法性的驗證需要額外的頻寬，並且是系統的潛在瓶頸，尤其是在流量很高的時候。實時驗證也意味著銀行伺服器之間需要同步。
這對我來說不是很清楚。銀行知道誰擁有每枚硬幣嗎？銀行具體驗證什麼？如果我嘗試向 Alice 和 Bob 發送相同的硬幣，這到底會在哪裡失敗？任何一方（Alice、Bob、銀行）在此交易中獲得了什麼知識？
當我提取10個蛤蜊時，我的客戶端軟體生成一個隨機ID：lkjsdfoiu
然後它會選擇一個隨機致盲因子，並對其保密。
然後，它使用致盲因子以及伺服器的 10-clam 鑄幣公鑰對隨機 ID 進行致盲，生成（例如）：897345jh
然後，這個隨機的、現在被蒙蔽的 ID 與我的提款請求一起被發送到 OT 伺服器。
一旦伺服器驗證它已經成功地從我的帳戶中提取了 10 個蛤蜊，它就會使用它的 10 個蛤蜊私人鑄幣密鑰來簽署盲 ID：897345jh SIGNED:Server。
伺服器將此返回給我。我的客戶使用它的秘密致盲因子以及伺服器的 10-clam 公開鑄幣密鑰來解鎖它：lkjsdfoiu SIGNED: Server.
當你問，“啊哈哈，但是當 ID 又從 897345jh 變回 lkjsdfoiu 時，伺服器的簽名怎麼還能驗證呢？” （因為它是非盲的）==> 答案是，這就是盲簽名的全部意義所在。它們仍然有效，即使在它們被揭盲之後。這就是數字現金的全部魔力。（我鼓勵你Google“同態加密”來了解更多關於這個概念的應用。）
此時： 1. 我的客戶端現在有一個隨機 ID，上面有一個有效的伺服器簽名。2. 伺服器不知道那個 ID 是什麼，因為這個 ID 在簽名時是盲的。3. 因此，只有我和我是唯一知道那個 ID 的人。4. 當我將代幣交給在伺服器兌換它的 Bob 時，伺服器可以看到這個代幣是好的（因為它有一個有效的簽名）。伺服器也知道它值 10 個蛤蜊，因為只有 10 個蛤蜊公鑰可以驗證該簽名。但是伺服器不知道它來自哪裡。
一旦伺服器為 Bob 兌換了令牌，它就會將令牌的 ID (lkjsdfoiu) 記錄在已用過的令牌數據庫中。這樣，如果令牌曾經被贖回兩次，伺服器可以看到它不好，因為它已經被使用過。
OT 到期並輪換現金代幣和鑄幣廠，以允許伺服器運營商每隔幾個月擦除其已用過的代幣數據庫。否則，伺服器操作員將被迫永久儲存不斷增長的數據庫，這對於伺服器操作員來說是不可行的。