Re: Perfect solution to Denial of Service (DoS) attacks in multi-hop payments

The images do not render on the archive page, here they are as flow chart code (UML) and anyone could render them yourself. Overall, the solution is to use the timeout in the two ways it can be used (first finish on timeout then cancel on timeout) and historically everyone has been using it only in one way (cancel on timeout but same problem if only used as finish on timeout), thus leaving DoS vectors without penalty and preventing the logical and obvious solution of a "chunked penalty", the one Ryan Fugger had already figured out by 2006 as can be seen [here](https://sourceforge.net/p/ripple/mailman/message/1307752/)on Ripple Sourceforge mailing list, but no one managed to figure out the very simple and logical way to ensure all DoS vectors have a penalty (i.e., combine all ways the timeout can be used, which is... just two... it can only be used in two ways, and both have to be used).

finish-payment.png:

@startuml
start
:Lock credit from buyer and forwards;
note right: Cancel on timeout
:Finalize from seller and backwards;
end@enduml

start-payment.png:

@startuml
start
:Lock credit from buyer and forwards;
note right: Finalize on timeout
if (All agree?) then ([Yes])
:Finalize from buyer and forwards;
end
else ([No])
:Cancel from buyer and forwards;
stop
endif@enduml

two-step-payment.png:

@startuml
start
:Lock credit from buyer and forwards;
note right: Finalize on timeout
if (All agree?) then ([Yes])
:Pre-finalize from buyer and forwards;
note right: Cancel on timeout
:Finalize from seller and backwards;
end
else ([No])
:Cancel from buyer and forwards;
stop
endif@enduml

Peace, Johan

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

On Tuesday, June 10th, 2025 at 7:05 PM, bipedaljoe <bipedaljoe@protonmail.com> wrote:

> The basic building block to prevent Denial of Service attacks is a timeout. A timeout can be used in exactly two ways. It can cancel the payment, or it can finish the payment. Used alone, either timeout configuration will always risk punishing a node, but either timeout configuration will always have DoS vectors that have no penalty. The penalty can be reduced in size either by doing continuous timeouts (as Ryan Fugger suggested in 2006 [here](https://sourceforge.net/p/ripple/mailman/message/1307752/)on Sourceforge Ripple mailing list), or, by reducing the size of the payment (as Interledger did with "stream payments"). The alternative to reduce the size of the payment itself ("stream payments") is not a good solution. The "chunked penalty" is the ideal solution, but while it is able to deter the DoS vectors that have a penalty it will tend to introduce vulnerability where there is no penalty (as the "continuous timeouts" tend to increase the overall total length until the payment has fully timed out). I.e., "chunked penalty" as a solution to the problem of too big penalty means the original solution of a timeout only works where the timeout incurs a penalty but not where it does not. The solution is to make sure every DoS vector has a penalty, and to achieve that, both timeout configurations (cancel on timeout and finish on timeout) have to be combined.
>
> All multi-hop payment systems in the past 20 years have been built on a timeout that defaults to cancel, with a penalty risk when finishing the payment from the end recipient and backwards. Here, the "finish payment" step (what Ryan Fugger called "commit") has a penalty, but the "start payment" step (what Ryan Fugger called "commit-ready") does not. Thus, with a "chunked penalty", the "start payment" step would become vulnerable to DoS attacks (whereas the "finish payment" step was defended). (Interledger resolved this by using "chunked payments" instead of "chunked penalty" but this is not a good solution).
>
> [finish-payment.png]
>
> The other way to use a timeout is one that finishes the payment. It is equally good to the one that cancels on timeout. Both have penalty at one step (either "start" or "finish" the payment) but no penalty at the other step (for finish on timeout, the "start payment" has a penalty that enforces the original sender to cancel the payment, an action that has to be authenticated with a hash lock just like the "finish payment" step has to be in the "cancel on timeout" configuration and for similar reason).
>
> [start-payment.png]
>
> So a timeout can be used in exactly two ways, both introduce a penalty only on one of the two steps (either "start" or "finish" the payment), but they introduce the penalty on opposite steps. To have a penalty at both steps, both timeout configurations can be simply combined.
>
> [two-step-payment.png]
>
> This is a very simple idea. But since either timeout configuration on its own seems to almost be the solution, it is also easy to miss the fact that their shortcomings are exact opposites.
>
> The combined timeout configurations penalize DoS attacks in every scenario except when the attacker controls both ends of penalty (the sender and receiver). To also deter attacks in that scenario, fees added on top of payment (and paid out in proportion to how long payment was stuck) are also needed.
> Anyone who is interested in the ideal multi-hop payment protocol, the one I have described here, feel free to try and start some discussion on it here so the idea can get some exposure and take over the world, peer-to-peer.
>
> Peace, Johan
>
> Sent with [Proton Mail](https://proton.me/mail/home) secure email.