Regular readers (to the extent that it’s possible to be a regular reader of a site that’s updated so irregularly) might remember the idea of making payments via chains of IOUs — if they’ve got a long memory, at least.
I wrote more specifically about what I called a responsible transitive transactions protocol; a way of implementing the idea that I hoped would avoid the necessity for a global public database, like a blockchain. I worked on that idea for a while under a similar name — responsible trust traversal protocol, or RTTP — but I wasn’t entirely happy about the memorability of that name.
Now, I’ve finally decided to call the protocol circulex — short for circular exchange. It has a website, too: https://circulex.nz.
There have been a few changes to the idea since I last talked about it here. For example, I had talked about an initial agreement-to-consider, which established the path along which a payment would flow. But there’s a subtle problem with that idea: it relies on people trusting information that originates from people they have no direct trust relationship with; and that information isn’t a firm commitment.
So, for example, an attacker could happily sign agreements-to-consider with very attractive exchange rates, without ever intending to actually participate in transactions. This would cause a lot of would-be payers to attempt to use paths through the attacker, only to find that their payments always fail; this could easily lead to the network being unusable.
Circulex avoids this problem by making sure that the initiator of a payment (who ultimately chooses which path, if any, to use) relies only on firm commitments from other participants, not merely indicative information. Multiple paths are searched simultaneously, with willing participants making commitments to their neighbours that are conditional on receiving (by a certain deadline) proof that their commitment was included in the path chosen by the initiator. The deadlines cascade, as before, so that no-one is obliged to forward information faster than they believe they’re able to.
If you’re interested in more details, visit the site, where there’s a link to my current incomplete draft of the protocol specification. I hope it won’t be too much longer before the specification is sufficiently complete for work to start on an implementation.