Network security

Possible frauds in a mutual credit clearing network
The most important features of a mutual credit clearing network as far as fraud protection is concerned are:
1. The fact that every trade credit is accounted for and remains at all times on the ledger. For one account to receive a credit, another account must incur a debit.
2. The fact that the network is comprised of many relatively small nodes (communities, local exchanges, or affinity groups) organized in hierarchical layers. The nodes at the lowest level are comprised of entities (persons or enterprises) who know each other through personal contacts and relationship history. There can be no anonymous accounts. Admission to membership must be by referral from other current members.
3. The nodes on each level of the hierarchy are co-responsible, meaning that the costs and other negative impacts of errors or fraudulent transactions remain at that level. At every level of the hierarchy, credit lines are limited, based on an appropriate credit allocation algorithm. Thus, the accounts of individual or business members each have a debit limit, each group has a debit limit, each cluster has a debit limit, etc., on up the hierarchy.
In every instance, as debit limits are approached, corrective action is taken to help rebalance purchases against sales.
¬¬¬
Consider a few possible scenarios.
A. Members collude to make fake transactions for the purpose of pumping up their trade volume stats and boosting their reputation ratings.
How far could they go with this before it becomes apparent to others on the same level? If there is proper administrative oversight and regular audits, it would quickly become obvious that something improper is going on and action can be taken to correct it.
B. A member wants to sell trade credits for fiat currency. The incentives for doing so depend upon the scale and scope of the network and the quality of trade credit allocation and management. Each of these factors determines the value of trade credits relative to fiat.
If trade credits have a value close to the value of fiat there will be little incentive to sell trade credits for fiat at a discount. However, a member may have an urgent need for fiat to pay taxes or to acquire some necessity that is not available within the network, in which case he might be willing to sell trade credits. But, is that a problem? It could be if that member is in danger of becoming insolvent and leaving the network with a negative (debit) balance. However, such “bad debts” might be recovered by means of customary collection procedures. Commercial trade exchange agreements typically contain a provision that outstanding debit balances can be collected in fiat via a charge to the member’s credit card. If collection efforts prove unsuccessful, then the balance will be written off against an insurance “fund for bad debts” that comes out of the revenue stream of the layer in which the defaulting member is contained.
Further, since debit balances are limited by the credit allocation algorithm, and the algorithm contains factors that relate to a member’s solvency, the loss would not be so great as to endanger the network.

See attached file

I can think of other fraud vectors, but in this holarchy all risk is contained by the people taking it. Even if you set up many groups, they can only cheat each other and those who trust them directly.

Even if ledgers were tampered with, the only people affected are those on that ledger, who are ultimately responsible for it, and to a lesser extent the immediate peers of that ledger to the extend they gave it credit.

Such tampering would be difficult to repeat as it would be provable and the reputational damage would be indisputable.
And if you could somehow steal a lot of credit, you would have difficulty spending it far from home because of the capital controls, and difficulty being anonymous.

It could yield more insights to think like a banker and consider how the rich could leverage a credit commons to their political and financial advantage. Rich entities would still be able to work together and grant each other more credit than poor entities, as in capitalism; the best way to obtain money for nothing might be to create fake ventures, sell shares and then not deliver - as in capitalism.

The only think I'm concerned about is the wrong people getting control of the high level groups and it being institutionally difficult to up competing groups, as it is difficult to imagine a competitor to the dollar as global reserve currency today. There might not be much we can do about that, but Dil's plan to create and control those top level groups now, seems smart to me.

The only think I'm concerned about is the wrong people getting control of the high level groups and it being institutionally difficult to up competing groups

Would it help to structure the system as a horizontal network of groups instead of a hierarchy of groups, security wise? I'm no security expert, but it seems like then it all becomes more like you describe earlier in your last comment @matthewslater :

Even if you set up many groups, they can only cheat each other and those who trust them directly.

@lynn, I would say that that heirarchical structure is fundamental to the credit commons design and that security and governance has to work under those conditions. My philosophical stance is that political power should follow the credit power, and therefore come from the bottom. If we give the groups the tools to govern themselves we can't stop them selling themselves down the road.

There seem to be three ways in which we need to think about these issues. Perhaps we can agree a terminology as follows:

• Security: measures to prevent access to data/tools, for malicious/selfish purpose. This is largely a systems design issue. Often, the focus is on the software and rules involved. In practice, it is usually the human interfaces with such mechanised parts of the system that are the most vulnerable.
• Fraud Minimisation: measures to reduce opportunities and rewards for dishonest behaviour for individual gain. Here, systemic design is important, but the problem is predominantly social.
• Defense: measures to neutralise attacks by those wishing to reduce the viability of the network as a whole. This is a category not often considered, except in paranoid blockchain circles.

