Yet another white paper

[cojulapa]

Hi there,

 

I have been reading along mutual credit newsgroups for years. Being impressed by ripple and ledgerloops I generated my own idea of how to solve the task of allowing multi-hop payments.

 

Being far from perfect I hope I arrived at least at a stage where I might get the concept across.

So let’s put this claim under test 😉

Here is the next white paper.

 

Happy to hear all your feedback. Or maybe you kill the concept right away with some good arguments? Then the idea is a least out of my head 😊

 

Thanks for your time if you read through,

Coju

[Michiel de Jong]

Fascinating, thanks a lot for writing this up!

I think you're right about the timing issues of when to try to route a settlement, and that it's not tractable

to do this when a user is waiting for an interactive decision. I think the gem is in this part on page 3:

> One day Ann goes to a bar and wants to drink some Tonic. Before paying they agree to check

> for open favors. They find out about the open favor of Bob. So Toni now says "If you tell me the
> solution of riddle RA3 then you can have the drink on Bob." Ann reveals the secret and can enjoy
> the drink.

One downside is you need a lot of riddles to make this work. In the example, Ann gave 4 riddles to Bob, and those end up with Tim, Tina, Toni and Toby as the final recipients. Note that it's not safe for Tom to use RA3 or RA4, because he gave out promises to Toni and Toby based on those. So if Tom would accept the solution from Ann and pass it to Bob, then Bob could sell the riddle's solution to Toni or Toby, and they could claim the reward from Tom, even if Tom already paid it out to Ann. So each node would really need to hold one riddle for each other node to which it's not connected. That's not impossible though...

I thought of variations of how to do routing. Your system is good in that it puts Ann and Toni in a "ready to transact" situation, even before they meet. An alternative is to let Toni first buy the drink for Ann unpaid, and then a decentralised loop detection algorithm can detect the loop can be detected the next day, and settle it. That does simplify the messaging system because such an algorithm could use worthless (and thus reusable) probes. For instance, the probe could travel around the network in depth-first search with backtracking until it hits its own tail. When it does, one of the nodes can refer to the worthless probe identifier and send around a riddle.

That is the setup I have always been thinking about, but it's a big step away from "payments" as we know them: with that setup, Toni does not know whether or not Ann will repay him the next day, or ever. Another variation is to allow for exchange rates, where the actor who is in most of a hurry to settle a debt loop has to "cross the spread". But that also leads to an incentive to trade and to inequality.

So I think your setup is definitely a valuable enhancement!

One small nit: I think the message from Tim to Tina is incorrect in the example:

@Tina: "If Tina can tell Tim the answer to riddle RA1 or RA2 then Bob owes Tim a favour."

should probably be:

@Tina: "If Tina can tell Tim the answer to riddle RA1 or RA2 then Tim owes Tina a favour."

Cheers,

Michiel

--
You received this message because you are subscribed to the Google Groups "Network Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-mone...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/fad552cf-ffed-41fa-8486-afb22845b8e3n%40googlegroups.com.

[Matthew Slater]

Thanks for sharing this before publishing.

Here are some comments.

Overall:

I'm not sure if this is a reframing of existing ideas or some thing that solves an existing problem with complementary currency architectures. Not much is new in this field.

The paper needs to start by saying what Dito allows that is currently not possible with ripple or mutual credit. Also what are the trade-offs involved. E.g. I explained yesterday that ripple vs mutual credit is a tradeoff off of connectivity vs governance, the latter being important for managing trade imbalances.  Perhaps Dito offers a decentralised architecture, which many would value but it could never do pathfinding as efficiently. I am aware of a project to to decentralised Ripple pathfinding. https://www.offsetcredit.org

Please send me the intro when you've written it!

More detailed comments:

Ledgerloops reminds me of this: http://cmb.sourceforge.net - Its not a system I ever seriously considered because it seems to me that having to identify a loop before you trade is not practical and will very much inhibit rather than enabling trade.

> In LedgerLoops the route finding of a trust line is done in the moment of payment.

This means you might not be able to pay somebody and you don't know for sure if you can pay until you have paid. You would need a complex set of political agreements to ensure that a loop doesn't evaporate between being identified and my pressing OK.

> There is no obligation to trust all

Not on any individual, no, but the system would be frozen if nobody trusted anybody.

> Dito wants to use the time between issuance of a coin

Its not clear at all what is meant by 'coin' and 'issue' in this context.

> A general problem when bringing the concept of money into the digital domain is the fact that all digital data can be duplicated easily.

This is only a problem while the software conceives of the means of payment as a data object which changes hands because any digital object can be copied. That's why digital money, including crypto is all done with accounts and ledgers, not property. The double spend problem is a really weird framing, because it only applies in the commodity money mindset.

> The proposed mutual payment protocol exploits the facts that coins can be

created with little effort

Here you are now speaking the language of commodity money, and I think it is starting to obstruct your reasoning process.

> Nodes which trust each other are direct neighbors in a network like in Figure 1

This whole section and diagram is ambiguous about whether trustlines are unidirectional or bi-drectional. I think it assumes that all are bidirectional. But this would contradict the earlier statement that 'there is no obligation to trust at all. The whole section needs reworking.

> Needless to say, coins can not only be minted at the instance of a physical trade. Two parties can exchange and spread coins prior to a physical trade to create liquidity along trust lines.

To me this feels less like an extension of the original idea and more like a completely different system. The latter system involves risk which changes everything. The former system is CMB and not interesting to me, so I'm assuming that it is here only as a step on the way to the latter system.

> For the process of payment, each coin has an identifier

Again the coin metaphor can obstruct understanding. In blockchain I understand that each coin is unique but divisible. The ledger is really moving around not coins but arrays of satoshis. Is something similar going on here?

[cojulapa]

Hi Matthew,

Thanks, for your feedback, I have to admit though, that I had troubles understanding some of your points.

>Thanks for sharing this before publishing.

#Well, isn't it published now, Why do you make this distinction?

>I'm not sure if this is a reframing of existing ideas or some thing that solves an existing problem with complementary currency architectures. Not much is new in this field.

#Sorry to say so, but to me this sounds like you haven't yet fully made up your mind what to think. I can not answer this for you, it would however, be interesing to hear your final conclusion.

>The paper needs to start by saying what Dito allows that is currently not possible with ripple or mutual credit. Also what are the trade-offs involved.

#Makes me worry a little that it seems that I wasn't able to get these points across. I thought I tried, since I also consider those very essential. I will try to improve on those in a revision.

>E.g. I explained yesterday that ripple vs mutual credit is a tradeoff off of connectivity vs governance, the latter being important for managing trade imbalances.

#To which yesterday conversation you are refering to?
What do you mean by mutal credit in this context?
For me mutual credit is the idea that everybody can give others credits (simply note down who I owe and who owes me). Ripple, Ledgerloops, offsetcredit, dito, CMB try to make this idea usable above just two nodes. They are strategies, technical implementations, of how to resolve multi hope payments between nodes without direct trust.
On the offset site mentioned by you, they understand it in a similar manner imo.
"At its core, Offset allows to manage mutual credit balances at scale. Managing credit balance between only two people is a simple task, and can be done using a pen and a paper. However, managing mutual credit for a whole economy becomes more difficult, and requires specialized technology."[https://docs.offsetcredit.org/en/latest/theory/mutual_credit_protocol.html]

>Perhaps Dito offers a decentralised architecture, which many would value but it could never do pathfinding as efficiently.

#As efficiently as what?
Indeed, everybody has to decide whether descentralization is a characterisitc they value and want to see in a payment system. If somebody does, it only makes sense to compare efficiency between system that incorporate this feature.
It seems you got at least one of the main points which dito allows :) : full descentralization.

>I am aware of a project to to decentralised Ripple pathfinding. https://www.offsetcredit.org

