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.
I am super excited about this app. We have a lot of Local mutual credit currencies and it would be awesome to shift them to an app. I think this is super important at this point in time.
Double spending has never been a question in the software I’ve written because I didn’t have accounts which were incremented and decremented. Instead I had a ledger with payers and payees and calculated user balances on the fly.
Spending limits can to be hard or soft. Soft means the user and maybe the admins will receive a notification. Hard means the transaction will fail to validate.
So sorry I didn’t get to this before, I might have been able to avoid confusions.
So the “double spending” problem I was talking about (though this name may very well not be appropriate) is making two offers to two different people at the same time, and get them to accept them at the same time, while trespassing the credit limit. It looks like this:
There are 3 actors in the system: Alice, Bob and Carol, all of them start with 0. There is a negative credit limit of -100.
Alice makes an offer for 60 credits to Bob.
Just after that, Alice makes an offer for 60 credits to Carol too.
Bob scans Alice’s chain and sees that the transaction history and the offer is valid.
Carol scans Alice’s chain and sees that the transaction history and the offer is valid (Bob’s transaction is still not on Alice’s source chain).
Bob signs the transaction, and Alice and Bob commit the transaction to their source chain.
Carol signs the transaction, and Alice and Carol commit the transaction to their source chain.
Now Alice has a non-forked source-chain, with -120 credits in it. Granted, we could allow for this in our systems and make it so that Alice cannot transact from this point forward (this won’t work in LETS systems without credit limit, so here there really is a security issue), but I wanted to see if we could fix this problem security-wise, and I think we have a good solution for that already implemented and in place.
@matslats I think that in centralized systems this is never a problem, because the server can always know which transaction came before and reject the second one. In this case, it’s the peers themselves the ones validating each other’s chain, so we need to ensure that Carol sees all of Alice’s source chain up to the point of their transaction together.
And actually, this problem only exists in networks where the transactions are private. If the transactions are public, I can rely on the validation rules to verify all the transactions, so I don’t need to be worried about this attack, I think.
I hope I made sense, I’m actually pretty excited because with @hedayat we have finished the implementation for the holochain community mutual-credit experiment and we’ll be sharing it in this forum soon
OK I don’t have a name for that problem, but perhaps it is the accounting-money equivalent of the double-spend problem.
Each ledger must implement its own solution, based on its governance and values.
Generally transactions have two phases, pending and completed. Ledgers may show two balances like on your bank statement when money has been transferred in but not yet ‘arrived’.
With such two step transactions the danger is that a fake pending transaction could be created to offset another pending transaction which would take you beyond your limit. So I see two approaches, relaxed and strict.
Membership of networks is voluntary and all credit is based on trust. Manipulations like the above will be obvious enough and might not be tolerated. Thus it would be regarded as low-trust behaviour in a network that depended on trust. Or it could be an accident, and since everyone promises to return their balance to zero it probably makes no difference.
The hard solution is only to allow new pending transactions that respect the limits whether or not all existing pending transactions are completed. So the user would get a validation failure saying: Sorry you can only trade up to (or down to) X units until your existing pending transactions are completed or cancelled. Is that clear?
I completely see your point. We also have offers with actually more than two steps, but “pending” and “completed” are two of those.
In respect to the approaches you outlined, we basically implemented version 1) of the two solutions, but with a “pessimistic” approach: the accepting agent scans the sender’s chain, and says: “Okey I approve to transact with you, but I’m only going to sign your header if”:
The header contains the correct transaction hash as the entry address. and
The previous header address in the header I’m about to sign is the last header I’ve seen and validated
But actually @hedayat is a big proponent of solution 2), which I also see with merit. In the future it might be best to have 3-4 different approaches implemented as libraries (private-relaxed, public-fast, …), and use whatever general mechanism suits best each use case to then configure and bootstrap the network from that.
Right. I’m building the credit commons reference implementation as a set of microservices, and validation could be a microservice, meaning that it is easy to separate from the rest of the code.
Who or what sets the credit limit in a Holo-mutual-credit app?
@matslats once explained mutual credit to me as an IOU from the community or network who are members of the community or network. (I hope I understood correctly. Matthew, please correct me if I didn’t…)
That seems to assume some governance for the network in setting the credit limit.
Generalize to include parameters such as: negative and positive credit limit
When implemented, what scope would those credit limits apply to? All agents using the same app dna? Or some other scope?
And who do you expect to set the limits?
I know that your app is still work-in-process so you may not have dealt with those issues before, but it’s also a very interesting experiment and is raising some interesting questions.
Yes The experimentation part is the most important one here.
So, there are very different possibilities:
Not set credit limits at all: each agent decides if they want to accept an incoming transaction based on the balance of the counterparty. I don’t know how much this pattern can be scaled, it seems to me that this works in trust networks when you roughly known one another.
Set the credit limits as properties in the DNA, they are fixed and can’t be changed, and apply to everybody. If you want to change those, you need to create a new DNA with new properties and migrate users if you need to. Updating this is hard because you need to maintain determinism of the validation rules, but maybe there is a way, with some governance mechanism.
Have a dynamic credit limit per each agent, according to a function that has as an input the source chain of the agent. This way you can say, every agent has a credit limit proportional to the amount they have contributing to hosting, in the case of holofuel. Or things like that.
Bear in mind that I’m not by any means knowledgeable in this area (hence me wanting to experiment ), other people could come up with much more interesting patterns.
Yeah so that would fall on category 2 but being able to dynamically set the limits, but we need some good validation rules to be able to handle that… Right now the only way I see involves comparing one’s timestamp with the timestamp of the last update of the global setting of the DHT, which means that there might be some accidents along the way when that setting has not yet made available in the DHT, and this could be attacked by setting your own timestamp before the decision was made… I dunno, we have to come up with smart patterns to go around these issues and maintain determinism of the validation rules.
Hey @guillemcordoba Enjoyed the discussion on this thread so far. With regards to your “double-spend” scenario, would it help if the credits transfer between counterparty or counterparties involved multiple steps, like what holo fuel is implementing?
This means, there will enough time (because there are a few steps in the process) for at least the 1st step to be recorded and for any node to check his counterparty’s chain for additional invalid recorded entries while not committing to go ahead (until all steps are done).
I think holo fuel’s tx process involved more steps for higher security, but this may also increase “latency/finality time”. Am i understanding this correctly?
I think this problem occurs anytime you have asynchronous requests between the getting of the source chain of the counterparty. This is the case in my implementation, since I want for members of communities to accept/reject offers depending on the balance of the counterparty, so this needs to be asynchrounous (not in the same zome call). As far as I understand, holofuel does this synchronously, so they don’t have this problem.
I actually thought that all txs in holo fuel or holochain apps are done asynchronously. How is holo fuel able to do their steps synchronously ?
Do you mean steps can done in Holo Fuel synchronously in scenarios like (alice-bob & alice-carol) counter parties & public validations? cc: @pauldaoust@artbrock
What I meant is that HoloFuel sends the source chain and sign the transaction synchronously in the same call, not in two different calls. Actually I wouldn’t want to say too much about how HoloFuel works since I don’t understand fully the validation logic yet.
I followed your presentation with Grace at the Open2020 Coop webinar a week ago. I knew the Holochain since its inception but i am a sociologist (coordinator of the WiseLifeLab- University of Torino), so I wonder if we can have a short interview in which we can present our current proposal (timeline June 26th9 about Covid-19. We prepared a protocol based on tokenization but we would be glad to know if a non tokenized way is possible. My believe is that Holochain could work beyond the mutual credit game, but I am not sure about it.
Thank you for your reply.
Absolutely! Holo-REA will enable any kind of economic networking with any kinds of value flows, including mutual credit, but also food, seeds, biodigester inputs and outputs, energy, pie, whatever.
), other people could come up with much more interesting patterns.