What is a mutual credit currency?

Learning Library FAQs
#17

The evolution of mutual credit, Ryan Fugger’s invention from 2003, “multi-hop mutual credit”, solved the fake accounts problem. Pseudonym Pairs is good for global consensus, mutual credit (what it became after multi-hop model was realized) is only an agreement between two people at most, therefore doesn’t need any consensus algorithm like PoW or PoS since there is no consensus.

Here is a promotional image I made for for Pseudonym Pairs a few days ago. The test net is still just 4 people + one joining this month. It can grow by doublings, 2, 4, 8, 16… 1 billion.

pp
pp1536×1024 250 KB

2 Likes
#18

thanks for jumping into the conversation @resilience-me ! Never occurred to me that trustline networks, a la Ripple, remove (or seriously reduce) the need for proof of personhood, but I think you may be right.

Interesting thing about Ripple: neither @mwl nor Ryan Fugger describe it as mutual credit, but the Trustlines documentation does (Trustlines is basically Ripple on Ethereum). Could create a lot of controversy if we wanted to talk about the distinctions; am I right, Michael? :wink:

(Great graphic BTW @resilience-me)

#19

Thanks for the mention.

To tell the story of Ripple the best I can, I think Ryan called it mutual credit. It is mutual credit, it just takes it to the natural logical next step, making it more mutual credit than earlier concepts of mutual credit.

From page 3 in Ryan’s second whitepaper from 2004,

There’s no reason why many mutual credit networks in different denominations couldn’t operatesimulaneously on the same servers.

He has acknowledged being inspired by Michael Linton many times. His invention solves fake accounts completely. My invention from 2012 (link), makes it possible to add a guaranteed basic income to it.

That I happened to end up also building a global “proof-of-person” is a long story…

1 Like
#20

True, he does describe it as ‘going beyond’, and TBH I really like it (I’m a sucker for a clever idea). The critique I’ve heard is that what it lacks, that mutual credit has, is the idea of a group of people stewarding a common pool of credit rather than being accountable to specific peers for specific amounts of money.

#21

From my PoV it doesn’t seem like group credit was superior, just that no one had found a way to scale money without a community before Ryan Fugger suggested scaling it in the same way the internet scales. I know Holochain is based on group mutual credit.

1 Like
#22

I’ll go with Ryan - that Ripple isn’t mutual credit. Mutual credit is an internal process in a community and Ripple was designed expressly as a way out of that collaboration - the credit holder getting out with what they can. “IOU” terminology generally indicates an interest in claim and assignment - which could perhaps be called “mutual liability”, but who wants that?
So recently I’m deprecating “mutual credit” - a term devalued by its general application - and restating as mutual commitment / common money, which speak better to what makes such systems work in my view.

3 Likes
Vril: The Ultimate Currency Project
#23

The logical validators of a mutual credit transaction are the two participants and maybe “the network” as a group agent to enforce the agreed-upon credit limits.

@mwl did you ever use credit (account positive or negative balance) limits in a mutual credit/commitment/common money network? If so, how and when were they enforced??

#24

Any consideration of limits depends entirely on the application, and what it needs to be viable - why limits? to generate what? guard against what? why is that a concern? what is the actual risk? to whom? are there other (better) remedies?

With clear analysis that examines particularly the presumption / perception of the inevitabilty of free riders and how they will cause falling skies there’s generally not an issue.

But who would believe a bicycle easy to ride if they had never seen one before? - clearly unstable, just look at it.

All of this and more can be explored at LETSplay the game with additional materials and guides.

In our co-vestment model however, designed to introduce a $:cc convertibility (for entry, not exit) there is a restricted set of issuers, so a zero credit limit on all other user accounts.

Other than that special case I’ve not yet seen reason for limits in any system I’ve used, nor indeed in many that do have them and I think suffer accordingly. However, looking forward to networks like, say, player trades in professional sports or large scale land deals, the currencies of record will likely require more substantial and effective governance than simple limits, perhaps that every transaction in that net requires sign-off by all.

