Triple Signed Receipts

The idea to use balance agreement combined with transaction numbers in order to enable so-called “destruction of account history” is inspired by Truledger by Bill St Clair. He has mentioned discussions with Patrick Chkeroff of Loom as his muse in this area. (“Destruction” might be better termed: “No longer having an account history, or even really having an account at all, other than the receipt itself on both sides.”)

Mr. St. Clair describes his protocol in this document: Truledger in Plain English.

---

The receipts on Open Transactions also take inspiration from the work of Ian Grigg.

Here is a great article on signed receipts by Ian Grigg himself, with diagrams: Triple Entry Accounting.

Grigg’s work, especially on Ricardian Contracts, is foundational to financial cryptography. (History will show…)

---

What is interesting about Triple-Signed Receipts?

Consider: If I sign cheque #45 and give it to someone who then cashes it, the money will come out of my account, and I’ll get a receipt. And if that person tries to cash it again? No problem… the server can see that it already processed cheque #45, so it refuses to process it twice. I am protected. But… only because the server, in this example, maintains a list of cleared cheque numbers. I am also relying on the server to “play nice” and only process cheques once. But what if the server itself is malicious? (Perhaps the cheque is made out to them, and they want to run it through multiple times, keeping the money each time.)

In such a dispute, I’d say, “Where is all my money?” If they said, “We don’t know,” but meanwhile my last receipt—with the server’s signature on it—shows a balance of a thousand clams, yet the server has nothing else with my signature on it (to prove why the balance should have suddenly changed), then they are clearly liable for whatever money is missing.

To avoid that situation, they’d have to say, “The money went out from these 10 cheque payments.” Of course they cannot prove such a claim without producing the signed cheque receipts. And when they do that, it will become instantly clear that the same cheque, number 45, was run through multiple times, and thus the transactions are all invalid. There is no escaping this discovery, since the server cannot forge my signature and put whatever transaction number it wants onto a cheque.

The point? Whether the server has to defend against malicious users running the cheque through twice, or whether I have to defend myself against a malicious server doing the same thing, either way, both sides are thus forced to store the transaction history forever, in order to cover their ass in the case of any dispute.

IT’S TIME FOR A NEW WAY: So-called “Destruction of Account History”

Double-entry bookkeeping was a huge leap forward in the economic progress of the West, as it made it possible for balances to be proven and for fraudulent activity to be rooted out and pinned onto specific people. Unfortunately, as explained above, the storage of transaction history is a necessity for accomplishing this. If you do not have all of the transactions recorded, then you are no longer able to “balance the books”.

Yet today we live in the age of strong crypto, where it is easy for me to produce a transaction request with an unforgeable digital signature, and for the server to include a complete copy of this signed request inside its signed reply. I cannot prove anything later without producing that server reply, and if I do that, I will have thus also produced my original signed request, since a copy of it is included within the server reply.

==> If each of these receipts also includes a new, signed, balance agreement, then it is no longer necessary for the server to store any previous transactions at all, since he already has my (unforgeable) signature on the current balance!

==> If, furthermore, that same, signed-by-both-sides, balance agreement also includes a signed list of all of my still-uncleared transaction numbers, then as a user, I am assured that I cannot later be nailed with some mystery transaction, even if it has my signature on it.

Huh? How does that work? I’ll explain: if I really did authorize a given cheque, then not only will the server have my signature on the cheque, but it’ll also have my signature on the list of authorized (single-use) transaction numbers assigned to me—and the cheque’s number appears on that list! That’s how the server proves that I really authorized the cheque. But… once the server clears the cheque, then a cheque receipt with the cheque number on it goes into my inbox. The server cannot clear the same cheque twice without either (a) failing to give me the receipt the second time around or (b) giving me a receipt with the same cheque number TWICE in the same inbox.

What about the case where I accept the receipt (to remove it from my inbox) and then a malicious server runs the cheque through again? This is not possible, because by then it’s already too late: the updated list of transaction numbers was already signed again by both sides, and the cheque number was therefore already removed from that authorized list, vis-a-vis the process of accepting the original receipt. (The “List of uncleared transaction numbers” is signed, like the balance agreement, by both client and server any time the client requests a transaction or accepts a receipt.)

Meaning: I have the server’s signature and timestamp proving that I am not responsible for that transaction number anymore, as of the timestamp on the receipt. So unless the malicious server can somehow come up with a newer receipt, where I re-take such responsibility, I’d win the dispute.

