"Late-receipt penalty" and "late-cancel penalty"
44 views
Skip to first unread message
Johan Nygren
Jun 4, 2025, 10:59:36 AMJun 4
to Ripple Project
Most of you are familiar with Ryan's "late-receipt penalty". By 2010-2012 this penalty was the full payment, but earlier back in 2006 it was continuous with a "late-receipt penalty rate" (mentioned here). The "late-receipt penalty" solves a "stuck decision" problem when finishing the payment, it enforces that each hop (from the seller towards the buyer) propagates the decision to finish the payment. But, the use of a continuous penalty (a "penalty rate") required a decision that could also get stuck, so Ryan abandoned that idea (but he did not abandon the "late-receipt penalty", instead he made the penalty the full payment. Interledger later by 2018 tried to "fix" the problem with the full payment penalty by reducing the size of the payment, but this is not the right approach).
The problem introduced with the "late-receipt penalty rate" (that it requires a decision that can get stuck) is solved with a "late-cancel penalty", that is also proportional to the same "penalty rate". This "late-cancel penalty" is the exact opposite of the "late-receipt penalty". The "late-receipt penalty" reduces the amount that can be finalized, whereas the "late-cancel penalty" reduces the amount that can be cancelled. While "late-receipt penalty" acts on whoever is at the end of the payment (thus at first the seller and then the next hop, etc), the "late-cancel penalty" acts on whoever is at the beginning of the payment (thus first the buyer and then next hop, etc).
The "late-receipt penalty" is a form of "continuous cancellation" (i.e., it reduces the amount that can be finalized), whereas the "late-cancel penalty" is a form of "continuous finalization" (i.e., it reduces the amount that can be cancelled).
The "late-receipt penalty" is used to finish the payment and the "late-cancel penalty" is used to start the payment.
Conveniently, the decision to go from the "continuous finalization" during the "late-cancel penalty" step to the "continuous cancellation" during the "late-receipt penalty" step, is naturally enforced as well (if that decision gets stuck, there is a net penalty on the person that caused it to get stuck).
These two penalty mechanism, the "late-receipt penalty" defined by Ryan 19 years ago and the "late-cancel penalty" defined by me this spring (does anyone know if it has been suggested by someone else earlier?) provides the incentive for true decentralized multi-hop payments. As what Ryan envisioned with Ripple Inter Server Protocol.
These two opposite penalty mechanisms work in every case except when the attacker is both the buyer and the seller (naturally). To also deter that scenario, fees have to be added on top of the payment (that are paid out to each person in the payment chain, in proportion to how long the payment got stuck).
The problem introduced with the "late-receipt penalty rate" (that it requires a decision that can get stuck) is solved with a "late-cancel penalty", that is also proportional to the same "penalty rate". This "late-cancel penalty" is the exact opposite of the "late-receipt penalty". The "late-receipt penalty" reduces the amount that can be finalized, whereas the "late-cancel penalty" reduces the amount that can be cancelled. While "late-receipt penalty" acts on whoever is at the end of the payment (thus at first the seller and then the next hop, etc), the "late-cancel penalty" acts on whoever is at the beginning of the payment (thus first the buyer and then next hop, etc).
The "late-receipt penalty" is a form of "continuous cancellation" (i.e., it reduces the amount that can be finalized), whereas the "late-cancel penalty" is a form of "continuous finalization" (i.e., it reduces the amount that can be cancelled).
The "late-receipt penalty" is used to finish the payment and the "late-cancel penalty" is used to start the payment.
Conveniently, the decision to go from the "continuous finalization" during the "late-cancel penalty" step to the "continuous cancellation" during the "late-receipt penalty" step, is naturally enforced as well (if that decision gets stuck, there is a net penalty on the person that caused it to get stuck).
These two penalty mechanism, the "late-receipt penalty" defined by Ryan 19 years ago and the "late-cancel penalty" defined by me this spring (does anyone know if it has been suggested by someone else earlier?) provides the incentive for true decentralized multi-hop payments. As what Ryan envisioned with Ripple Inter Server Protocol.
These two opposite penalty mechanisms work in every case except when the attacker is both the buyer and the seller (naturally). To also deter that scenario, fees have to be added on top of the payment (that are paid out to each person in the payment chain, in proportion to how long the payment got stuck).
Johan Nygren
Jun 8, 2025, 5:51:32 AMJun 8
to Ripple Project
To explain more simply
Ryan's idea from 2006/2008 has been to have a time out that defaults to cancelling the payment, and to finish the payment from the seller and towards the buyer
This incentivizes each hop to forward the agreement (as everyone here knows)
My idea from this spring was to have a time out that defaults to finish the payment, and to start the payment from the buyer and towards the seller
This incentivizes the buyer to cancel the agreement unless everyone agrees
Why this extra step? It allows the payment to start with a penalty ticker. This ticker allows the time out to be for just a "chunk" of the payment
Interledger tried to achieve the same result with "stream payments" by reducing the size of the payment, but, with my start-payment mechanism (and Ryans finish-payment mechanism) you can achieve it without the convoluted and overcomplicated and very costly (in terms of transactions needed) stream payments
Peace, Johan
Ryan's idea from 2006/2008 has been to have a time out that defaults to cancelling the payment, and to finish the payment from the seller and towards the buyer
This incentivizes each hop to forward the agreement (as everyone here knows)
My idea from this spring was to have a time out that defaults to finish the payment, and to start the payment from the buyer and towards the seller
This incentivizes the buyer to cancel the agreement unless everyone agrees
Why this extra step? It allows the payment to start with a penalty ticker. This ticker allows the time out to be for just a "chunk" of the payment
Interledger tried to achieve the same result with "stream payments" by reducing the size of the payment, but, with my start-payment mechanism (and Ryans finish-payment mechanism) you can achieve it without the convoluted and overcomplicated and very costly (in terms of transactions needed) stream payments
Peace, Johan
Johan Nygren
Jun 8, 2025, 8:20:25 AMJun 8
to Ripple Project
I can emphasize,
both the solution I had on February 21 when I shared my 1 year long work here to build multi-server Ripple:
so I did have a complete solution just as much as Ryan had a complete solution, but, neither is actually good on its own. they are fully working, opposite approaches, but not very good on their own.
in my solution, I had always considered the penalty to be gradual, and in Ryan's original solution in 2006, he had considered the penalty to be gradual. but in my solution this led to another problem and in Ryan's it led to another problem (so he abandoned it by 2008 and used the full payment as penalty). but I noticed that if I combined my solution with Ryan's, that problem was solved.
if anyone feels like publicly auditing my solution, and feels like staking their reputation here by proving or disproving it, that would be great. so far, there has been negative feedback but it has been directed towards me as a person, not towards my solution. i.e., the people who gave some negative feedback have deliberately decided to avoid addressing the solution, and rather addressed that I am an asshole, or, that I do not understand computer science, or that I think I am a genius, or alternatively decided to argue "the problem has never been a solution did not exist, it has been that there is no use case for ripple", and so on. the alternative, is to address the solution I present, attack the argument and not the person. anyone here is very free and welcome to do so.
Peace, Johan
both the solution I had on February 21 when I shared my 1 year long work here to build multi-server Ripple:
- start from the buyer towards the seller with a dead line that defaults to paying out the payment, and incentivize the buyer to cancel
- start from the seller towards the buyer against a dead line that defaults to cancelling the payment, incentivizing each hop to agree
so I did have a complete solution just as much as Ryan had a complete solution, but, neither is actually good on its own. they are fully working, opposite approaches, but not very good on their own.
in my solution, I had always considered the penalty to be gradual, and in Ryan's original solution in 2006, he had considered the penalty to be gradual. but in my solution this led to another problem and in Ryan's it led to another problem (so he abandoned it by 2008 and used the full payment as penalty). but I noticed that if I combined my solution with Ryan's, that problem was solved.
if anyone feels like publicly auditing my solution, and feels like staking their reputation here by proving or disproving it, that would be great. so far, there has been negative feedback but it has been directed towards me as a person, not towards my solution. i.e., the people who gave some negative feedback have deliberately decided to avoid addressing the solution, and rather addressed that I am an asshole, or, that I do not understand computer science, or that I think I am a genius, or alternatively decided to argue "the problem has never been a solution did not exist, it has been that there is no use case for ripple", and so on. the alternative, is to address the solution I present, attack the argument and not the person. anyone here is very free and welcome to do so.
Peace, Johan
Johan Nygren
Jun 8, 2025, 9:53:09 AMJun 8
to Ripple Project
Evgeni, in 2006 you mentioned
"daily penalty rate if receipt or path-cancel not received before the penalty deadline" (here on Sourceforge mail list)
The penalty rate for late receipt there is the one Ryan and you had been discussing and the same concept as Ryan's later design (the "staggered timeouts" and all that)
But what is the penalty for path-cancel you mention?
A penalty to cancel can only be applied against the person who has a pending outgoing balance but no pending incoming balance. And, it can only be paid out if the penalty timeout defaults to finalize the payment (a "chunk" of the payment). Whereas the penalty on late receipt can only be applied against the person who has a pending incoming balance but no pending outgoing balance (i.e., already claimed receipt or is seller).
So I assume you must have meant the identical penalty idea I came up with this spring? That forces the buyer to cancel?
I never see Ryan mention path-cancel penalty. Where you two on the same page with it?
If you had the late-cancel penalty and the late-receipt penalty and the fees on top of payment back in 2006, you had a full solution. Why pivot to "commit registers"? The only explanation is Ryan was never aware of the late-cancel penalty?
Of course if you already had this design in 2006 I have no new idea, but, why does this community not seem to be aware of it? Surely you cannot all be aware of it as this community pivoted to a much worse design around 2008-2010-2012.
To everyone else, summary of the late cancel penalty, late receipt penalty, and how both have to be combined for "chunked penalty": http://ripple.archi/multihop_rules.pdf.
"daily penalty rate if receipt or path-cancel not received before the penalty deadline" (here on Sourceforge mail list)
The penalty rate for late receipt there is the one Ryan and you had been discussing and the same concept as Ryan's later design (the "staggered timeouts" and all that)
But what is the penalty for path-cancel you mention?
A penalty to cancel can only be applied against the person who has a pending outgoing balance but no pending incoming balance. And, it can only be paid out if the penalty timeout defaults to finalize the payment (a "chunk" of the payment). Whereas the penalty on late receipt can only be applied against the person who has a pending incoming balance but no pending outgoing balance (i.e., already claimed receipt or is seller).
So I assume you must have meant the identical penalty idea I came up with this spring? That forces the buyer to cancel?
I never see Ryan mention path-cancel penalty. Where you two on the same page with it?
If you had the late-cancel penalty and the late-receipt penalty and the fees on top of payment back in 2006, you had a full solution. Why pivot to "commit registers"? The only explanation is Ryan was never aware of the late-cancel penalty?
Of course if you already had this design in 2006 I have no new idea, but, why does this community not seem to be aware of it? Surely you cannot all be aware of it as this community pivoted to a much worse design around 2008-2010-2012.
To everyone else, summary of the late cancel penalty, late receipt penalty, and how both have to be combined for "chunked penalty": http://ripple.archi/multihop_rules.pdf.
Johan Nygren
Jun 8, 2025, 10:21:29 AMJun 8
to Ripple Project
OK you Evgeni were quoting Ryan's design, from here: https://ripple.ryanfugger.com/Protocol/PaymentProtocol.html, and it says
"The recipient can cancel the transaction at any time by sending the payer a payment-cancel and releasing its neighbours from their promises with a promise-release (see Releasing Promises). The payer can cancel the transaction by sending the recipient a payment-cancel, informing it that it can release its neighbours from their promises. Released promises should be propagated back down each payment path to free up those funds for other payments."
Which says the cancellation was from the recipient and backwards. But then you cannot apply a penalty as you wrote on same page in "daily penalty rate if receipt or path-cancel not received before the penalty deadline" . Your "daily penalty rate if [...] path-cancel not received" idea was not enforceable in your design.
This is what you missed. You have to do the cancel penalty in the opposite direction. You apply it onto the buyer, not the seller. As defined in https://ripple.archi/multihop_rules.pdf.
"The recipient can cancel the transaction at any time by sending the payer a payment-cancel and releasing its neighbours from their promises with a promise-release (see Releasing Promises). The payer can cancel the transaction by sending the recipient a payment-cancel, informing it that it can release its neighbours from their promises. Released promises should be propagated back down each payment path to free up those funds for other payments."
Which says the cancellation was from the recipient and backwards. But then you cannot apply a penalty as you wrote on same page in "daily penalty rate if receipt or path-cancel not received before the penalty deadline" . Your "daily penalty rate if [...] path-cancel not received" idea was not enforceable in your design.
This is what you missed. You have to do the cancel penalty in the opposite direction. You apply it onto the buyer, not the seller. As defined in https://ripple.archi/multihop_rules.pdf.
Johan Nygren
Jun 9, 2025, 11:25:55 AMJun 9
to Ripple Project
Have noticed "lightning network" seems to rely on same DoS prevention as Interledger did before "stream payments" and same as Ripple Inter Server Protocol ideas used in 2008-2012, so I can apologize publicly to David and agree that "lightning" has things in common with Ripple. Just like ideas where each node is a mutual currency community like a LETS (like Evgenis ideas) have things in common with Ripple. All those systems have to solve the coordination decentralized multi-hop payments, they are all in the same boat.
And, I have solved how to coordinate multi-hop payments.
The problem is Denial of Service (DoS) attacks. A timeout is part of the solution, but a timeout cannot exist without also imposing a penalty (the timeout always leads to a penalty), and with that a risk of penalizing a non-attacker.
The solution to avoid penalizing a non-attacker is to do the penalty in "chunks", continuous timeouts with "chunks" of payment rather than all the payment at once.
But, with continuous timeouts, the duration of the combined timeouts gets too long. So the timeout itself can no longer prevent DoS, only the penalty can.
A timeout can be used in one of two ways. It can cancel the payment once the timeout is reached, or it can finish the payment once timeout is reached. Either way it is used, there is DoS vectors that are not penalized.
Only by combining the two ways the timeout can be used (starting with that it finishes the payment and ending with that it cancels the payment) can all DoS vectors be penalized. I.e., only by combining both "trivial solutions" can the penalty be done in "chunks" (which leads to much longer penalty duration and thus makes the timeout itself vulnerable to DoS attacks).
Then for the scenario where attacker controls both ends of penalty (the sender and receiver) the fees added on top of payment (and paid out in proportion to how long payment was stuck) is also needed.
It is quite easy to see why no one managed to solve this. It is not overly complicated, but, both "trivial solutions" (the one Ryan had in 2006 and the one I had this winter) are incomplete solutions, but they are still good enough that they might seem like the complete solution. I mean, every single multi-hop payment system for the past 20 years has assumed the trivial solution that defaults to cancel is "it". I assume people considered the other one (that defaults to finish), and some may have preferred it. Myself, I saw it as a full solution just like others see the other trivial solution in "lightning" etc as the full solution. But, it seems no one considered combining them. I only did so because of the feedback from Ryan and Michiel, for example, who defended the "cancel on timeout" approach and did not seem to support the "finish on timeout" approach (although it is equally good, more or less).
David, Jorge, have both publicly demonstrated here they will not interact with my claim to have solved multihop payments (based on critique of my person but without a single word said about my solution) and this is fair, but to do my part to meet half way I can acknowledge "lighting" and any other multi-hop system has a lot in common. Ripple should also be allowed to be its own thing though (and my Resilience only works on Ripple...), but all projects need the same thing and I have here in this mailing list presented exactly what that thing is.
I attach an extremely simple to understand pdf, with flow chart illustrations that show both "trivial solutions" and the combined solution (the one it seems no one has noticed until me now).
Peace, Johan
And, I have solved how to coordinate multi-hop payments.
The problem is Denial of Service (DoS) attacks. A timeout is part of the solution, but a timeout cannot exist without also imposing a penalty (the timeout always leads to a penalty), and with that a risk of penalizing a non-attacker.
The solution to avoid penalizing a non-attacker is to do the penalty in "chunks", continuous timeouts with "chunks" of payment rather than all the payment at once.
But, with continuous timeouts, the duration of the combined timeouts gets too long. So the timeout itself can no longer prevent DoS, only the penalty can.
A timeout can be used in one of two ways. It can cancel the payment once the timeout is reached, or it can finish the payment once timeout is reached. Either way it is used, there is DoS vectors that are not penalized.
Only by combining the two ways the timeout can be used (starting with that it finishes the payment and ending with that it cancels the payment) can all DoS vectors be penalized. I.e., only by combining both "trivial solutions" can the penalty be done in "chunks" (which leads to much longer penalty duration and thus makes the timeout itself vulnerable to DoS attacks).
Then for the scenario where attacker controls both ends of penalty (the sender and receiver) the fees added on top of payment (and paid out in proportion to how long payment was stuck) is also needed.
It is quite easy to see why no one managed to solve this. It is not overly complicated, but, both "trivial solutions" (the one Ryan had in 2006 and the one I had this winter) are incomplete solutions, but they are still good enough that they might seem like the complete solution. I mean, every single multi-hop payment system for the past 20 years has assumed the trivial solution that defaults to cancel is "it". I assume people considered the other one (that defaults to finish), and some may have preferred it. Myself, I saw it as a full solution just like others see the other trivial solution in "lightning" etc as the full solution. But, it seems no one considered combining them. I only did so because of the feedback from Ryan and Michiel, for example, who defended the "cancel on timeout" approach and did not seem to support the "finish on timeout" approach (although it is equally good, more or less).
David, Jorge, have both publicly demonstrated here they will not interact with my claim to have solved multihop payments (based on critique of my person but without a single word said about my solution) and this is fair, but to do my part to meet half way I can acknowledge "lighting" and any other multi-hop system has a lot in common. Ripple should also be allowed to be its own thing though (and my Resilience only works on Ripple...), but all projects need the same thing and I have here in this mailing list presented exactly what that thing is.
I attach an extremely simple to understand pdf, with flow chart illustrations that show both "trivial solutions" and the combined solution (the one it seems no one has noticed until me now).
Peace, Johan
Reply all
Reply to author
Forward
0 new messages