Comments above regarding Security and Fraud Minimisation seem reasonably strong and well thought through, with one proviso - they are mostly predicated on human-scale networks in federation (on which more later).

So of the three, I consider Defence to be the least robust, for a simple reason. Even a minimal economic level of impact - we talk about 1% of SME turnover being carried by the system as a proxy for such impact - would be of immediate concern to banks. Because banks have relatively high overheads and fixed costs, a transfer of 1% in credit issuance to an alternative system that is growing fast will attract strong retaliation (1% of a sector in Mutual Credit turnover is not a direct, marginal 1% reduction in lending to that sector, but seems likely to be closely correlated, with a coefficient not far from 1).

What is the likely structure of such attacks? I suggest three categories:

• Denigration: painting Mutual Credit as a hotbed of fraud, as inefficient, as expensive, as bureaucratic, as dangerous, as naive bullshit, as idiotic economics, as impossible to scale.
• Disruption: funding competing networks / network hierarchies that undercut prices, imposing commercial penalties on firms that participate (through loan conditions, pushing them to bankruptcy etc, on the basis of 'concerns about increased risk of insolvency'), supporting trading in Mutual Credit Units outside the network, encouraging 'shorting', encouraging 'carpet-bagging' (supporting members who suggest that networks sell themselves to banks - demutualise for short-term gains).
• Systemic: urging regulatory investigations and impositions, and pushing for legislative changes that undermine key aspects of Members' Agreements.

I haven't spent too long thinking about this list, so I imagine there will be many other attacks. We have seen attacks on blockchain in all these categories, so this isn't fantasy.

One point that comes up again and again in this conversation is the inherent resilience and resistance to disruption afforded by having human-scale, trust-based networks as the fundamental unit of the system. This is fundamental, I agree.

But it cannot be taken for granted. The same was true of the co-op movement in the C19th and early C20th in the UK, but in the face of attacks and challenges in several of the categories mentioned above, it amalgamated and lost any local focus. It is important to note that this process of amalgamation, though controversial at the time, appeared to serve the movement well in terms of immediate benefits over a period of forty years, and is in fact still prevalent (the UK's only telephone provider co-op ceased to be independent this year, amalgamating with the largest UK regional retail co-op).

There is no automatic limitation on network size; I cannot imagine a sustainable governance mechanism that should/could impose such a limit (the 'right size' will vary widely across contexts of 'local'). One robust mechanism is obvious - that maximisation of trust will provide a push toward optimal sizing. But this is only one mechanism, and it does not act quickly or in an obvious way - trust is an emergent system property, not directly measurable. One could easily imagine robust capitalistic management providing an equivalent experience from the point of view of an average SME member - particularly if it were being well-funded as a disruptive operation.

There is no reason to suppose that members who are primarily concerned with maintaining a viable small business will make large political waves about the amalgamation of networks, or other technical rule changes in a system which is unlikely for most of them to provide more than a marginal benefit to operating cost and cashflow. The UK co-op movement chose safe viability over any chance at system change, even though it started with explicit political consciousness.

Although this is a largely gloomy assessment, it should be noted that all of these issues are in the 'nice problems to have' category - if we are seeing such attacks, it will be because the project is working.

The real issue we face is that an obvious strategic choice is to be 'agile' and 'lean' about this - to address such problems as they come up.

This is the fashionable approach to everything these days, for all sorts of good reasons. But fashion is a terrible reason to do anything - what really matters, of course, is style.

Style is the capacity to make high quality choices in situations where there are no rules - and good agile teams know this. In pursuing an agile approach, you need to value wisdom, experience and forethought, even while sticking to a stepwise, learning mode approach.

If we are taking network security seriously, we need to make good early choices in relation to the full range of threats to the viability of this project at every stage.

Sometimes, the high quality choice will be 'not to worry about that now'. but it should be a conscious choice, revisited often.

Good thinking going on here :clap: Just a link across to another thread . . these are all matters of commons stewarding, basic considerations for the Credit Commons Protocol Foundation (equals the commons 'court'): see the assets licences governance thread. I made a comment elsewhere which Dil hasn't posted to that thread yet, regarding the constitutive practices of commoning. Rather than the G-word (governance), the foundational practices are Curating (continuous labour of constructing and contributing to the commons, by commoners) and Stewarding (continuous labour of policing, repairing, confronting malicious elements, pollution-handling, forceful defending, by commoners). When that comment has been posted, I'll link it here.The point is, these are not network matters, they are commoning matters. Network/code is a tech subset.