Illustration of the web-of-trust and payments in the simulation above (full size)
This is a multi-server Ripple with person-to-person consensus only. It is built on a penalty system that applies a force on the multi-hop payment coordination. The financial penalty system fixes the problems Ryan Fugger had in his original design for multi-server Ripple, specifically at the "seller finalizes" signal. Note that user-to-user consensus was addressed by Ryan Fugger as early as 2006 here and is not a new idea (although it is done optimally in my design).
Whitepaper: being rewritten as "buyer fees" mechanism in previous one was wrong (now the conventional type of fees is used instead, works just as well, better even, other than that no changes), here is temporary article that explains everything: multi_hop_payment_game_theory.pdf
Repository: bitbucket.org/bipedaljoe/ripple (also on ripple.archi/code)
Simulation: 8_users_payment_scenario.json
Simulation output: output.txt
Illustration of the web-of-trust and payments in the simulation above (full size)
News: 4/21/25: now finished with adapating code for the "buyer fees, published on bitbucket. 4/20/25: now published reworked code to bitbucket. 4/20/25: added most of reworked penalty system where fees are agreed on beforehand, see ripple.archi/code. much improved, now probably perfect design. 4/18/25: the "buyer fees" have to be agreed on prior to the payment rather than the "decentralized fee collection" mechanism I described earlier. This is more conventional, and actually better. The "continuous finalization" and "continuous cancellation" are then separated from each user collecting their share of the fees. Overall better I think.
Contact: johan@ripple.archi
Ripple papers by Ryan Fugger: 2003, 2004, 2006
Work to add swarm redistribution to ripple.archi: My system "Resilience" (swarm redistribution) is added in full in the code at bitbucket.org/bipedaljoe/resilience/. The only difference from the 2012/2013 design is that the buyer does not pay tax for every hop, instead there is a "pay-it-forward" mechanism (this mechanism is also not in the 2019 whitepaper, but it has been alluded to occassionally in blog posts). This distributes the decision making so to speak. It is much much easier to implement, and more beautiful also I think. The ideas for it come from the 2014/2015/2016 period.