#Thanks for sharing, I haven't heard of it yet.
Here is probably not the right place to dicuss this since you only mentioned this and I guess you are not involved in the design of their protocol? But the differences I would point out is that they have to go throught the line three times to finish a transaction, during request, response and collection(Though i think one is not really necessary.). So there are plenty of points where this could fail, (nodes going inactive , nodes not getting engough fees) which would set the whole process back to find another route(And it is not clear how they find the route... as they stated they excluded this due to brevity. IMO however the most tricky task).[https://docs.offsetcredit.org/en/latest/theory/mutual_credit_protocol.html]
What is confusing in my eyes is what they define as route discovery. Because later talking about cancelation they write "This can happen for example if there is not enough capacity for pushing credits forward, or the provided fees are not sufficient". So the route detected (which was not described how) isn't acutally a valid route.

>Please send me the intro when you've written it!

#I will consider.

>Ledgerloops reminds me of this: http://cmb.sourceforge.net - Its not a system I ever seriously considered because it seems to me that having to identify a loop before you trade is not practical and will very much inhibit rather than enabling trade.

#I disagree on that. LedgerLoops solved the task of multihop with beeing fully decentralised and having nodes with equal rights. I thought an impressive progess when I read Michiels paper some years ago. CMB has a central authoritiy to which nodes must communicate their payments. (wrote more on it at the end)

>> In LedgerLoops the route finding of a trust line is done in the moment of payment.
>This means you might not be able to pay somebody and you don't know for sure if you can pay until you have paid. You would need a complex set of political agreements to ensure that a loop doesn't evaporate between being identified and my pressing OK.

#Why political?
I think Michiel is/was well aware of this timing issue, he discussed various scenarious in his paper. But I think also the wrong place to discuss here.

>> There is no obligation to trust all
>Not on any individual, no, but the system would be frozen if nobody trusted anybody.

#100% agree, but thats the case in all mutual credit systems...

>> Dito wants to use the time between issuance of a coin
>Its not clear at all what is meant by 'coin' and 'issue' in this context.

#By coin I mean something that can be exchanged in a trade (the coin is a riddles solution). By issuance I mean the process when somebody gets the coin and could spend in thereafter.

>> A general problem when bringing the concept of money into the digital domain is the fact that all digital data can be duplicated easily.
>This is only a problem while the software conceives of the means of payment as a data object which changes hands because any digital object can be copied. That's why digital money, including crypto is all done with accounts and ledgers, not property. The double spend problem is a really weird framing, because it only applies in the commodity money mindset.

#I get your point, and yes others try to do it with ledgers (acutally that is how most digital currencies solved the problem, conventional banks as well). Those systems have other shortcommings. In terms to explain the system proposed, where a solution has value and can be exchanged for something, the analogy of a money or a coin is usefull in my opinion.

>> The proposed mutual payment protocol exploits the facts that coins can be
created with little effort
>Here you are now speaking the language of commodity money, and I think it is starting to obstruct your reasoning process.

#I would like to ask you to elaborate on how it obstructs the reasoning process.

>> Nodes which trust each other are direct neighbors in a network like in Figure 1
>This whole section and diagram is ambiguous about whether trustlines are unidirectional or bi-drectional. I think it assumes that all are bidirectional. But this would contradict the earlier statement that 'there is no obligation to trust at all. The whole section needs reworking.

#Yes, I did not set all the ranges to which they would allow the contacts go into debt. However, they do not trust all, Sue and Sam therefore could not trade with the others.
In fact in dito, nodes can decide on each incomming conditional IOU where to forward it and this will result in the net possible debt/credit they could face if those become used. The ones they currently face are in the myCID list. Ann here holds one coin from bob by the value of the apples. She needs to trust him to this amount.

>> Needless to say, coins can not only be minted at the instance of a physical trade. Two parties can exchange and spread coins prior to a physical trade to create liquidity along trust lines.
>To me this feels less like an extension of the original idea and more like a completely different system. The latter system involves risk which changes everything. The former system is CMB and not interesting to me, so I'm assuming that it is here only as a step on the way to the latter system.

#In a mutual credit system in my opinion there is always risk involved. The point is you know exactly towards whom you have to face this risk. Ann faces the risk that she will never get something for her apples, she cannot force bob to forward it to people where she needs something. Mutual credit is based on the idea of game theory that players see a benefit of cooperation.
Which system would be of interest to you?

>> For the process of payment, each coin has an identifier
>Again the coin metaphor can obstruct understanding. In blockchain I understand that each coin is unique but divisible. The ledger is really moving around not coins but arrays of satoshis. Is something similar going on here?

#Funny to say so but I would not use a coin methaphore to explain bitcoin. I would rather use a flow model where I have to justifiy that I have enough unspent income to use on a spending. I wouldn't say that something similiar is going on here because bitcoin has a totaly differnt principle as any mutual credit system.


*Regarding CMB just as a side note
"When a buyer and a seller agree to trade a certain amount of a product at a given price, they register their agreement into a central database (see The coordinating system). Overnight the database is analyzed and a list is issued of circular transactions that are discovered. The traders themselves are responsible for the actual carrying out of the transactions [1]."
"Running a coordinating system is a serious responsibility that must be appointed to trustworthy individuals or organizations. The coordinator's software must digitally sign all documents it issues so that traders can verify the contents indisputably. Strong computer security is needed."
-> CMB is not decentralized.
Hence there is an authority that has a lot of power, it could exlude people from trading.
I see the bottleneck of such a system also in having all the data of all nodes, need to process all request of all nodes, puts the question how you prioritize them.
The coordinator has also the possibility(power) to exploit, he has to write a report, but who can and will check on this?



Looking forward to your answer,

Br
Coju

[Michiel de Jong]

Great discussion! Glad that we could clear up the confusion around the word 'coin' (a riddle solution in Dito).

One thing I would like to clarify additionally about LedgerLoops is that in its design it intends to decouple trade from payment.

Consider two situations:

1) Alice knows Bob well, and bakes him a pie. They agree that he will return the favour some day, but no need for Bob to pay on the spot.

2) Alice doesn't know Gareth from the Tool Shop at all, but she needs to buy a screwdriver. She asks if she can "pay with LedgerLoops".

Situation 1 is hard enough because it requires:

A) Both participants to be using some LedgerLoops-compatible software

B) The software including the loop-finding to work

Situation 2 is much harder because it additionally requires:

C) The loop-finding to take less than a second

D) A loop to exist that includes the intended purchase

I have always considered D) to be out of scope but I guess for most users it would not be. They would consider it a failure of the software if their transaction fails, even if the transaction they requested was impossible given the credit limits that existed in the network at that time.

HTH,

Michiel

--
You received this message because you are subscribed to the Google Groups "Network Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-mone...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/e9279ec9-cf1f-4272-9764-cd19bb503464n%40googlegroups.com.

[Matthew Slater]

On Sun, 6 Feb 2022, at 21:50, 'cojulapa' via Network Money wrote:

Hi Matthew,

Thanks, for your feedback, I have to admit though, that I had troubles understanding some of your points.

Its not surprising this is an esoteric field, everyone uses language slightly differently.

In an attempt to prevent this thread exploding into something unmanagable I've dropped 2 or 3 paragraphs and I invite you to drop the paragraphs which seem finished or less i mportant...

>Thanks for sharing this before publishing.

#Well, isn't it published now, Why do you make this distinction?

I thought if it wasn't published, my feedback might help to make it better.

>I'm not sure if this is a reframing of existing ideas or something that solves an existing problem with complementary currency architectures. Not much is new in this field.

#Sorry to say so, but to me this sounds like you haven't yet fully made up your mind what to think. I can not answer this for you, it would however, be interesing to hear your final conclusion.

Well, it looks like a way of doing mesh credit. Maybe you should run it past people in trustlines and offsetcredit to see if they think it solves original problems. I think the main problem of mesh credit, especially when decentralised, is the routing, and I think the main idea you're putting foward is the notion of passing around private 'puzzle solutions', which I don't think is routing, but to me sounds like an alternative metaphor for talking about trust-lines. The difference being that each puzzle solution is for a fixed quantity, like a coin so you might need several in a payment, and each one needing to find its own route. On first inspection this feels less efficient. But I encourage you to share it with Offset Credit and Trustlines, they'll be able to give better feedback than me.

>The paper needs to start by saying what Dito allows that is currently not possible with ripple or mutual credit. Also what are the trade-offs involved.

#Makes me worry a little that it seems that I wasn't able to get these points across. I thought I tried, since I also consider those very essential. I will try to improve on those in a revision.

If you did them across the information was dispersed and I'm suggesting you put it at the top and make it absolutely clear. It makes the rest of the paper easier to read.

>E.g. I explained yesterday that ripple vs mutual credit is a tradeoff off of connectivity vs governance, the latter being important for managing trade imbalances.

#To which yesterday conversation you are refering to?

