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

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