To me the amazing part of all this isn’t that the balances are proved, or that the authenticity and authorization of an instrument can be proven. The amazing part, rather, is that it is done while simultaneously eliminating any need to store the account history, or even an “account” at all (other than the receipt itself) on both sides! Server and client only need to store the latest receipt, and the winner in any dispute is the one with the newest receipt.

Because all parties must sign off on any transaction, and because receipts are provided in all directions, the layers of proof are pretty comprehensive. For example, take a look at the receipts received by all parties during an account-to-account transfer:

ALICE
– Alice gets the server’s signature on her transfer request (whether it is accepted or rejected, she still
gets a signed receipt.)
– She gets Bob’s signature (in her inbox) accepting her transfer when he processes his own inbox.
– She also gets the server’s signature on that when it happens.
– She’ll also get the server’s signature on an agreement of balance at the same time.

BOB
– Bob gets Alice’s signature sending the original transfer, which appears in his inbox.
– He also has the server’s signature on that
– Then, when he accepts her transfer, he will get a signed receipt from the server when his balance is updated.
– He will also have a signed balance agreement from the server at this time.

THE SERVER
– The server gets Alice’s signature on the transfer request.
– The server gets Bob’s signature accepting Alice’s transfer.
– The server gets Alice’s signature acknowledging Bob’s acceptance (when she removes his accept notice from her inbox.)
– Tthe server will also have Alice AND Bob’s agreement on both of their balances, (and doesn’t need to store anything else.)

---

How does Open Transactions compare to Truledger?

• Because Truledger focuses on account transfer, and because you are always guaranteed that transfers will happen in order (versus cheques, which can hit your account at any time unexpectedly), Mr. St. Clair was able to rely on a simple assumption: That all transactions prior to a specific balance agreement have been cleared, and are therefore no longer pending.

• I was apparently also relying on this simple assumption. Unfortunately, I was wrong to do so, since Open Transactions features transactions that may occur out of order. (I am just now implementing balance agreement, and thanks to Bill for helping me realize this difference between his system and my own.) You might use transaction numbers 5, 6, and 7 on a set of three cheques. But the recipients might redeem those cheques in the order 7, 5, 6. Just because cheque 7 has cleared, does not mean that 5 and 6 have cleared! OT thus does not have the same guarantee of sequential processing that Truledger does.

• This means that Open Transactions must include a list of all uncleared transaction numbers with each balance agreement, so that when the receipt is presented later, clear proof may be obtained as to which transactions were cleared and which had not yet been processed. Whereas on Truledger, the balance agreement itself proves the current transaction number, and all previous numbers are considered cleared.

• In both cases (Truledger and Open Transactions) the same basic effect is achieved: server and client can prove balances and instruments simply by presenting the most recent receipt, with no need to store any previous transaction history. OT has to include all outstanding transaction numbers on the receipt, but this enables OT to support offline instruments (such as cheques) that may be presented later in a different order than they were originally issued.

• The other big difference is that Open Transactions assigns the transaction numbers to a user account, and they might end up being used for any of that users’s asset accounts, meaning that OT has inboxes for the user accounts (for receiving transactions and messages) AND for the asset accounts (for receiving pending transfers and cheque receipts) whereas in Truledger, the user account IS the asset account (you can create more than one if you need to), and therefore only one inbox is necessary.

• The other big difference, right now, is that Truledger uses timestamps for its transaction numbers, whereas OT uses sequential long integers. Most likely, OT will soon also change to using timestamps—but not for the same reason. On Truledger, the timestamp proves the sequence of the transaction, and thus eliminates the need for any other timestamp on the receipt (the two numbers are one). Whereas on Open Transactions, the transaction number wouldn’t prove the sequence even if it WAS a timestamp, since instruments can be presented out of order!

So then, why is OT converting to use timestamps? Because it’s the only way to expire them. The server would otherwise be forced to store uncleared numbers forever, in case they came floating back in some day. To fix this, OT will soon switch to timestamp-based transaction numbers, to make it easy for the server operator to expire any uncleared transactions that are older than N days.

Much gratitude and respect for Bill St. Clair, whose work on Truledger was truly inspirational and who has been available for discussions on this topic.

Click here to read more about cheques.
Click here to read about other financial instruments on Open Transactions.