What do you mean by mutal credit in this context?

Sorry maybe that was elsewhere. Please enjoy https://matslats.net/ripple-reciprocation-credit-commons

When I talk about Mutual credit imagine a ripple mesh where everyone trusts and is trusted by a central node whose trustlines are set by a governance process. There is no need for routing, but also the credit risk of one is the credit risk of all.

For me mutual credit is the idea that everybody can give others credits (simply note down who I owe and who owes me). Ripple, Ledgerloops, offsetcredit, dito, CMB try to make this idea usable above just two nodes. They are strategies, technical implementations, of how to resolve multi hop payments between nodes without direct trust.

On the offset site mentioned by you, they understand it in a similar manner imo.

"At its core, Offset allows to manage mutual credit balances at scale. Managing credit balance between only two people is a simple task, and can be done using a pen and a paper. However, managing mutual credit for a whole economy becomes more difficult, and requires specialized technology."[https://docs.offsetcredit.org/en/latest/theory/mutual_credit_protocol.html]

You are correct that advocates of mesh credit systems also use the term mutual credit. However for me the idea that a trustline _could_ run both ways doesn't make a system mutual. My use of the term has been popular for at least 3 decades, and if mesh credit is mutual credit, that leaves no term to describe these other systems, which are actually much more widely implemented and successful than any mesh system!

>Perhaps Dito offers a decentralised architecture, which many would value but it could never do pathfinding as efficiently.

#As efficiently as what?

As efficiently as any version of Ripple, which is centralised.

Indeed, everybody has to decide whether descentralization is a characterisitc they value and want to see in a payment system. If somebody does, it only makes sense to compare efficiency between system that incorporate this feature.

It seems you got at least one of the main points which dito allows :) : full descentralization.

yes. Also offset credit.

>I am aware of a project to to decentralised Ripple pathfinding. https://www.offsetcredit.org

#Thanks for sharing, I haven't heard of it yet.

Its mostly just one Israeli guy, but he's pretty smart.

Here is probably not the right place to dicuss this since you only mentioned this and I guess you are not involved in the design of their protocol?

I've only talked to the guy and not contributed anything technical.

But the differences I would point out is that they have to go throught the line three times to finish a transaction, during request, response and collection (Though i think one is not really necessary.). So there are plenty of points where this could fail, (nodes going inactive , nodes not getting engough fees) which would set the whole process back to find another route(And it is not clear how they find the route... as they stated they excluded this due to brevity. IMO however the most tricky task).[https://docs.offsetcredit.org/en/latest/theory/mutual_credit_protocol.html]

What is confusing in my eyes is what they define as route discovery. Because later talking about cancelation they write "This can happen for example if there is not enough capacity for pushing credits forward, or the provided fees are not sufficient". So the route detected (which was not described how) isn't acutally a valid route.

All that sounds like an excellent place to start the convo with Bar Gouta

>Please send me the intro when you've written it!

#I will consider.

>Ledgerloops reminds me of this: http://cmb.sourceforge.net - Its not a system I ever seriously considered because it seems to me that having to identify a loop before you trade is not practical and will very much inhibit rather than enabling trade.

#I disagree on that. LedgerLoops solved the task of multihop with being fully decentralised and having nodes with equal rights. I thought an impressive progess when I read Michiels paper some years ago. CMB has a central authoritiy to which nodes must communicate their payments. (wrote more on it at the end)

Decentalising CMB would certainly be an achievement. But does it not remain the case that a full loop must be identified before any trade can take place. And that each loop must consist of hops of equal value?

>> In LedgerLoops the route finding of a trust line is done in the moment of payment.

>This means you might not be able to pay somebody and you don't know for sure if you can pay until you have paid. You would need a complex set of political agreements to ensure that a loop doesn't evaporate between being identified and my pressing OK.

#Why political?

Because introduces the need for credit.

I think Michiel is/was well aware of this timing issue, he discussed various scenarious in his paper. But I think also the wrong place to discuss here.

Ok I didn't spend a lot of time on it.

>> Dito wants to use the time between issuance of a coin

>Its not clear at all what is meant by 'coin' and 'issue' in this context.

#By coin I mean something that can be exchanged in a trade (the coin is a riddles solution). By issuance I mean the process when somebody gets the coin and could spend in thereafter.

I suggest you make that explicit in the paper before using the terms in this way.

>> A general problem when bringing the concept of money into the digital domain is the fact that all digital data can be duplicated easily.

>This is only a problem while the software conceives of the means of payment as a data object which changes hands because any digital object can be copied. That's why digital money, including crypto is all done with accounts and ledgers, not property. The double spend problem is a really weird framing, because it only applies in the commodity money mindset.

#I get your point, and yes others try to do it with ledgers (acutally that is how most digital currencies solved the problem, conventional banks as well). Those systems have other shortcommings. In terms to explain the system proposed, where a solution has value and can be exchanged for something, the analogy of a money or a coin is useful in my opinion.

Yes I think your solutions are more like coins than ledgers but a much better analogy would be cheques, because each cheque has its own value and can be issued by anyone. Maybe meditate on payments during the Irish Banking crisis of the mid 70s

https://wiki.p2pfoundation.net/Irish_Banking_Strike_of_the_1970's in which people were payed in low denomination cheques and the cheques circulated like coins and notes.

>> The proposed mutual payment protocol exploits the facts that coins can be

created with little effort

>Here you are now speaking the language of commodity money, and I think it is starting to obstruct your reasoning process.

#I would like to ask you to elaborate on how it obstructs the reasoning process.

This is emerging as the main theme of this email.

Because coins have standard denominations and a central issuer, and no liability, to me it seems like the wrong metaphor to talk about your puzzle solutions.

>> Nodes which trust each other are direct neighbors in a network like in Figure 1

>This whole section and diagram is ambiguous about whether trustlines are unidirectional or bi-drectional. I think it assumes that all are bidirectional. But this would contradict the earlier statement that 'there is no obligation to trust at all. The whole section needs reworking.

#Yes, I did not set all the ranges to which they would allow the contacts go into debt. However, they do not trust all, Sue and Sam therefore could not trade with the others.

In fact in dito, nodes can decide on each incomming conditional IOU where to forward it and this will result in the net possible debt/credit they could face if those become used. The ones they currently face are in the myCID list. Ann here holds one coin from bob by the value of the apples. She needs to trust him to this amount.

I think you didn't answer my point. When I say unidirectional, that means Ann trusts Bob.  Bidirectional would suggest that Bob also trusts Ann, perhaps by the same amount. This is regardless of the current balance between them. A trust line needs to be represented by a single or double-headed arrow, while the current balance between them is a kind of marker that moves back and forth along the arrow. The notation needs to be absolutely clear because it is very easy to confuse credit and debt.

https://www.youtube.com/watch?v=m8N3hLKDvcY

>> Needless to say, coins can not only be minted at the instance of a physical trade. Two parties can exchange and spread coins prior to a physical trade to create liquidity along trust lines.

>To me this feels less like an extension of the original idea and more like a completely different system. The latter system involves risk which changes everything. The former system is CMB and not interesting to me, so I'm assuming that it is here only as a step on the way to the latter system.

#In a mutual credit system in my opinion there is always risk involved. The point is you know exactly towards whom you have to face this risk. Ann faces the risk that she will never get something for her apples, she cannot force bob to forward it to people where she needs something. Mutual credit is based on the idea of game theory that players see a benefit of cooperation.

Which system would be of interest to you?

As I saId, I'm only interested in the latter system, since as I understand it, the former system involves no credit, no liquidity, and isn't practical. Yes there is always risk involved with credit. All these different systems are about who bears that risk, and who says who bears that risk... Otherwise we are left with that barbarous relic, gold!

*Regarding CMB just as a side note

"When a buyer and a seller agree to trade a certain amount of a product at a given price, they register their agreement into a central database (see The coordinating system). Overnight the database is analyzed and a list is issued of circular transactions that are discovered. The traders themselves are responsible for the actual carrying out of the transactions [1]."

"Running a coordinating system is a serious responsibility that must be appointed to trustworthy individuals or organizations. The coordinator's software must digitally sign all documents it issues so that traders can verify the contents indisputably. Strong computer security is needed."

-> CMB is not decentralized.

Hence there is an authority that has a lot of power, it could exlude people from trading.

I see the bottleneck of such a system also in having all the data of all nodes, need to process all request of all nodes, puts the question how you prioritize them.

The coordinator has also the possibility(power) to exploit, he has to write a report, but who can and will check on this?

These are all standard critiques of centralised systems. My concern with CMB is that in practice, trade is almost impossible if you have to set up loops. It solves the double coincidence of wants problem, but only for simultaneous wants. Most exchanges are asynchronous, with 'money' or credit being used to bridge the time gap between giving and receiving. Asynchronous exchange, (and money) allows many many more possible loops. Simultaneous exchange isn't money, it is rather as the name Ciricular Multilateral Barter suggests, just Barter, and as such, suffers all the other limitations of barter outlined by the classical economists.

[cojulapa]

Hi Michiel,

This is interesting, I think you and I have a totally different view of situation 1.
in my mind this situation wouldn't require any fancy software .
The reason is that I do not see the necessitiy to resolve this situation per se.
So that first and foremost it is just noting down what happend.

I see this as the prerequisit credit to allow non-trusted transactions.
And as you described it, it is a very comfortable one. Since Alice isn't demanding, she maybe liked baking the cake, but Bob would just like to give her back. I somehow see this as he valued it more, than it was a burden for Alice to make it. But that is how trade can start off. The willingness to do something with the outlook that it will eventuallty pay off in the future is what a mutual credit systems is based on.

Your goal seems to be to constantly bring all obligations between all participants to zero. Correct me if I am wrong.
This could work only in the case of a very well balanced economy where parties tend to spend all in equal amounts and they all have the behaviour of not saving .
Because having money is somebody elses debt.
I have the impression that different people have different preverences about how much to save. Some feel confident when they move around a zero balance just knowing more or less that they will be able to earn what they need the next month, while other people however, want to have more securities to have a large financial nest egg. It is also differnt over lifespan. There might be times someone earns a lot and then times when they want to live from savings.


So 1 can be used for something like 2 (if Garath knows Bob).
If 1 wasn't there before 2 (lets assume the tool is equal value to the cake), Ann could think "I now owe Bob that much, how can I pay back."
Bob could think "What did she buy, will she be able to deliver this. And what the hell can I give to Garath?!" and Garath, Thinking "Hopfully Bob will make up for Anns expense"

On the other side lets assume another 1) between Bob and Garath and say Bob regularly takes Garths dog for a walk, when Garath is busy. Bob likes dogs anyways and usually denies receiving something in return.
If 2) happens after the two 1)s I assume all participants are more at ease.