On “logical validators” our openmoney specifications/ (search “journal entry” and thank John Waters) seem to match yours and be likewise holo compatible.

5 Likes
#25

@bhaugen what measures are being taken to enforce the agreed-upon credit limits?

#26

I don’t know if the current Holochain mutual credit experiments have credit limits or not, and @mwl , who knows a lot more about mutual credit than I do, doesn’t believe in them. All of the existing mutual credit systems that I know about use centralized software, so the server enforces the credit limits. But if a Holochain mutual credit network wanted to have credit limits, they would need to be enforced in the transaction validation, I think as one more agent (a group agent) involved in the validations.

But regardless of how implemented, the transaction validation would need to consult the credit limits.

Does that make sense to everybody else?

#27

Yup, I understand what you’re saying. And one thing to keep in mind is that the credit limit might want to be changed over time. So I’m picturing (from the implementation POV) a credit limit entry that gets written to the DHT and has an expiry date. For a transaction to be valid, the spender’s new balance must be within the credit limit specified by the credit limit entry whose applicable date range encompasses the transaction’s timestamp.

(As for the governance of changing the credit limit, Holochain’s multiple-perspectivism isn’t as much of a barrier as you would think. You could designate a benevolent dictator to write the credit limit updates, or have an update require a quorum of authorised signers, or what-have-you.)

2 Likes
#28

Great discussion.
I’d be interested to know, how many here in this forum actually use an mutual credit exchange?
There are a few around, with varying levels of success.

I have experience with the CES software in Australia www.communityexchange.net.au

#29

I’ll go with Ryan - that Ripple isn’t mutual credit.

Ryan Fugger specifically uses the term “mutual credit” to describe Ripple though, here on page 3 in his second whitepaper from 2004,

There’s no reason why many mutual credit networks in different denominations couldn’t operatesimulaneously on the same servers.

and page 7 on his 2003 whitepaper,

If two people wanted to set up mutual credit, but didn't want it used to relay others' transactions in “regular” currency, then they must use their own private currency, so their connection doesn't appear on the graph of regular currency connections.

I always interpreted mutual credit as that the balance is positive on the account receiving IOU, and negative on account issuing IOU. This is the definition often given, credit recorded in mutual balance changes.

Ripple is the evolution of your LETS, built on shoulders of giants :slight_smile: Incredible invention. I see it as one of the most important inventions of this century. It is a bit strange that there isn’t any true implementation of it yet though. Since it can operate with just simple peer-to-peer messaging.

1 Like
#30

Thanks for these references to Ryan’s papers Joan.

Paul wrote "Interesting thing about Ripple: neither @mwl nor Ryan Fugger describe it as mutual credit, but the Trustlines documentation does (Trustlines is basically Ripple on Ethereum). Could create a lot of controversy if we wanted to talk about the distinctions; am I right, Michael? "

Sorry - Paul’s comments rang true, so I confirmed them. But I now recall (quite vaguely) that when Ryan showed me the first version I asked (quite firmly) that he take my name off it.

IOU means I Owe You - in which frame A’s transfer to B is NOT considered payment and a debt still exists. Which is NOT money as I know it - it’s just another form of debt-factoring.

And I consider that LETSystems (and other such form of mutual commitment) are money, issued by users. No debt happens.

The problem is compounded when the interests of those in “credit” are presented as entitlement to be paid, and applicable (in theory) to any on the negative side of the ledger.

For me that breaks autonomy, accountability, choice, contribution, pattern, purpose, ethics and adds in reification of risk and accelerates extraction. Ryan’s idea seems to me about getting what he wants out of community, not about supporting it.

On “true implementations” of an “incredible invention” I think in the word “incredible” shows much of the problem. Ryan didn’t (and likely still doesn’t, nor cares to) really understand what LETSystems are about, how they work and why. So he fixed what for him was a problem. That’s ok in general principle of course but in particular practice it can be less so, and here I see Ripple as degenerative rather than evolutionary.

