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

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!


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
> <https://youtu.be/LoZ2eWA1bUs?si=hKLFdurfdVa3oPHh&t=300>*
>
>
> Peace, Johan
>
> Sent with Proton Mail <https://proton.me/mail/home> secure email.
>