It might be a a minor difference but I think first noting down this small favours among trusted nodes which are then used in a transaction between distant nodes is easier to get along with psychologically.

Or with a quote from Simon Sinek :
"When we give expecting nothing in return, it is remarkable how much more others will give back to us."

So in my eyes:
1) is valuable, a resource , a thing to note because of its potential to be used. but nothing fancy required here.
2) is HARD ALL TOGETHER. I totally agree with you!
C) is the engineering task, which can? maybe? eventually? will? be solved.
D) however, is nothing that can be solved by technology imo. This is a matter about people realizing that cooperation finally makes them better off. Taking small risks, maybe first by keeping track of little things where they anyways would not have expected something back (like your 1 example)


Good point though, that people could take this as a failure of the software. At the moment my answer to this would be that if they haven't understood this, they are in danger using it. By danger I mean not managing their risk properly (setting friendships at stake) , having wrong expectations from whom they can claim back value...  So it would anyways be better they stay away from it.

BR, Coju

[Michiel de Jong]

Fascinating!

On Mon, 7 Feb 2022 at 22:43, 'cojulapa' via Network Money <networ...@googlegroups.com> wrote:

Hi Michiel,

This is interesting, I think you and I have a totally different view of situation 1.
in my mind this situation wouldn't require any fancy software .
The reason is that I do not see the necessitiy to resolve this situation per se.
So that first and foremost it is just noting down what happend.

I see this as the prerequisit credit to allow non-trusted transactions.
And as you described it, it is a very comfortable one. Since Alice isn't demanding, she maybe liked baking the cake, but Bob would just like to give her back. I somehow see this as he valued it more, than it was a burden for Alice to make it. But that is how trade can start off. The willingness to do something with the outlook that it will eventuallty pay off in the future is what a mutual credit systems is based on.

Your goal seems to be to constantly bring all obligations between all participants to zero. Correct me if I am wrong.

Yes. In "the normal economy", the goal is to constantly bring all inter-personal and inter-organisational obligations to zero, and only keep obligations (loans or savings) where one of the two parties is a bank. I want to get rid of the special role of banks in this picture.

This could work only in the case of a very well balanced economy where parties tend to spend all in equal amounts and they all have the behaviour of not saving .
Because having money is somebody elses debt.
I have the impression that different people have different preverences about how much to save. Some feel confident when they move around a zero balance just knowing more or less that they will be able to earn what they need the next month, while other people however, want to have more securities to have a large financial nest egg. It is also differnt over lifespan. There might be times someone earns a lot and then times when they want to live from savings.

Yes. Maybe I gave that part too little attention. The sum of the savings in a society always has to equal the sum of the loans. But different people can have different preferred non-zero debt levels. So then to accurately describe the goal of LedgerLoops, I would have to say the goal is to allow each participant to get as close to their preferred debt level as mathematically possible.

 

So 1 can be used for something like 2 (if Garath knows Bob).
If 1 wasn't there before 2 (lets assume the tool is equal value to the cake), Ann could think "I now owe Bob that much, how can I pay back."
Bob could think "What did she buy, will she be able to deliver this. And what the hell can I give to Garath?!" and Garath, Thinking "Hopfully Bob will make up for Anns expense"

On the other side lets assume another 1) between Bob and Garath and say Bob regularly takes Garths dog for a walk, when Garath is busy. Bob likes dogs anyways and usually denies receiving something in return.
If 2) happens after the two 1)s I assume all participants are more at ease.

It might be a a minor difference but I think first noting down this small favours among trusted nodes which are then used in a transaction between distant nodes is easier to get along with psychologically.

Nice point!

 

Or with a quote from Simon Sinek :
"When we give expecting nothing in return, it is remarkable how much more others will give back to us."

So in my eyes:
1) is valuable, a resource , a thing to note because of its potential to be used. but nothing fancy required here.
2) is HARD ALL TOGETHER. I totally agree with you!
C) is the engineering task, which can? maybe? eventually? will? be solved.
D) however, is nothing that can be solved by technology imo. This is a matter about people realizing that cooperation finally makes them better off. Taking small risks, maybe first by keeping track of little things where they anyways would not have expected something back (like your 1 example)


Good point though, that people could take this as a failure of the software. At the moment my answer to this would be that if they haven't understood this, they are in danger using it. By danger I mean not managing their risk properly (setting friendships at stake) , having wrong expectations from whom they can claim back value...  So it would anyways be better they stay away from it.

Yes! Well, Dito does this better than LedgerLoops, probably. If LedgerLoops allowed you to settle payment for a coffee on-the-spot in a café, it would almost be a random coincidence (unless that café is your neighbour in the credit network, of course). For Dito, you would expect that *if* a loop exists, then Dito will already have found it before you enter the café, so that would probably make Dito much more usable in practice than LedgerLoops (for that specific but important use case).

Cheers,

Michiel.

To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/1f73ba41-4316-44fc-bf2f-5487e32049e4n%40googlegroups.com.

[Matthew Slater]

I find it helpful to be clear about the paradigm of exchange, which is quite separate from the paradigm of the gift or the paradigm of wealth capture.

Paradigm of exchange:  The accounting 'resolves' when money/credit balances are zero, that is the target. this doesn't prohibit gifting and maximising surplus, but they appear in the accounts as abborations.

Paradigm of the gift:  There is no unit of account, because one gift is never truly equivalent to another. Usually accounting is done mentally. Closely examined, gifting usually ends up looking like exchange, but without accounting.

Paradigm of wealth capture: requires that the unit of account is also a commodity, so the rich control the market of money.

We here are all focused on the paradigm of exchange. Saving means giving before receiving, and Borrowing means receiving before giving. That's why gross saving must always equal gross borrowing, and therefore savers need to coordinate with borrowers. This is accomplished in a free market through interest rates. High interest rates incentivise saving and disincentivise borrowing and vice versa. It can also be accomplished through political processes, or even by having principle issuer who just issues the difference (though not for ever, obviously)

