Triple Signed Receipts

The idea to use balance agreement combined with transaction numbers in order to eliminate the storage (or need) of any account history (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. The receipt itself becomes the “account”.

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 therefore it cannot just put whatever transaction number it wants onto a cheque receipt.

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. (You can set cheques aside, and examine any other instrument, and end up having to deal with similar conundrums.)

IT’S TIME FOR A BETTER WAY: Eliminating the need for account history entirely

As Ian Grigg said, “The receipt is the transaction.”

And more: the receipt is also proof of balance, and proof of which transactions are still outstanding (all others being closed.)

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? I’ll explain: Even when a cheque has a valid signature on it, once it’s cashed, it’s no longer any good. Though the signature still verifies, the cheque is now “bad”. Thus, it’s not enough for a cheque to have a good signature on it. There must be something beyond the signature which helps us to prove whether or not the cheque is currently authorized — not just for cheques but for all instruments.

Here’s how OT solves this problem: Before I can use cheque #45, I must first sign for transaction number 45. I am now responsible for that number until the transaction is cleared. That is, it will be on every balance agreement I sign, until it is closed out. Thus, 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 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.

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: my last balance agreement contains a list of transaction numbers, but the cheque’s number no longer appears on that list. I’m not responsible for that number anymore since it has already cleared. In the event of a dispute, I can produce my last receipt to prove that I’m not responsible for that number. (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 signed instruments can be authorized and de-authorized. 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.)

Not to complicate things, but on each of the above (on each balance agreement), there is also:
– a list of transaction numbers still outstanding (signed out by the Nym).
– a list of pending transactions, and signed receipts, awaiting approval in the inbox.
– …and a similar list of pending outgoings (in the outbox.)

Once a transaction is closed, it will be removed from the next signed receipt and the old receipt can be discarded.
The user no longer has sign off on that transaction number on any future balance agreements.

That’s important: If Cheque #45 hits my inbox in the form of a cheque receipt, my wallet only needs to verify against
the last signed receipt. If #45 wasn’t signed out to me, then I’m not responsible for that cheque! The signature, by
itself, is not enough.

This makes it possible to define the terms of an instrument, to exercise it, to revoke it, or expire it, or determine the
manner or the number of times by which it shall be negotiated. Nevertheless, parties only need store the last signed receipt.

---

How does Open Transactions compare to Truledger?

• Because Truledger guarantees that transfers will happen in order, 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 major 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 other transaction history. In order to accomplish this, OT has to include all currently 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, where 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 just create as many as you need, and each has its own inbox.)

• The other big difference, right now, is that Truledger uses chronological timestamps for its transaction numbers, whereas OT uses sequential long integers. However, OT will soon most likely also change to using timestamps—but not for the same reason. On Truledger, the timestamp (for a given transaction) inherently proves the prior clearance of all previous transaction numbers, and thus eliminates the need for any “uncleared” numbers to be explicitly declared on the receipt. Whereas on Open Transactions, the current transaction number wouldn’t prove the sequence even if it WAS a timestamp, since instruments can be presented out of order! This is why OT explicitly must declare all uncleared numbers on the receipt.

So then, why is OT bothering to convert to use timestamps as transaction numbers? 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.