Payment coordination in two phases, what I shared last year finished

[Johan Nygren]

Sender "delay fee", paid out in "chunks" to each intermediary. 

Prepare: "Chunked" finish-on-timeout + delay fee

Sender -> Intermediaries -> Recipient 

(Payment + delay fee starts to be paid out continuously).

Recipient then signals buyer directly. 

If Prepare fails, buyer is enforced to cancel (authenticated with preimage of payment ID)

Commit: Sender -> Intermediaries -> Recipient 

Commit stops delay fee. This enforces propagation for the next hop (penalizes any delay).

What was missing last year was the delay fee. The commit step at the moment I shared the idea (after a year of work building full implementation) did not have enforcement, but nothing suggest adding it was hard. Because of the strangely aggressive responses here, I "rushed" the solution, and added the "reverse" approach you all used. This worked but is unnecessarily complex, and requires delay fee regardless (when sender and recipient are both attacker...).

Peace, Johan

[Johan Nygren]

@startuml
start
:Prepare;
note right: Penalty
note left: Finish on timeout + Delay fee
if (All agree?) then ([Yes])
:Commit;
note left: Delay fee stops
note right: Penalty
end
else ([No])
:Cancel;
note left: Hash lock
note left: Finish-on-timeout + Delay fee stops
note right: Penalty
stop
endif
@enduml

"Chunked penalty" as Ryan suggested in 2006 requires a penalty on each phase. "Cancel-on-timeout" 2 phase commit only has on one phase, likewise, "finish-on-timeout" 2 phase commit also only on one (as I presented in Austria at CoFi here...). But, "finish-on-timeout + delay fee" 2 phase commit has on both. As Ryan noted in old source forge mailing list, "delay fee" is needed anyway (for attack where sender and whoever causes prepare to get stuck collude). So it was already there.

My "3-phase" that combined "cancel-on-timeout" and "finish-on-timeout" 2 phase commit, was a year-long detour (or attempt to meet this "community" half way perhaps, to "listen" as Jorge Timon claimed was not done, but seems better to meet around the goal: Ripple). I "rushed" the last part of my model because of the feedback here.

If this 2-phase works, why has it not been noticed in the past 20 years? Everyone busy assuming the "reverse model" for some reason? Why? Why assume you have to use "cancel on timeout" 2 phase, and not consider the other candidate 2-phase commits? The critique on me suggesting "finish-on-timeout" 2 phase was severe, but why? Why was the "cancel-on-timeout" 2 phase selected as somehow being the best to look at?

Peace, Johan

[Johan Nygren]

Update: 3-phase commit is better. Enforcement (penalty) is stronger on the second/third phase.

The 2-phase "finish-on-timeout" + delay fee does work, but enforcement is weaker.

The thing to remember is a penalty is needed on all phases. This is what was missing in the 2006 protocol from Ryan and why the "gradual penalty" idea was not achievable with it alone - the penalty was only on one of the phases.

So the "indirect teamwork" with you Ripple community was positive. You had half the solution.

And, any comment I doubted path-based redistribution and favoured demurrage, the doubt was ungrounded. Demurrage is single-hop, "tax pool" is your friends. Tax-rate thus has to be number_of_hops higher on average than with multihop (path-based, i.e., project Resilience). It is a good mechanism but belongs in "singlehop" money category alongside Hans-Florian Hoyer's "three-party novation" (which is implemented here).


Peace, Johan