[cojulapa]

I still owe ;) Michiel a reply to his first comment,
Unfortunately, it was lost somehow.


You mean the gem being the fact that showing one single string is enough to verify a payment. Right? Well, to be fair we have to count in the diff time finding a match in the databases of seller and buyer. That could take a while, considering the size, if such a system would be in place with a lot of participants. But it is at least a taskt PCs are realtively good at...

        >In the example, Ann gave 4 riddles to Bob, and those end up with Tim, Tina, Toni and Toby as the final recipients. Note that it's not safe for    Tom to use RA3 or RA4, because he gave out promises to Toni and Toby based on those. So if Tom would accept the solution from Ann and pass it to Bob, then Bob could sell the riddle's solution to Toni or Toby, and they could claim the reward from Tom, even if Tom already paid it out to Ann. So each node would really need to hold one riddle for each other node to which it's not connected.

Exactly, Tom kept R5 for himselve if he ever wanted to accept. Indeed, it would not make sense to him to accept R3 or R4 from Ann. Since he passed out CIOUS to Toby and Toni.
As far as I can see, your desciption makes clear that Tom has an incentive to stick to protocol and not accept what he forwarded but only what is in his AccL.

        >One downside is you need a lot of riddles to make this work.

        >That's not impossible though...

Right, I thought the same. It is a little crazy and a technical challenge but it probably has a target were you reach a point where it is good enough for the system to run. (I have the hypotheses that coin count converges at a certain point.) In contrast to bitcoin where you have an infinitely growing database... and verification is based on a task that can never be good engouh (rather you engineer the hell out of it just to make mining more efficient to use ore miners for less energy to make more profit, everybody doing that in an endless loop... But technical progress in more efficient mining doesn't make the real system any faster.... or less energy hungry (since for how much energy mining goes on is rather a function dependent on the current price of a bitcoin).

But improving memory space here would have a clear benefit of allowing better liquidity.  

So maybe put it this way : to me this requirement still seems more feasible than characterisics of other cryptocurrencies....

Besides, I was thinking about a supply&demand communication layer in the network. So that your coins end up being accepted from nodes which acctually have something of interest to you.
I came to the understanding that each unique riddle is giving each existing line an identifier. Therefore the large amount. But people have habits and specific interessts. If you are vegan you wouldn't need coins at a butchers .
So they could insert the information of what they demand from the economy into the coin. Then only nodes which can provide those things will keep riddles. (Beside reducing the amount of coins this also gives a kind of signal to the market what is actually demanded: if you see a lot of coins going around with there aren't that many nodes providing this service because they would have keept the riddles already stopping the coin to travell on.)

Further, I think that nodes who want to accept payments from many different nodes are typically large corporations, those would have to pay for and maintain the largest database. They anyways already have a lot of data about customers they save ;)

        >I thought of variations of how to do routing. Your system is good in that it puts Ann and Toni in a "ready to transact" situation, even before they meet. An alternative is to let Toni first buy the drink for Ann unpaid, and then a decentralised loop detection algorithm can detect the loop can be detected the next day, and settle it. That does simplify the messaging system because such an algorithm could use worthless (and thus reusable) probes. For instance, the probe could travel around the network in depth-first search with backtracking until it hits its own tail. When it does, one of the nodes can refer to the worthless probe identifier and send around a riddle.
        >That is the setup I have always been thinking about, but it's a big step away from "payments" as we know them: with that setup, Toni does not know whether or not Ann will repay him the next day, or ever. Another variation is to allow for exchange rates, where the actor who is in most of a hurry to settle a debt loop has to "cross the spread". But that also leads to an incentive to trade and to inequality.

But having this open transaction beetwen non trusted nodes is in my opinion exactly what one needs to resolve. The way you start here is how two trusted nodes would make a transaction imo. I have to admit though: I don't fully get what you mean by worthless probes.
It is a new approach, right?, not the one you proposed in your ledgerloops paper?


Regarding exchange rates: I think this can be achieved in dito too. Therefore, I included the value relation which can be described as "The thing the coin was originaly used for". If two partners while makeing their CIOU contracts have different feeling about how appropriate these two values are (value and value relation ) the might change their CIOU accoringly. This can happen at every hop resulting of a down or upgrade of the coins value. So when checking the list in the process of payment the owner will see how much it is worth at this point in the economy. If he decides to take it, simple all conditional IOUs become active the only difference is that they are not of equal value. What they have written in it is just a matter of each node pair at each hop.

I finally gave up on active routing due to the following reasons:
A) Free to join and quit network ->(hard to come to a point where a route is verified )
B) Likewise it is a constantly changing network (people paying at the same time, with crossovers in the routes, maybe people adjusting their exchange rates trust lines margings)
C) Route finding, as far as I know, isn't a task computers are necessarily very efficient with.

Dito overcomes these problems I think like this:
A) a node decided that it would be ok to pass this transaction for the agreed conditions, and then this information is keept in contracts basically. Therefore, it is unimportant whether the node is active when the transaction happens.
B) It allows nodes only to change their mind when this is ok with everybody who would be affeted. (pulling back CIOUs)
C) it shrinks the needed operations to stupid computer tasks: copying data (message transfer), comparing sorted data and storing huge amounts of data.

In dito when two nodes want to pay, there is basically all the information of all the routes right there. The relevant ones (the one the payer has the solution to - the ones which connect the buyer end seller) can be found with a diff function. The nice thing: those can not change by actions of a third party. So they have time to maybe find their favourite within the existing routes (exchange rates, best match for the price)

>One small nit: I think the message from Tim to Tina is incorrect in the example:
@Tina: "If Tina can tell Tim the answer to riddle RA1 or RA2 then Bob owes Tim a favour."
should probably be:
@Tina: "If Tina can tell Tim the answer to riddle RA1 or RA2 then Tim owes Tina a favour."

You are absolutely right! (The first is true but of course it isnt the thing Tim and Tina would communicate, they need to get THEIR CIOU in their contract Thanks for pointing that out. Already change for the next version.

BR, coju

[cojulapa]

The distinction of the three types really helps of becoming consciously aware of what we do day to day. I think I once wrote something similiar in this forum. Where I was wondering in which realtions people most likely would starting using mutal credit.

However, when making up my mind about a monetary system I always had the vision that this system should not dictate anything on its users, more on the opposite it should allow them to go along as they please in as many aspects as possible.

What the hell do I know?, maybe people like to use it to track little gestures or gifts, so that instead of saying merci with a box of sweets, they simply note it down and later can see it resolved, knowing that it allowed a riskless transaction for two other parties who otherwise could not have traded. And overall they saved the calories on the sweets. ;)

But for sure not all need to  be focused on the paradigm of exchange exclusively.

Likewise, I would also not say that zero balances are the target. Because I think it is hard to achieve this. One would need to control how all people behave. As I replied to Michiel I think people have differnt characters when it comes to money /financial management/ planing into the future. If this weren't the case and we wouldn't face so many problems in the current money system.

Nevertheless, I share the feeling that a mutual credit system, where each node knows to whom it owes and from whom it has credit, is more likely to come closer to this state.

Regarding you mentioning "a  gift is never truly equivalent  ":

Nothing we trade in modern economies is ever truly equivalent to anything else. Two parties just need to feel at ease with a certain trade. And thats it. Just these two parties. They wont harm anybody when they use a mutual credit system to note down what others would like to account mentally.

[Michiel de Jong]

On Tue, 8 Feb 2022 at 21:52, 'cojulapa' via Network Money <networ...@googlegroups.com> wrote:

I still owe ;) Michiel a reply to his first comment,
Unfortunately, it was lost somehow.


You mean the gem being the fact that showing one single string is enough to verify a payment. Right? Well, to be fair we have to count in the diff time finding a match in the databases of seller and buyer. That could take a while, considering the size, if such a system would be in place with a lot of participants. But it is at least a taskt PCs are realtively good at...

        >In the example, Ann gave 4 riddles to Bob, and those end up with Tim, Tina, Toni and Toby as the final recipients. Note that it's not safe for    Tom to use RA3 or RA4, because he gave out promises to Toni and Toby based on those. So if Tom would accept the solution from Ann and pass it to Bob, then Bob could sell the riddle's solution to Toni or Toby, and they could claim the reward from Tom, even if Tom already paid it out to Ann. So each node would really need to hold one riddle for each other node to which it's not connected.
