Re: 3-phase commit presented in Austria last week (video)

Hi Melvin happy to hear you have been looking more at the 3-phase commit. And great that Michiel has worked to get discussion going on it here.

Your design ideas about Interledger (about Interledger right and not Ripple?) are another topic. I am no expert on Interledger.

I think the 3-phase commit is "the missing puzzle piece" and that all multihop systems need it. It is therefore good to try and get discussions going around it and to inform people about it. Other implementation details (such as what you seem to suggest) is also important but I do not think it is what the road block has been. I think we need to cultivate the 3-phase commit idea and get a conversation going so that people get informed about it (and it does not just go unrecognized), give focus to it.

You contributed to the invention of the 3-phase commit Melvin. It was in fact in correspondence with you that I had the idea, when I was arguing that my "finish-on-timeout 2-phase commit" could do gradual penalties and I noticed (just like Ryan must have noticed in 2006 sometime with the "cancel-on-timeout 2-phase commit") that I actually ran into a dead end. And since Ryan and everyone else had already done the work to popularize the "cancel-on-timeout 2-phase commit" I could simply attach it after my "finish-on-timeout 2-phase commit" and solve the problem.

It is good to recognize Ryan as the inventor of the gradual penalty model (back in 2006), but the 3-phase commit as what makes it practically possible to do gradual penalty.

Thank you for your kindness throughout the invention process also (during the spring). Hopefully we can work together over the next decades to see the 3-phase commit make decentralized multihop payments a reality, both over Interledger, or Lightning Network/Raiden, as well as Ryans Ripple.

Peace, Johan

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

