Holochain Forum

Guillem Cordoba's Holo mutual credit app

Thanks @guillemcordoba !

Tipped by @ViktorZaunders in an SSB-Holochain conversation.

@pospi @lynnfoster (and anybody else) what can we learn from it?


Hey @bhaugen!

Thanks for sharing this here, be careful though. I did this more as an experiment than as a real project, I wanted to learn the difficulties of implementing such an app.

Actually I’ve been wanting to redesign it completely since at this stage I don’t think it solves the “double-spending” problem. I want to replace the current attestations with confirmation entries before commiting the transactions, maybe @pospi or @lynnfoster can shed some light on the best pattern to use.

1 Like

Does mutual credit have a double spending problem? I suppose in systems that have a limit on how far below zero balance you can go?

I’ll leave your question to @pospi though, a bit too far in the weeds for my level of knowledge in holochain. :disappointed:

Another note: There are some people trying to get a project together to do some exchange related functionality, including mutual credit, in holochain. Will update you if they get something actually together, they are in active discussion, including about funding. But it remains to be seen…


That would only be a problem in a race condition, no? (Which could happen of course…) Any other way for something like a double-spending problem to happen with mutual credit? What am I missing?

I asked Matthew Slater, who has as much experience with mutual credit as anybody I know, if he thought double-spending would be a problem in a mutual credit system. He replied,

A mutual credit system is a style of accounting. Double spending is a problem that only occurs when ledgers get out of sync. So its a non-question. Double-spending is a concern for distributed ledgers only as far as I can see.

That says to me, it depends on the architecture of a Holo mutual credit system. Does it have the equivalent of a ledger for a whole network, where validity can be enforced at the network level? Could a DHT be partitioned to be a ledger for a network? Could a group agent (or bot) enforce balance constraints?

What else would be needed?

Would some kind of limited transactional consensus be required, at least between the participants in a mutual credit transaction? (One mutual credit transaction requires updating two accounts, decrementing the provider and incrementing the receiver.)

P.S. [edited to add] by transactional here, I mean atomic: both updates must happen or neither of them.

Here are two kinds of double spend problems I can see:

  • In a system with credit limits, you could spend beyond your limit.
  • In a system without credit limits, e.g., LETS, it seems that people make decisions about whether to transact with each other based on their current balance + their transaction history. You could hide the actual size of your balance and mislead peers into making decisions based on incomplete information.

In a Holochain app, double spending looks like forking your source chain and writing two alternate histories. This shows up as a branched tree of headers on the DHT. Now, unfortunately this is un-detectable (DAGs don’t point forwards, only backwards to the root node), so what can we do?

In order to detect this sort of thing, you have to equip some peers to maintain a continuous memory of an agent’s previous actions, so that they can detect branches and blow the whistle on the offending agent. Then, subsequent counterparties have to be able to discover the corruption.

You could designate notary nodes like R3 Corda does, but that reintroduces centralisation. And then there’s shared ledgers with Proof-of-Work/Proof-of-Stake, but we’re trying to leave blockchain behind.

So what we’re planning to build in, at the subconscious layer, is peer witnessing of source chain headers. I think Art’s plan is that the agents that hold copies of an author’s public key will be the notaries for their entire chain. I’m hoping to suggest that it should be the agents that hold their previous header instead, which forces more work for the validator but should be much more robust against attacks.

1 Like

Where’s the best place to learn about trees of headers in the DHT? And how those are implemented as DAGs?

Hm, I don’t think there’s anything yet… except the famous diagram from the home page. You can see that it’s supposed to be a very simple Merkle DAG — no branches or anything, just a single chain of headers. If two headers linked to the same previous header, that would be a branch and would be cause for alarm.

Because the headers get published to the DHT, Holochain is able to (subconsciously) detect branches because of metadata that an author is expected to publish along with the header — as mentioned, I think that metadata will live in the DHT along with the agent ID entry as links that point to each header in sequence. It’ll be a link to a header along with its index in the source chain. You shouldn’t ever have two headers with the same index, so whoever stores your agent ID is able to see your attempt to publish the conflicting one.

But what’s to force you to publish the conflicting header? Nothing, but whenever you enter into a transaction with someone, they can look at the source chain you’ve supplied and ask the nodes that hold your agent ID to check whether their view matches up with the one you just supplied.

Waaaaaaait… that DAG is drawn wrong! It shows the entries pointing to their respective headers, but there’s nothing in an entry that links it to the header. A header, on the other hand, has a link to both its previous header and to its entry. For all purposes you can remove the link to the entry, though, and see the chain of headers as a 1-dimensional Merkle DAG. Because headers are published to the DHT, anyone can reconstruct that DAG.

I think the best person to learn about mutual credit implementations on Holochain from might be @philipbeadle, given he was involved with the authoring of the HoloFuel codebase IIRC?

As to spending limits- it occurs to me that if limits aren’t a problem, you can avoid double spending purely by recording entries as increments and decrements rather than a final balance. The order of operations doesn’t matter, only the outcome. Though this is unlikely to be applicable in reality for the stated reasons of people wanting to have an accurate reading of someone’s balance before transacting with them.

1 Like