But I do agree Joan that all sorts of useful things can be done by simple peer-to-peer messaging.

Money is a patterning technology. Now, do we want our money entropic or syntropic? https://psychology.wikia.org/wiki/Syntropy

1 Like
#31

“Joan Dark” was just a username based on a video game I used in that chat channel where you said the same thing a year or two ago, "That literally sucks. Ripple doesn’t evolve from mutual credit, it simply departs from it. So there’s irony in Ryan’s attribution, no doubt unintended. " Actual name Johan. I like multi-hop mutual credit a lot. I was cc:ed in this chat because I work on a proof-of-unique-human system. The topic was how to prevent fake accounts in a mutual credit system, a problem that was solved 15 years ago by Ryan Fugger.

Isn’t your money system idea also using a design where “the total amount of credits in existence is always technically 0”?

"An example of how the issuance of your own currency would work could play out like this; every member starts with a 0 balance. By placing a transaction within the system, one account will always go up and the other down by the same amount. So if Bob builds me a shed and charges me 50 “LETS Credits” his account will go up by 50 and mine down by 50. This does of course mean that inflation within the system is non-existent, as the total amount of credits in existence is always technically 0 due to the negative balances. It also means that negative balances are a necessary part of the system and can’t be viewed as “bad”. " (source)

#32

Syntropic!

#33

@pauldaoust have you heard of bright id? apparently they are working on anonymous proof of personhood…

1 Like
#34

Some social graph analysis systems have a notion of seeds , which are people who serve as centers of trust. Seeds are used by the system to differentiate between
honest regions of the graph and sybil regions created by attackers to resemble
honest regions.
Selecting seeds is especially important during the rapid growth phase of the network
when subgraphs of users may arise that are not well-connected to the main graph.

BrightID Main DAO will promote the research of different seed selection methods and
also the creation of tools that make seed selection scalable. Some principles to
consider when creating a seed selection process are outlined below.

All too fishy… Just as corrupt as the SSL certificate-authority infrastructure of the present day… Truth being told, the very central problem of personhood verification has no solution! It’s a chase in vain!

Ryan’s Ripple is the only thing that comes anywhere close; either all ‘users’ in a region/colony are bots or they’re all humans; why the hell should the protocol care!

#35

Don’t know if I have, but their branding looks familiar. Looks interesting; I’ll look into it!

I like this conclusion :slight_smile:

That said, I think all forms of squishy human trust involve some concession to a little bit of centralisation. So maybe the question is, can we embed disciplines into our shared norms that allow us to reach the ‘just right’ level of centralisation and go no further? What does ‘just right’ even look like? I do believe it’s possible to make this inquiry fruitful, but I don’t think it will be easy.

I appreciate this too. There are some things I really like about Ripple. I guess what concerns me is not being able to see beyond my circle of friends to see what kind of company friends-of-friends-of-friends are keeping. Maybe they’re more lax about connecting with bots; how do I even know? I also appreciate @matslats’ observation that it tends to atomise the players in the system, preventing them from coordinating on the greater good.

1 Like
#36

I’m getting myself understand more about mutual credit.

It seems the hard part is how to identify a person/stuff that can own such a credit, and lend the credits to others.

This means a onchain (not blockchain) identify system is a necessary, to make this identify system resilient and fair enough, actually we can make a life simulation,

  • each account/agent need two parent accounts;
  • parent accounts can funding/lending credits to child accounts;
  • child accounts needs to solve puzzles from parents account to get further credits;
  • child accounts get no more credits after a period of time;
  • to get more, the child account needs “work”, like how many transactions it makes, how frequent it interact with other systems;
  • the accounts has hard cap on the credits, if an account holds more that the maximum credit, the extra will distribute to the system;
  • an account could mark as deal after no activities, and transfer its credits to its children and system treasury based on the distribution rule.

Let me know if this is interesting to you.

1 Like