On Monday, July 7th, 2025 at 2:52 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> čt 3. 7. 2025 v 11:22 odesílatel Michiel de Jong <michiel@unhosted.org> napsal:
>
>> Hi Johann,
>>
>> Thanks for posting this here! Let me try to provide my perspective on what your recent work could mean for Interledger. For context, I worked on Interledger in 2017 and 2018, I had some one-on-one conversations with Johann about his work, and Johann and I shared a presentation slot at the recent week-long https://www.collaborative-finance.net/ conference in Austria (an awesome futurist gathering which more Interledger enthusiasts should attend!).
>>
>> The way I see it (and this is also what [I presented in the 7 minutes before Johann's presentation](https://www.youtube-nocookie.com/embed/ysUBs2ByuHo?playlist=ysUBs2ByuHo&autoplay=1&loop=0&start=565)) there are 3 big issues in a system like interledger:
>> * discovery / routing / quoting
>> * cryptographic proof of delivery (e.g. hashlocks)
>> * guaranteed convergence (e.g. timeouts)
>>
>> Timeouts can work with:
>> * amicable resolution (when a multi-hop payment gets stuck, have a conversation about it)
>> * referee (agree on a single source of truth that will decide whether the payment went through or rolled back)
>> * staggered (stagger the timeout values of the hops, so each connector has some extra time to try to commit their incoming hop after their outgoing hop is committed)
>>
>> Within staggered timeouts there are a few options:
>> * connectors accept the risk and will sometimes lose significant amounts of money if their outgoing hop is committed but they can't commit their incoming one in time
>> * streaming (make the amounts small so the connector risk becomes more manageable)
>> * gradual (this is Johann's new addition)
>>
>> With a gradual timeout, the connector risk is reduced to just small amounts because if they are too late committing their incoming hop, it doesn't time out entirely, but only partially. So for instance, if a connector participates in a 100$ payment, and is slightly too late committing their incoming payment, they will have paid the full 100$ outgoing payment but only received for instance a 99$ incoming payment. Their loss is just 1$ instead of the full 100$ transaction amount.
>> The network as a whole will still disagree on what happened to this payment, but instead of the first nodes saying it rolled back and the later nodes saying it committed, now all nodes will say the payment was at least partially committed, but they disagree on what the amount of the payment was committed (100$ or 99$).
>>
>> I think this is quite a genius innovation that I think none of us thought about when we designed the Interledger protocol. We should consider if we can add it as an optional extension, maybe. I guess it would have to be a new packet type, similar to ILP Prepare, but instead of [expiresAt](https://github.com/interledger/rfcs/blob/f7f54131033cd8dbf7ff15953f58337a0a03fa9f/asn1/InterledgerProtocol.asn#L21) it would have something like startsExpiringAt and then probably something like a (linear?) expirationRate expressed in local amount per second or something similar.
>>
>> The advantage of gradual timeouts is that they reduce the connector risk. One disadvantage is (1) that (like in streaming payments), a sender can get stuck having paid half the amount for for instance a purchase, and possibly no way to pay the other half. Another disadvantage is that (2) part of the money used in a multi-hop payment is potentially locked up for a long time before it gets either rejected or fulfilled.
>>
>> I don't think there is an incentive for any connector or the receiver to (2.1) fulfill late, because they will receive less than 100% of the money that was sent.
>> Also, a prepared payment stops being attractive as (2.2) a free option on arbitrage once part of it starts expiring.
>> However, (2.3) for senders that prepare many-hop payments and then let them expire, with the goal of maliciously locking up liquidity at the participating connectors, gradual timeouts will give a bigger impact than immediate ones.
>> Also, (2.4) a connector may decide not to forward a reject message, or forward it after a delay, to maliciously keep liquidity locked up for longer than necessary at preceding connectors, and (2.5) in the prepare phase (step 4 in the [ILP packet lifecycle](https://interledger.org/developers/rfcs/interledger-protocol/)) a connector may decide not to forward the prepare message, and then it should immediately send back a reject message, but it could of course do this slowly or not at all, to maliciously lock up liquidity at preceding hops.
>>
>> In addition to proposing gradual timeouts, Johann proposes the addition of a third phase. I must say I don't think I understand it fully, but I think it's a mitigation for gradual timeouts disadvantage (2.5) mentioned above. It cleverly makes sure that before the prepare phase starts, each participating connector already has some skin in the game.
>>
>> In a first phase preceding the 'prepare' phase, all hops already reserve funds for the entire path, but the prepare phase is not yet entered.
>> If funds are reserved all the way to the receiver, then the receiver sends an out-of-band message to the sender, confirming this.
>> This means that at this point:
>> * the sender has outgoing funds reserved
>> * each connector sees incoming funds reserved and has outgoing funds reserved
>> * the receiver sees incoming funds reserved
>>
>> There are no connectors that see incoming funds reserved but don't also have their own skin in the game by having their own outgoing funds reserved.
>> Therefore, it is now safe to enter the Prepare phase without worrying about disadvantage (2.5).
>>
>> This preceding liquidity reservation phase also has a timeout, so if the sender never follows up with a Prepare message, then they should send a cancel message, to cancel everything, or otherwise, they will start to be on the hook for a percentage of the transfer amount. This is similar to the gradual timeout but it acts with the opposite effect: instead of gradually rejecting, it gradually executes the payment.
>>
>> I think Johann's three-phase commit would require us to add quite a few things:
>> * two additional message types,
>> * the additional requirement of out-of-band communication between sender and receiver,
>> * a mechanism to link the various new message types to each other
>> * and to the sender's identity, and
>> * some additional threat model analysis around different ways the sender, connectors and receiver could try to game the system.
>>
>> So I don't think it would be as easy to add as the gradual timeouts by themselves. Having said that, I do think it is very clever in how it addresses disadvantage (2.5) of gradual payments.
>>
>> Looking forward to more discussion about this!
>
> Hi Michiel and Johann,
>
> Thanks for the insightful discussion on gradual timeouts and the 3-phase commit. It's sparked some thoughts on practical prototyping.
>
> I'm thinking about many small, independent ledgers living within Solid (or linkedwebstorage [1]) pods, secured by did:nostr [2] identities.
>
> On top of this, I'm proposing we introduce an acl:paymentRequired predicate in WebACL [3] for certain Solid resources. Access would then require a payment.
>
> This setup would let us model payment commitments:
>
> Simple IOUs and Clearing: Start with basic IOU transfers between these Solid-hosted ledgers, followed by simple clearing.
>
> Two-Phase Commits: Then, implement 2-phase commits (cancel or finish on timeout) for these IOU payments to observe penalties and consistency.
>
> Three-Phase Commits: Finally, tackle Johann's 3-phase commit within this framework, experimenting with pre-reservation and gradual execution/rejection.
>
> I believe this approach offers a powerful testbed, using Solid for data and did:nostr for identity, directly prototyping your discussed payment coordination challenges.
>
> Looking forward to your thoughts!
>
> Melvin
>
> [1] https://linkedwebstorage.com/
> [2] https://nostrcg.github.io/did-nostr/
>
>> Cheers,
>> Michiel de Jong
>> Independent programmer
>>
>> On Fri, 27 Jun 2025 at 16:35, bipedaljoe <bipedaljoe@protonmail.com> wrote:
>>
>>> The logical solution to multi-hop payment coordination was invented by me this spring and presented in Austria last week: https://youtu.be/DVjMis02AE8
>>>
>>> In the history of ideas, it continuous on the same "root" that Interledger "stream payments" has evolved from.
>>>
>>> This root is a "cancel-on-timeout" 2-phase commit. It always introduces a penalty (as does the "finish-on-timeout" 2-phase commit), and the logical next step is to reduce the size of this penalty (so that an innocent person does not get stuck with it). "Stream payments" from Interledger achieves this, but, introduces a new attack vector (very easy to cause payment to fail halfway), is limited in how well it can scale (the more you reduce penalty size, the more packages you need to send, thus the more messages you have to use). I.e., "stream payments" get slower and more resource demanding as they scale towards shrinking penalty size. The other approach was what Ryan Fugger suggested in 2006: shrink the size of the penalty itself. This leads to another problem: the full duration until payment times out gets very long, thus undermining the timeout as a solution to payment getting stuck and requiring penalty to enforce on all phases, but either 2-phase only has penalty on one phase, and by combining both 2-phase commits into a 3-phase commit you solve that problem.
>>>
>>> I would be very happy to work with Interledger to perfect it with the 3-phase commit. The invention is open source and public domain and anyone can own it for yourself so you also do not need to work with me.
>>>
>>> Illustrations: https://ripple.archi/3phase.pdf
>>> Full implementation of Ripple: http://bitbucket.org/bipedaljoe/ripple-normal
>>> Interactive simulation: https://multihop.xyz/?view=sim
>>>
>>> As for the critique of "stream payments", many have critiqued those and Stefan Thomas himself has said he sometimes wonder if they are the right solution, and well, they are not, but, they were a fairly OK attempt (and they do work better for settlement only as in the LedgerLoops project as there a failure half-way does not matter!). But with the 3-phase commit as a perfect solution it is probably far superior also for settlement-only type systems (as less overhead with messages... faster and less resource demanding...)
>>>
>>>> "Why are we talking about packetization? So this is obviously a very technical topic and I know this, not everyone in this audience is extremely technical, but I still thought it was a good topic for this keynote. The reason is that its a topic that comes up over and over again, both when I talk to people who have never head to Interledger, as soon as they learn about packetization and that its a key aspect of Interledger, they sort of wonder why, it seems very cumbersome and why are we doing this. And then the same things goes for people who have been working with the protocol, you know there's papers that gets written where its like "hey should we really be using packetization", and, you know, don't tell anyone but even i myself sometimes wonder like is this the right path. " -How I Learned to Love Packetization - Stefan Thomas, 05:00-05:50, https://youtu.be/LoZ2eWA1bUs?si=hKLFdurfdVa3oPHh&t=300
>>>
>>> Peace, Johan
>>>
>>> Sent with [Proton Mail](https://proton.me/mail/home) secure email.