Exactly, Tom kept R5 for himselve if he ever wanted to accept. Indeed, it would not make sense to him to accept R3 or R4 from Ann. Since he passed out CIOUS to Toby and Toni.
As far as I can see, your desciption makes clear that Tom has an incentive to stick to protocol and not accept what he forwarded but only what is in his AccL.

        >One downside is you need a lot of riddles to make this work.
        >That's not impossible though...
Right, I thought the same. It is a little crazy and a technical challenge but it probably has a target were you reach a point where it is good enough for the system to run. (I have the hypotheses that coin count converges at a certain point.) In contrast to bitcoin where you have an infinitely growing database... and verification is based on a task that can never be good engouh (rather you engineer the hell out of it just to make mining more efficient to use ore miners for less energy to make more profit, everybody doing that in an endless loop... But technical progress in more efficient mining doesn't make the real system any faster.... or less energy hungry (since for how much energy mining goes on is rather a function dependent on the current price of a bitcoin).

But improving memory space here would have a clear benefit of allowing better liquidity.  

So maybe put it this way : to me this requirement still seems more feasible than characterisics of other cryptocurrencies....

 

I agree! A riddle can be stored in 32 bytes, so a node that has one riddle for each citizen of the USA would still only need 10Gb, which nowadays off-the-shelf computers and smartphones do have.

 

Besides, I was thinking about a supply&demand communication layer in the network. So that your coins end up being accepted from nodes which acctually have something of interest to you.
I came to the understanding that each unique riddle is giving each existing line an identifier.

Ah yes, it would actually be good to deduplicate, if there are two paths to Ann, maybe you would only need to keep a riddle for one of them?

Then again, to maximise capacity, you would maybe want to keep them all.

It might still make sense to use routing tokens which don't have value themselves, but that do indicate the existence of a viable path to someone.

So for that, Toni generates a random worthless string, a "routing token", and sends it in one direction. Other nodes forward this routing token in all directions, to indicate "there is a path to Toni here" (just that Toni's real identity is obfuscated by using a random string as the routing token instead of a meaningful identifier for Toni). Each node only remembers where they received the routing token from, and that is the breadcrumbs trail. When Ann wants to pay Toni in the bar, she shows Toni her list of routing tokens, Toni sees his own one, and tells Ann which one it is. Now Ann can create the riddle, attaching Toni's routing token as a routing hint, and each intermediate node can forward it, following the breadcrumbs to Toni. These tokens would even only have to be 5 or 6 bytes long instead of 32, to bring down the risk of misrouting due to collisions.

  

Therefore the large amount. But people have habits and specific interessts. If you are vegan you wouldn't need coins at a butchers .
So they could insert the information of what they demand from the economy into the coin. Then only nodes which can provide those things will keep riddles. (Beside reducing the amount of coins this also gives a kind of signal to the market what is actually demanded: if you see a lot of coins going around with there aren't that many nodes providing this service because they would have keept the riddles already stopping the coin to travell on.)

Nice idea! There will also be natural reasons why the people Ann will want to trade with will be relatively local to her in the network. The most obvious one being geography. :) You are likely to be more connected to people who live in the same town as you than to people who live on another continent. And the same will probably happen for subcultures, online communities around specific interests, etcetera.

 

Further, I think that nodes who want to accept payments from many different nodes are typically large corporations, those would have to pay for and maintain the largest database. They anyways already have a lot of data about customers they save ;)

Even if you store routing tokens (6 bytes each) for 8 billion people, it will probably still fit on a standard USB stick. If you store full riddles (32 bytes each) it would still fit on a standard SSD drive.

        >I thought of variations of how to do routing. Your system is good in that it puts Ann and Toni in a "ready to transact" situation, even before they meet. An alternative is to let Toni first buy the drink for Ann unpaid, and then a decentralised loop detection algorithm can detect the loop can be detected the next day, and settle it. That does simplify the messaging system because such an algorithm could use worthless (and thus reusable) probes. For instance, the probe could travel around the network in depth-first search with backtracking until it hits its own tail. When it does, one of the nodes can refer to the worthless probe identifier and send around a riddle.
        >That is the setup I have always been thinking about, but it's a big step away from "payments" as we know them: with that setup, Toni does not know whether or not Ann will repay him the next day, or ever. Another variation is to allow for exchange rates, where the actor who is in most of a hurry to settle a debt loop has to "cross the spread". But that also leads to an incentive to trade and to inequality.


But having this open transaction beetwen non trusted nodes is in my opinion exactly what one needs to resolve. The way you start here is how two trusted nodes would make a transaction imo. I have to admit though: I don't fully get what you mean by worthless probes.
It is a new approach, right?, not the one you proposed in your ledgerloops paper?

Ah, it's the same thing as what I said above about the "routing tokens". I experimented with it in 2016 (apparently called them "probe tokens" then https://github.com/ledgerloops/ledgerloops.com/issues/17), and in 2018 I described it as "Bidirectional Breadth-First Search (BBFS)" in section 3.2.1 of https://ledgerloops.com/doc/whitepaper.pdf

 

Regarding exchange rates: I think this can be achieved in dito too. Therefore, I included the value relation which can be described as "The thing the coin was originaly used for". If two partners while makeing their CIOU contracts have different feeling about how appropriate these two values are (value and value relation ) the might change their CIOU accoringly. This can happen at every hop resulting of a down or upgrade of the coins value. So when checking the list in the process of payment the owner will see how much it is worth at this point in the economy. If he decides to take it, simple all conditional IOUs become active the only difference is that they are not of equal value. What they have written in it is just a matter of each node pair at each hop.

Yes. But be aware that this may attract market makers who make a profit by improving the liquidity of the network, which may or may not be what you want.

 

I finally gave up on active routing due to the following reasons:
A) Free to join and quit network ->(hard to come to a point where a route is verified )
B) Likewise it is a constantly changing network (people paying at the same time, with crossovers in the routes, maybe people adjusting their exchange rates trust lines margings)
C) Route finding, as far as I know, isn't a task computers are necessarily very efficient with.

The forwarding of riddles that happens after Ann does Bob a favour but before Ann meets Toni in the bar is something like a routing algorithm, right? How do you distinguish it from "active" routing?

 

Dito overcomes these problems I think like this:
A) a node decided that it would be ok to pass this transaction for the agreed conditions, and then this information is keept in contracts basically. Therefore, it is unimportant whether the node is active when the transaction happens.

I think I don't understand what you mean by "active".

 

To view this discussion on the web visit https://groups.google.com/d/msgid/network-money/7f46b4ac-9164-4a3c-afe1-fd02ef705d47n%40googlegroups.com.

[cojulapa]

Hi Matthew,

Sorry, for the late response but I had to get into some of the resources you shared.

        Well, it looks like a way of doing mesh credit. Maybe you should run it past people in trustlines and offsetcredit to see if they think it solves original problems. I think the main problem of mesh credit, especially when decentralised, is the routing, and I think the main idea you're putting foward is the notion of passing around private 'puzzle solutions', which I don't think is routing, but to me sounds like an alternative metaphor for talking about trust-lines. The difference being that each puzzle solution is for a fixed quantity, like a coin so you might need several in a payment, and each one needing to find its own route. On first inspection this feels less efficient. But I encourage you to share it with Offset Credit and Trustlines, they'll be able to give better feedback than me.

Yeah, definately it would be interestin to dicuss with them. I picked this forum because it is meant to be project independent. You and Michiel were people 2 and 3 who read the paper. So I also thought about first going for a smaller venue before bothering anybody with it ;)

        >E.g. I explained yesterday that ripple vs mutual credit is a tradeoff off of connectivity vs governance, the latter being important for managing trade imbalances.
        #To which yesterday conversation you are refering to?
        What do you mean by mutal credit in this context?
        Sorry maybe that was elsewhere. Please enjoy https://matslats.net/ripple-reciprocation-credit-commons

This passage from the link was good to clarify your understanding.
"Ripple bypasses the governance problem by letting each user be responsible for their own credit - wouldn't it be much easier just to plug everybody in to Ripple and forget about circles within circles of mutual credit?"
I am fine with the distincition now. For me this characterisitc is the interesting thing to achieve. For me Ripple is one implementation of this principle that everybody can decide about their own credit, with offsetcredit, ledgerloops and dito being others.
In your post you answer the question with NO, would be interesting to dicuss this seperately maybe.

        When I talk about Mutual credit imagine a ripple mesh where everyone trusts and is trusted by a central node whose trustlines are set by a governance process. There is no need for routing, but also the credit risk of one is the credit risk of all.

