Redistribution in Circles only over one hop?

It seems to me that printing coins is mathematically the same as “demurrage” except with an inflating money supply (if you force the money supply to always return to same amount, printing coins will mathematically become “demurrage”).

So, it becomes clear that what a person is getting as UBI in their “person coins”, is money taken from the people who trust them (and thus may hold “person X coin”) and then given back to the person X.

To me it seems like Circles is single-hop redistribution in a web-of-trust. Is this correct? Thus it is comparable to person X asking their 16 friends (if we assume each person has on average 16 friends) to donate money to a UBI fund every month. Maybe something like 60 dollars per friend, roughly 1000 dollars per month.

Note, it is technically possible to achieve multi-hop redistribution in a web-of-trust. This is implemented in full here (includes a solution to “stuck payment attack” that is the main obstacle historically for decentralized multi-hop payments, a solution Circles could also use). Thus if Circles is single-hop redistribution, two categories can be recognized: redistribution in web-of-trust by single-hop vs by multi-hop.

1 Like

Hey, I’m just seeing this now. It isn’t clear to me how the mechanics of Circles can be interpreted as implying that the CRC a user creates are somehow taken from other users. I also don’t know what a single-hop redistribution is. We have, however, published the Circles whitepaper recently, so maybe that helps you better understand the connection to the system you’re building. https://tinyurl.com/circlesv2-whitepaper

"It isn’t clear to me how the mechanics of Circles can be interpreted as implying that the CRC a user creates are somehow taken from other users. "

I am assuming you understand how printing coins redistributes wealth. That financially the effect is the exact same as demurrage (where you explicitly take from someone to give to someone else). And that demurrage and printing coins is just two different ways of doing it mathematically.

When everyone does “redistribution over single-hop only” there is secondary effect too.

The main difference in Resilience vs demurrage in trust network (as Circles, or as in “Flow” that was described here half a year before Martin Koppelman announced Circles idea) is the tax base. Tax base in demurrage is the money supply vs in transaction-tax (“IOU-tax”) it is the transaction volume.

The other differences, may be interchangeable on either tax base (for example, in Resilience for example the “tax rate” is set in a decentralized way, but it is possible a demurrage system could also do this although in Circles so far you set it globally).

I would be happy for Circles (and AlexJc’s “Flow” too) to succeed in being developed. To do decentralized multi-hop payments, you need to solve the “stuck decision attack” problem. I solved that in the past months, defined on multihop.xyz. It continues on the design Ryan Fugger had back in 2006, an incentive system that penalizes the attacker. He used a parameter called “late-receipt penalty rate”, but later abandoned it as it required a decision that could get stuck (and to solve that, another penalty was needed as I defined now but he never got that far as far as I know).

With that, you can run each person in Circles as their own blockchain or equivalent (whereas in AlexJC’s “Flow” each relationship could be its own ledger, i.e., like in Ripple, so it decentralizes a bit more).

I am pretty sure the redistribution in Circles (or AlexJC’s “Flow” from 2014) is similar to when the tax base is the transaction volume (“IOU-tax”) and the tax is forwarded over multi-hop based on the ratio of outgoing-to-incoming balance.

Similar, not identical. But, comparable in effect.

I guess that could answer the question of if Circles is single-hop only. There is “emergent effect” somewhat similar to IOU-tax over multiple hops if it is forwarded based on the ratio of outgoing-to-incoming balance.