Hi Martin and Max and everyone else. I solved decentralized payment coordination last year, but overcomplicated it (still the best solution suggested though). Now, I started to consider demurrage for redistribution more (whereas I have favored “path-based redistribution”, tax that hops) and it struck me that the payment coordination could be simplified. (I actually already had the simplified steps in my codebase, but the way the idea had developed, I had missed that the second step was not needed).
I am very interested now in Ripple + demurrage. CirclesUBI is similar to Ripple but the credit limit is shared between all relationships. I do not think doing so adds much. It makes things much more complicated. Oversight is introduced, which makes the infrastructure more complicated (“double spend”-like problems and such). Accounting only on pairs is much easier.
I would also give each person their own demurrage rate. This should self-organize to an equilibrium, much like trends. If most people use a certain rate, it would tend to spread.
Would CirclesUBI community be interested in skipping the “a shared credit limit on all relationships” to instead do Ripple+demurrage with “decentralized demurrage rate selection”?
If I take this approach, it is admission demurrage may be better than path-based redistribution. I am not certain on that, but it seems a lot simpler. Hard to exactly tell the differences. In path-based approach, sender pays for the tax. In demurrage, recipient pays for it.
In my path-based approach, I had also made one wrong rule historically for many years now, and with that rule (which is needed, as was known early on, it just got missed) it starts to be pretty similar to demurrage anyway, just with many many messages needed… whereas demurrage requires only one message, it is accounted for whenever a balance changes… And, me finding the likely ideal solution to payment coordination came from first considering demurrage over path-based redistribution… (demurrage actually makes “finish-on-timeout” 2-phase commit work inherently, but it is better to rely on the “delay fee” for enforcement in the “commit” step and such delay fee is needed regardless to defend an attack vector). That suggests maybe a “hybrid” of Resilience and CirclesUBI is the best approach?
Peace, Johan