If you have everybody trusting the central node you are right there is no need for routing. However, this would be like having one bank only in the world which of course has other issues(single point of failure, power, ...)
In the Credit commons you propose, which is to my understanding groups within groups, I think it is wrong to say that routing is totally gone. In each subnet you might have fewer nodes but still on each level you need to mangage risks and credit limits given.

       

        You are correct that advocates of mesh credit systems also use the term mutual credit. However for me the idea that a trustline _could_ run both ways doesn't make a system mutual. My use of the term has been popular for at least 3 decades, and if mesh credit is mutual credit, that leaves no term to describe these other systems, which are actually much more widely implemented and successful than any mesh system!

So your definition of mutual credit would be : giving everybody within the group the same credit/debt range. This is made a rule in the group to which everybody has to obey.
With "these other systems" , you mean the mutal credit systems right? Just to make sure, the link was a little loose here.

        >I am aware of a project to to decentralised Ripple pathfinding. https://www.offsetcredit.org
        #Thanks for sharing, I haven't heard of it yet.
        Its mostly just one Israeli guy, but he's pretty smart.

Unfortunately , that doesn't help with monetary systems *hahah*. ;) It's more helpfull to be easily understood and get a huge crowd to follow you, right?

        All that sounds like an excellent place to start the convo with Bar Gouta

Thanks for the name.

        Decentalising CMB would certainly be an achievement. But does it not remain the case that a full loop must be identified before any trade can take place. And that each loop must consist of hops of equal value?

Not sure about this CMB in detail, but what I am mainly interested in and I think was is the topic of this group are systems which find a loop where the trade can be made possible by intermediatly noting down the IOUS.
So there is no need to find trades of equal value to find a loop.

        >> The proposed mutual payment protocol exploits the facts that coins can be created with little effort
        >Here you are now speaking the language of commodity money, and I think it is starting to obstruct your reasoning process.

        #        I would like to ask you to elaborate on how it obstructs the reasoning process.

        Because coins have standard denominations and a central issuer, and no liability, to me it seems like the wrong metaphor to talk about your puzzle solutions.

Hmmmm, yes, but I think to people it can be easier to grasp, this concept of "I have coins and I can spend them". Since often this mutual credit concept with open credit lines is often far off from what people are used to. Especially, those who maybe didn't think about monetary systems as much as you did already.

        >> Nodes which trust each other are direct neighbors in a network like in Figure 1
        >This whole section and diagram is ambiguous about whether trustlines are unidirectional or bi-drectional. I think it assumes that all are bidirectional. But this would contradict the earlier statement that 'there is no obligation to trust at all. The whole section needs reworking.
        #Yes, I did not set all the ranges to which they would allow the contacts go into debt. However, they do not trust all, Sue and Sam therefore could not trade with the others.
        In fact in dito, nodes can decide on each incomming conditional IOU where to forward it and this will result in the net possible debt/credit they could face if those become used. The ones they currently face are in the myCID list. Ann here holds one coin from bob by the value of the apples. She needs to trust him to this amount.
        I think you didn't answer my point. When I say unidirectional, that means Ann trusts Bob.  Bidirectional would suggest that Bob also trusts Ann, perhaps by the same amount. This is regardless of the current balance between them. A trust line needs to be represented by a single or double-headed arrow, while the current balance between them is a kind of marker that moves back and forth along the arrow. The notation needs to be absolutely clear because it is very easy to confuse credit and debt.
https://www.youtube.com/watch?v=m8N3hLKDvcY

Tustlines does a really good job with illustration here.

In the lowest layer the ranges do not need to be specified for the protocol to work. The node(owner) simply decides for each incoming coin and its riddles where and if to forward it. From the data storage content one can calculate the trust line and the current balance with each neighbor. The owner should however, think about with which values he feels comfortable with. And here I have to admit dito might have a property which could make it hard to adopt: for high liquidity the potential IOU range would be very high. Because if the high amount of coins of everybody being forwarded. At the moment I see the acceptance of the user side as a much bigger problem than the memory storage size.
When one writes an algorithm for his node so that incoming coins are processed automatically one needs to get the trust line range information from the node owner so that the algorithm can balance the incoming coins accordingly and make decissions in the limits of the owner.
I will have to think about the characteristic above and will try to derive the equivalents in the video to dito and probably add a section in the paper.  

        >> Needless to say, coins can not only be minted at the instance of a physical trade. Two parties can exchange and spread coins prior to a physical trade to create liquidity along trust lines.
        >To me this feels less like an extension of the original idea and more like a completely different system. The latter system involves risk which changes everything. The former system is CMB and not interesting to me, so I'm assuming that it is here only as a step on the way to the latter system.
        #In a mutual credit system in my opinion there is always risk involved. The point is you know exactly towards whom you have to face this risk. Ann faces the risk that she will never get something for her apples, she cannot force bob to forward it to people where she needs something. Mutual credit is based on the idea of game theory that players see a benefit of cooperation.
        Which system would be of interest to you?
        As I saId, I'm only interested in the latter system, since as I understand it, the former system involves no credit, no liquidity, and isn't practical.

I think both involve credit, and therefore liquidity. It's really just what was the initial incentive to create the credit. A misunderstanding could maybe be my usage if the term coin. But this coin is just a placeholder of Bobs debt. You would prefer cheque maybe? as you mentioned it above.

        These are all standard critiques of centralised systems.

Yeap, excatly therefore the drive to avoide them.

        My concern with CMB is that in practice, trade is almost impossible if you have to set up loops. It solves the double coincidence of wants problem, but only for simultaneous wants. Most exchanges are asynchronous, with 'money' or credit being used to bridge the time gap between giving and receiving. Asynchronous exchange, (and money) allows many many more possible loops. Simultaneous exchange isn't money, it is rather as the name Ciricular Multilateral Barter suggests, just Barter, and as such, suffers all the other limitations of barter outlined by the classical economists.

The problem you decribe is clear, I do not know about CMB, as you brought it up. But I see that systems like Ripple,Ledgerloops, dito, create credit. So there the problem doesn't exist. They keep the exact information of where this credit is created along the line. But it can be balanced out with multiple other trades with happen much much later, at different times with different value.
So there is no need to have simultaneous wants. 

Cheers, Coju

[cojulapa]

Hi, 

So maybe put it this way : to me this requirement still seems more feasible than characterisics of other cryptocurrencies....

 

I agree! A riddle can be stored in 32 bytes, so a node that has one riddle for each citizen of the USA would still only need 10Gb, which nowadays off-the-shelf computers and smartphones do have.

 Yeah, as I wrote to Matthew what worries me more at the moment is the high potential IOU span in which this would result for each node... 

 

Besides, I was thinking about a supply&demand communication layer in the network. So that your coins end up being accepted from nodes which acctually have something of interest to you.
I came to the understanding that each unique riddle is giving each existing line an identifier.

Ah yes, it would actually be good to deduplicate, if there are two paths to Ann, maybe you would only need to keep a riddle for one of them?

Then again, to maximise capacity, you would maybe want to keep them all.

It might still make sense to use routing tokens which don't have value themselves, but that do indicate the existence of a viable path to someone.

So for that, Toni generates a random worthless string, a "routing token", and sends it in one direction. Other nodes forward this routing token in all directions, to indicate "there is a path to Toni here" (just that Toni's real identity is obfuscated by using a random string as the routing token instead of a meaningful identifier for Toni). Each node only remembers where they received the routing token from, and that is the breadcrumbs trail. When Ann wants to pay Toni in the bar, she shows Toni her list of routing tokens, Toni sees his own one, and tells Ann which one it is. Now Ann can create the riddle, attaching Toni's routing token as a routing hint, and each intermediate node can forward it, following the breadcrumbs to Toni. These tokens would even only have to be 5 or 6 bytes long instead of 32, to bring down the risk of misrouting due to collisions.

I like your analogy with the breadcrumbs. Helps to visualize! I personally used the picture of travellers going from city to city. In each city they talk about where they came form. Like this over time you can gain knowledge what other cities can be reached going into the different directions(torward other nodes) from one node.

What I don't get is your idea with the routing token though... This again ends up that the riddle is created and its path startet in the moment of payment. It might reach its destination faster... The problem I see however that nodes along the line might not be active. As a result the riddle fails to reach its destination.

  

Therefore the large amount. But people have habits and specific interessts. If you are vegan you wouldn't need coins at a butchers .
So they could insert the information of what they demand from the economy into the coin. Then only nodes which can provide those things will keep riddles. (Beside reducing the amount of coins this also gives a kind of signal to the market what is actually demanded: if you see a lot of coins going around with there aren't that many nodes providing this service because they would have keept the riddles already stopping the coin to travell on.)

Nice idea! There will also be natural reasons why the people Ann will want to trade with will be relatively local to her in the network. The most obvious one being geography. :) You are likely to be more connected to people who live in the same town as you than to people who live on another continent. And the same will probably happen for subcultures, online communities around specific interests, etcetera.

Good point, I will add in a location placeholder. I think it would be the location where the owner would wish for liquidity. It not necessarily needs to be the location where he currently is. Do you agree? So maybe a general field: Liquidity specifier, " where  or for what you would wish to spend the coin" would be enough. 

Further, I think that nodes who want to accept payments from many different nodes are typically large corporations, those would have to pay for and maintain the largest database. They anyways already have a lot of data about customers they save ;)

Even if you store routing tokens (6 bytes each) for 8 billion people, it will probably still fit on a standard USB stick. If you store full riddles (32 bytes each) it would still fit on a standard SSD drive.

Like that you are already doing back on the envelop calculations. Did some myself and  came to the conclusion: Not out of reach, but not what we designed for up to now. Especially, because the storage for the safe content would be security critical... But most importantly for me it has a set goal, just as you took it it is the number of people on the planet. The smallest entitiy of economic actor there is.

Ah, it's the same thing as what I said above about the "routing tokens". I experimented with it in 2016 (apparently called them "probe tokens" then https://github.com/ledgerloops/ledgerloops.com/issues/17), and in 2018 I described it as "Bidirectional Breadth-First Search (BBFS)" in section 3.2.1 of https://ledgerloops.com/doc/whitepaper.pdf

I will have to read it first, I will come back to it

 

Regarding exchange rates: I think this can be achieved in dito too. Therefore, I included the value relation which can be described as "The thing the coin was originaly used for". If two partners while makeing their CIOU contracts have different feeling about how appropriate these two values are (value and value relation ) the might change their CIOU accoringly. This can happen at every hop resulting of a down or upgrade of the coins value. So when checking the list in the process of payment the owner will see how much it is worth at this point in the economy. If he decides to take it, simple all conditional IOUs become active the only difference is that they are not of equal value. What they have written in it is just a matter of each node pair at each hop.

Yes. But be aware that this may attract market makers who make a profit by improving the liquidity of the network, which may or may not be what you want.

Not important what I want. In large parts I believe in the free market. People aren't stupid. They wouldn't use an option if it weren't to their benefit or at least one of the best options available. However, it is important to give options tough... Therefore, a premise for me is, that it is good if a systems allows for those options.

I finally gave up on active routing due to the following reasons:
A) Free to join and quit network ->(hard to come to a point where a route is verified )
B) Likewise it is a constantly changing network (people paying at the same time, with crossovers in the routes, maybe people adjusting their exchange rates trust lines margings)
C) Route finding, as far as I know, isn't a task computers are necessarily very efficient with.

The forwarding of riddles that happens after Ann does Bob a favour but before Ann meets Toni in the bar is something like a routing algorithm, right? How do you distinguish it from "active" routing?

Dito overcomes these problems I think like this:
A) a node decided that it would be ok to pass this transaction for the agreed conditions, and then this information is keept in contracts basically. Therefore, it is unimportant whether the node is active when the transaction happens.

I think I don't understand what you mean by "active".

 Well, for me it is the difference of the task that needs to be accomplished at the moment of a payment. For active routing you get the information of the mesh network(in some form dependent whether you have ripple or ledgerloops) and the start S and destination D you now need to find a connection to. The problem is the mesh information is more or less a mess, right? Many dead ends, nodes changing their settings (trust line limits) or going inactive at all(relevant for offsetcredit and ledgerloops as far as I remember). 

In dito S carries a sorted list of paths it can take (its coin IDs) and D has a sorted list of incoming paths. So the task is to just match those. 

In its most trivial form, coins would simply spread in all directions. With which enough liquidity would eventually lead to a match in the lists. Although there was never a request to connect S and D explicitly. Therefore i don't see it as active routing. It is like up to this point noting down all possible acceptable paths. 

How we discussed however, it might be efficient to move riddles where they would most probably be needed, just to limit the amount. This could be considered some sort of active routing. With the interresting asepect, that it is timewise decoupled from the payment process.

Hope this is makes sense :) 

BR Coju

[Matthew Slater]

"Ripple bypasses the governance problem by letting each user be responsible for their own credit - wouldn't it be much easier just to plug everybody in to Ripple and forget about circles within circles of mutual credit?"

If you don't want to deal with long term trade imbalances, yes fine.

        When I talk about Mutual credit imagine a ripple mesh where everyone trusts and is trusted by a central node whose trustlines are set by a governance process. There is no need for routing, but also the credit risk of one is the credit risk of all.

If you have everybody trusting the central node you are right there is no need for routing. However, this would be like having one bank only in the world which of course has other issues(single point of failure, power, ...)

In the Credit commons you propose, which is to my understanding groups within groups, I think it is wrong to say that routing is totally gone. In each subnet you might have fewer nodes but still on each level you need to mangage risks and credit limits given.

Typcially there are only a few people who know each other connected to each central node. The groups are small enough for participative governance.

In the credit commons there is a tree structure, which means there is only one route between any two leaves.

Yes at each level  you need governance, and trade balances. There's no getting round politics if you think that balancing trade matters.

So your definition of mutual credit would be : giving everybody within the group the same credit/debt range. This is made a rule in the group to which everybody has to obey.

No, the credit/debt ranges can be different for different users. For me what makes it mutual credit is that, everyone uses the same credit. My promise of a dollar is fungible with your promise of a dollar. You cannot discount some members' promises.

With "these other systems" , you mean the mutal credit systems right? Just to make sure, the link was a little loose here.

I think I meant the other mesh systems.

        Decentalising CMB would certainly be an achievement. But does it not remain the case that a full loop must be identified before any trade can take place. And that each loop must consist of hops of equal value?

Not sure about this CMB in detail, but what I am mainly interested in and I think was is the topic of this group are systems which find a loop where the trade can be made possible by intermediatly noting down the IOUS.

So there is no need to find trades of equal value to find a loop.

Sounds like I didn't grok the LedgerLoops documentation well enough.

Hmmmm, yes, but I think to people it can be easier to grasp, this concept of "I have coins and I can spend them". Since often this mutual credit concept with open credit lines is often far off from what people are used to. Especially, those who maybe didn't think about monetary systems as much as you did already.

Cheques!

In the lowest layer the ranges do not need to be specified for the protocol to work.

Do you mean that new users are immediately exposed to the risk of other users' defaults?

        >> Needless to say, coins can not only be minted at the instance of a physical trade. Two parties can exchange and spread coins prior to a physical trade to create liquidity along trust lines.

        >To me this feels less like an extension of the original idea and more like a completely different system. The latter system involves risk which changes everything. The former system is CMB and not interesting to me, so I'm assuming that it is here only as a step on the way to the latter system.

        #In a mutual credit system in my opinion there is always risk involved. The point is you know exactly towards whom you have to face this risk. Ann faces the risk that she will never get something for her apples, she cannot force bob to forward it to people where she needs something. Mutual credit is based on the idea of game theory that players see a benefit of cooperation.

In any money system there are always risks involved. The question is always who takes the risks, who gets the rewards, and how those decisions are made.

        Which system would be of interest to you?

        As I saId, I'm only interested in the latter system, since as I understand it, the former system involves no credit, no liquidity, and isn't practical.

I think both involve credit, and therefore liquidity. It's really just what was the initial incentive to create the credit. A misunderstanding could maybe be my usage if the term coin. But this coin is just a placeholder of Bobs debt. You would prefer cheque maybe? as you mentioned it above.

If you rewrite it with cheques metaphor, I'll look at it again.

Cheers!