User login


Syndicate content
Updated: 4 hours 56 min ago

Mobile phone app for any community platform - latest.

February 22, 2017 - 02:30

In the complementary currency movement most of us have been so preoccupied with our software platforms that we haven't had the capacity to build apps; when apps are built, they are tightly coupled to one platform, making them difficult to share.

Building a mobile phone app means defining an API in which all the objects to be manipulated are described field by field. The app and the server send these objects back and forth, and, knowing the fields, the app can apply the data objects to built in templates to display them. In fact the whole user experience is determined by the javascript css and templates of which the app is comprised.

The different community exchange platforms have very similar data types, and need a similar user experience, but they do have slight differences which means a 'highest common factor' API would be extremely minimal. What's needed therefore is known as a 'self-describing REST API'.

It turns out however that REST is an extremely diverse school of how to write applications. The original specification of REST had everything being self-described, but this was rather cumbersome for projects with very specific functions, and nowadays almost nothing does it the original way, there are no standards and conventions are weak.

So I feel a bit in the dark as I'm working with two volunteers to build a mobile app for community platforms and community exchange platforms. Version 1 will handle 4 resource types, offers, wants, transactions, and members, and the app will know enough about each to provide a nice user experience.

I attempted to define the API on Swagger but realised that what I want to describe is the very abstraction of what Swagger is doing. Each of my four resources have different fields and operations on different platforms, but they are all described in exactly the same way - but what formal language exists for meta-swagger, and do I have time/inclination to learn it, and if I did, is anybody likely to read it?

I've written a small php application to sit between the web platform and the Client, serving up the REST API. Each platform that wishes to use it must extend a base object for each of the four REST resources. Each platform author must defines the resources' fields, handle user authentication, and read and write to its database.

Since the resources are described so generically, additional resources could easily be added, although the client won't know enough about them to make them user-friendly beyond the standard operations of listing, filtering, sorting, creating, viewing, updating, deleting. The platform can also define operations on each resource such as user->contact, or transaction->sign, or blog-post->like, which would appear as buttons on the app, so there's quite a lot of flexibility there.

In fact I'm wondering if this might have wider applications for building clients which simply browse and manipulate REST data. I can't believe nobody else is doing this.

Just to clarify, the long term vision is to disintermediate these web platforms entirely. The politics of community network software revolves around what umbrella groups communities are in and what platforms they have been offered. I'm proposing that eventually the clients (meaning the mobile phone app) would access myriad data services, such as accounting and offers/wants directly, without cumbersome platforms in the middle. Step by step.

Categories: Blogs

Will Tradeswap disrupt Business barter?

February 5, 2017 - 19:44

I've been blogging occasionally about business barter, a sector I would very much like to see disrupted. As a monetary reformer and someone who wants to see an economy that enables trade rather than inhibits it, business barter is the critical tool which is already available and needs no legislative changes.

Yet the sector isn't serving those aims at the moment, being highly segmented and very expensive to use. Disruptive business models are needed to make barter more appealing, more affordable and more scalable.

That's why I've been encouraged by meeting Laurence Anderson in Melbourne, Australia and seeing his life's work, with TradeSwap Laurence has spent most of his career working for various trade exchanges in the region, and only comparatively recently decided to coalesce his vast address book into his own exchange.

Laurence doesn't thrive in the role of manager or owner, and when designing his trade exchange, didn't seek to create a vast dominion and live from the rent. Laurence prefers the role of salesman, and a matchmaker, and TradeSwap is setup to reward those who grow the network and make trades happen. He boasts of having only 20 minutes a month work to trigger all the commission payments, and the rest of the time he's working as a trader.

While Laurence is the main trader on his platform maybe it is academic whether he's paid by commission or by rent. But now he's hoping to bring other traders onto the platform to build their careers. It works like multi-level marketing, so recruiters and matchmakers are rewarded for what happens up to 5 levels below them.

Laurence sees himself as a barter-activist, and that's why he's invested AUD $200K in developing the app on which it all happens to enable anybody to participate on equal terms.

Laurence's next question is how to take TradeSwap to the next level. He doesn't want to be a social media geek, or a pen pusher or a strategist, he thrives on the road doing what he does best. The system will work in any country, but how should Laurence, identify, recruit, train or poach deal makers worldwide when all his own networks are in the state of Victoria?

So I'm wishing Laurence every success. If I had the chance to redesign his system, I would do it only slightly differently:

Politically the network and the software and the intellectual property of the software still belong to Laurence. As it grows across countries and continents, the governance/ownership model is set to stay the same, so it would grow into a massive system under his control. This can be good for quality and branding - he is adamant about transparent accounting and respecting zero balances - but other innovators will be unwiling to build on what they cannot own.

So, as the Credit Commons White Paper explains, I would like to see more emphasis on the development of protocols for interoperability between platforms/networks. A single barter network need not span several countries (several regulatory domains) but can connect to networks in other domains.

If we are to allow the creation of sub networks within a greater barter network, then each sub network needs to have political independence meaning its own bank account, its own conditions of membership, its own rules for setting credit limits and commissions, and crucially, its own brand or reputation. Joining one network or another should not affect who you can trade with but it should affect the risk/reward ratio of participating.

So contact TradeSwap of you are looking to make barter sexy again, to upgrade to a 'mobile first' software, or forge a new career building an economy without money.

Categories: Blogs

'Mutual credit' on Wikipedia

January 21, 2017 - 16:25

I just spent rather longer than I care to admit completely revamping the wikipedia article on mutual credit.

This seemed valuable to me because that idea has been the focal point of my work, and source of much inspiration, since starting this blog in 2008, and I feel it is a simple yet profound idea which is appreciated only by a few money geeks.

In addition I've never seen a definition which satisfied me, rather, people assume what it means, so maybe this article will help some future scholar to better move towards a satisfactory definition!

Categories: Blogs

New interview

December 31, 2016 - 00:35

I've just discovered that the mailing list on my website hasn't been working, so if you receive this by mail, do have a look back at my blog!

In particular I'd like to draw your attention though to two things.

Firstly in considering how to build on my career so far, how to reduce technical dependence on me, and how the whole complementary currency movement can move forward, I wrote this analysis:
Community forge must move on from Drupal!

Secondly, thanks so much to Gary Dykstra, the host of 'Bitcoins in Bali', who just recorded and produced this new podcast conversation with me.

Categories: Blogs

A way forward for grassroots communities.

December 29, 2016 - 23:52
My last post was read with alarm by some fans of Community Forge, but they shouldn't worry I wouldn't close one door without opening another!

While many projects enter and exit the community currency field, the major players move very slowly - since I started meddling in 2004, only a few mild achievements seem worth mentioning.

  • the actors know each other better, in part because we are using the internet better and in part because of a biannual academic conference, and I think those actors have collectively learned a fair bit, though almost nothing of that learning crossed the gulf into the Bitcoin discourse.
  • The major blocs within timebanking and LETS have been mostly reinforced by software; CES emerged as the only global player, but it is by no means dominant, Community Forge emerged in Europe but largely didn't spread beyond Francophones, and small software projects are still manifold.
  • CES has become a network of multiple currencies, spread accross multiple web servers, and using multiple technologies, and for me, is leading the way, yet it receives little attention and investment, and to this day has only one engineer.
and much is the same:
  • I don't feel the movement has grown much while I've been in it, but there's still no data available about that. Even the big networks publish no more than a google map; there's no discussion about what constitutes a countable system, and there's still a tendency to show the largest possible numbers (which are the numbers that require the least processing).
  • Our discourse is still outside even the most radical politics, ignored by classical monetary reformers, hardly understood by progressives. It is neither practised as a strategy for change, not used in the most vibrant economies.
  • Bitcoin stirred a lot of new interest in money, but brought with it a crude Austrian economics; much of the enthusiasm was fueled by unexpected windfalls, and much of the fervour turned out to be about making a quick buck without creating anything of value. Much of the innovation has been sold to venture capitalists.
  • I regard projects like Ripple/Stellar as missed opportunities because they are based on a proper understanding of credit as money, but all their attention is elsewhere, partly because their power is universally overlooked and partly because they need to justify themselves financially.
  • Even as it becomes cheaper and more powerful, technology continues to be a race in which we lag. As I wrote in 2010, the systems we have are mostly old, depending on few and unpaid engineers, and have poor usability.

Some faces from the Impact Economy Summit, Whistler 2015 - See any you know?-->

Greater cooperation between individuals and networks is key. Projects are too focused on their own specific objects rather than continually enquiring where and with whom they can have the most impact. In this talk I explain how my project was in service of so many other projects, and how I had collaborated with several people in the room.

Seen from a systems perspective, money is more like an operating system, than a program, and as such it sits under, provides services to, and connects all other programs! So in monetary networks above all, we must not allow our activism to be circumscribed by specific organisations or networks.

Small, isolated monetary systems are valuing their sovereignty above all other things, including their effectiveness. They struggle to meet operating costs, to produce decent education materials, to develop and host and update and support software, even before any transactions are taking place. And every group, even the larger ones are struggling as I described in my last post.

I can think of only two software projects apart from my own which have attempted to serve the movement without launching currencies of their own, Freecoin and OpenMoney, though neither has any major implementations.

From 2008 I have been arguing and coding for Drupal as a unifying technology for social movements; but things haven't worked out that way. Now not only has the architecture of the Internet changed, but writing software 24/7 is no longer how I want to help!

So I think a lot of the stasis we are facing is because we trying to support such a great diversity of software, all of which is doing mostly the same thing.

From now I'm changing my call. I invite all social movements, and especially complementary currencies to organise around building a modern software ecosystem, NOT a platform which can be owned, but a set of APIs and open source implementations which can be used off the shelf or easily tailored.

This is nothing to do with replacing Facebook, but to support modern life in flesh & blood communities! In this ecosystem payment systems would be just one tool sitting alongside a plethora of other potential services such as marketplaces, event calendar, neighbour alerts, and voting. By better coordinating we can make all of these interoperable, meaning that the services are aware of each other, and the groups are aware of each other without building a monolithic system vulnerable to domination by Big Capital.

I'm aware of projects like Synereo and Fermat, which are focused on building the next internet and learning from past mistakes, but waiting so far hasn't yielded a silver bullet. These other projects often turn out to be too ambitious, or are led in different directions, like Cyclos whose donors eventually walked away and they were forced to serve more conventional institutions. The best way for change-makers and activists to acquire the software they want is to build it and own it themselves.

So here is the actual news: I'm now in talks with Community Forge, CES, Timebanking New South Wales, Mutual Aid Network and others about a new level of cooperation. If you know a community that wants to address these problems in partnership with others, or of a community network that struggles with software, please get in touch.

Categories: Blogs

Community forge must move on from Drupal!

December 20, 2016 - 01:36

Readers less interested in the story of Community Forge may wish to skip the text in grey.

In 2008 grassroots social organisations were (and still are) behind the curve both in uptake and in appreciating the importance of open source. Most local community currency groups were unaware of the software options available and still using paper although migration to online packages was underway.

  • Community Exchange Systems was the largest yet spread only by word-of-mouth, unknown in much of Europe.
  • Most of Scotland was using a sophisticated MS Access package
  • Fourth Corner Exchange was a cluster using instances of the same software
  • LETSlink UK had recently started distributing using a fork of Fourth Corner
  • OS Currency had just started in US, using a Ruby on Rails platform
  • Time & Talents was running on one Timebank in Portland
  • I had written a package, MatsLETS in 2004 but it had never been deployed

In addition the two main timebanking networks in USA and UK were each pouring money into large but inappropriate national web applications to server their respective networks.

Powerful PHP Frameworks like Drupal, Wordpress and Joomla were starting to replace applications coded from scratch, but local groups made software decisions based on the people they actually knew, many of them relying on ageing developers who were not adapting to that new paradigm of collaborative development and modular open source code.

Having just worked with a small NGO in Geneva I had some understanding of the issues that small organisations faced to build and own their own web sites, or rather I should say web applications. While a web site, even a content management system could be fairly straightforward, every organisation, had different business processes and wanted different, which is to say custom-coded functionality. The LETS though, had very standard requirements across the board and I saw that by creating software an order of magnitude cheaper and better I could empower hundreds of community groups and bringing them towards a standardised open source framework which would make future cooperation inevitable!

While the Typo3 guys were snowboarding together, the Plone guys were lost in another paradigm, the community of Drupal developers was very smart, cooperative and the best and most committed people were making good technical decisions. They were building businesses, contributing code as part of the business model, while many were working for the love of it. The range of modules available meant that I could focus only on the accounting (the bit that turned me on!) build a simple directory for offers and wants, and then it was a trivial matter to package the rest of the site. By adhering religiously to Drupal's own standards and conventions, my code would be readable, maintainable and extendable by future developers (paid or voluntary) who would surely come to the project as uptake increased. Build it and they will come, right?

What I really loved was that, once these components were written, Drupal's approach was to provide a vast configuration interface, which meant that the super-user could build a site from modular components without writing code. It was perfect for LETS who often more and less technically inclined people and who wanted a lot of control over their sites.

Drupal is a huge library of useful functions which means you can accomplish a lot by writing a little code. But that little code takes a long time to learn, and if there is a bug, there's a huge codebase to search through. Without the most powerful editing tools (it helps to have a tame sysadmin) or really advanced knowledge of php, I might spend 12 hours tracking down a single bug maybe once a month. It took me 6 months to learn Drupal 6, build my first Drupal site for SEL du Lac, and to deploy the LETS in Geneva. Not bad. Tim Anderson, the chair, and I then founded Community Forge - I wrote the software and Tim worked with other LETS, particularly a cluster in Belgium, to bring them onboard in a way we would all own and manage it. I recruited a friend to learn server management, and together we started to learn how much harder it was to manage many deployments and set up and run and defend, and optimise, and authenticate, and backup a web server.

After about 18 months we were up to about 15 sites and had found a professional volunteer to keep the server ticking over. Much wiser now, I wrote v2 of the mutual_credit module with multiple currencies and upgraded all sites with only a few mishaps. My plan seemed to be working when Timebanks USA deployed about 300 timebanks using my module!

Within days of 2011 when Drupal 7 was released I started work voraciously on the upgrade. It was a big jump, lots to learn. Almost every line of code needed rewriting. I joyously empowered local administrators with new configuration options like a plugin architecture to determine balance limits, spent weeks building an inline transaction form designer, and much more. It was really hard writing the upgrade routines the data for my module, settings for the Hamlets distribution, and all the settings for all the modules we used, many of which hadn't provided upgrade routines, and in the right order! But I was further encouraged when Timebanks UK gave me a verbal assurance they would work with Community Forge to deploy Drupal 7.

By Spring 2012, I had upgraded a handful of sites to Drupal 7 but not very consistently and users were discovering bugs and I was hotfixing an array of live sites, some of them customised, one by one, and just making things worse. But I just couldn't cope. A bug in a mass mail routine led to 3 sites sending not 100 mails, but 10,000 mails and our SMTP provider baulked and cut us off. Phil from New Zealand swooped in like an angel and set us up own own mail sending service. But then one night in Spring 2012 doing more hotfixes on the server I accidentally deleted the wrong directory and all our sites disappeared.

I never wanted to be in charge of live sites; I want to architect and build and fix beautiful things in PHP, but keeping them running 24/7 is tedious work which somebody else should be paid to do! Phil restored the sites in a few minutes but still, it was time to call for deeper engagement from our partner-users. It worked. There were enough donations to pay Phil a retainer, and Marie in Belgium stepped up to test the Drupal 7 version, translate into French, and build a support infrastructure.

Over the next 2 years the team grew to about 3 people who were really meticulous and we worked well together, loved what we were accomplishing and grew to about 80 stable functional sites. Donations increased to EUR3-4K per year, the team took over governance of Community Forge and developed training materials encouraging groups to take control of their sites. Also it was a concern that my work helping the middle classes re-imagine money was still far removed from helping the poor. It had become clear though that however great the software was, LETS themselves still weren't really growing, replicating, innovating or having any economic impact; not very many of them wanted to lend energy to building a global movement or to software. That's why in 2013 I leapt into the Global Ecovillage Network IT team, one of whom had learnt Drupal and single handedly built a colossal ecovillage database and social networking and project-management regionalised multilingual portal, which the network couldn't afford to maintain and was a daunting prospect for any rare drupal volunteer that might come along (i.e. me). Over three years I hope helped with the damage limitation and I kept the thing running until they found funding to migrate the most important bits into Wordpress, (about a year's work).

But that wasn't the only only Drupal disaster going on. Timebanks USA, lacking experience, money, advice and support had had a terrible time migrating and running and fixing their array of sites. hOurworld, an aging, closed source project but with a committed team giving usable Software as a service (SAAS) sites had mopped up hundreds of disaffected Time Banks depriving TBUSA of income and causing some friction between the orgs. I was ready and free and exactly experienced to give myself fully to helping TBUSA move to drupal 7, but the expert they engaged did not talk to me and they took his offer to build them a new system from scratch. At the same moment, Timebanks UK after a 3 year bout of institutional paralysis, lost the money, had hired a managing director who knew none nothing of those promises and accepted an offer of partnership from hOurworld. My plans were in tatters, especially because the timbanking movement had money, while the LETS eschewed money!

I was ready to change direction, but in 2013, that all changed when Karel Boele an Australian activist talented in project management, landed a contract with the state of New South Wales to provide timebanking for five years by upgrading CES into Drupal. CES was monolithic about three times the size of Community Forge, written in microsoft ASP from about 2001, maintained by a respected lifelong activist. I had read his intentions to make it open source and distributed but estimated it would take me 2 years to replicate and migrate to Drupal 7; I hadn't wanted to commit myself to that while single-handedly maintaining Community Forge, and while also wanting to innovate in Business Barter systems and ecovillages and transition towns! But Karel already had a very experienced Drupal developer, who said he could deliver the site in only 4 months! Yay I could help by just doing the mutual credit module but without being responsible! He urged us to go with Drupal 8, which was then in early alpha, and he would help me learn it. So instead of taking a sabbatical year, I girded my loins and started the next version of the mutual credit module.

I was so happy to have a coding partner! We started before Christmas but in the first week of January he had a massive motorbike accident. Over the following weeks it became apparent that he wouldn't return to the project. The back up plan was to hack drupal 7 Hamlets to deliver a multi-timebank solution with maps, a new theme and new stats. The components I already had enabled me to deliver that site, migrated and working pretty well, in five weeks. Thank Drupal!

I spent the next 18 months upgrading the mutual credit module to Drupal 8 two months of which was coping with API changes as Drupal 8 moved through many alphas and betas. But I loved it, great architecture, powerful tools, proper configuration, my faith in the platform was rewarded and strengthened. Hamlets, really a simple distribution was pleasingly quick to recreate!

By the time Drupal 8 launched at the end of 2015, I was an expert. To build CES I was waiting on some critical components which weren't in core. The rules module empowers site managers to trigger actions under certain conditions when events happen, so without writing code, they can do things like: When a transaction happens: If it is in the needlework category If it is the first week of the month, If the payer lives in Anyville : Charge the payee 5% into the Christmas box Send Santa an SMS.

There had been a funding drive for rules, regarded as a critical module, the year before, but I tried a beta and it broke. Similarly the organic groups module, a foundation stone of the CES build and many many sites was way behind the curve. I joined the team on github and found several people tinkering at it, and really striving for perfection, but no visible progress being made. Perhaps they were all too busy in lucrative day jobs? Perhaps in the 7 years since I started all these guys had accrued families and mortgages? I started hearing that the love had gone from drupal. Acquia had been pushing it towards big clients, big money, the newer adopters were not communitarian and wanted only to sell sites using free software, not to contribute back. The tragedy of the commons had been exposed as a myth, yet as Drupal grew, somehow I was feeling more scarcity than abundance. A full year after Drupal 8 was released, these modules are still not usable, and worse, the core upgrade routines from Drupal 7 to Drupal 8 still are not ready. Should I volunteer weeks to inch along these huge projects so reap a little benefit for my users and a lot of benefit for the corporoate takers? The tragedy of the commons. Or should I spend time hacking my way forwards until the tools come, or should I wait while drupal 8 loses its lustre and Drupal 9 approaches?

Another elephant crept in the room during 8 years with my nose in my laptop. The technical pressure and my wish to work on wider money issues has afforded me very little leisure to survey the larger trends communing with other developers. I knew that things were moving to mobile phones and the client side was doing more work, but I didn't realise how web frameworks were being pushed out by this whole new approach. Web platforms which perform all the functions of the institutions which own them are being replaced by a new architecture oriented around users' tiny screens and the short tasks they want to do. Apps are more responsive by doing more of the work on the device, not by bootstrapping a massive application on the server and reloading a page every time they want a bit of data.

Drupal is designed to do everything, handle a request, retrieve data, skin it and deliver data. I'm still trying to preach to hOurworld about the separation of concernes into modules in a lovely framework, and wondering if some of those module might be more universally useful as web services with REST API interfaces. Meanwhile the framework itself is being obviated by a separation of greater concerns. The user's device now manages all user interaction by pulling specific pieces of data into an app instead of requesting web pages; authentication and identity can be done by 3rd parties; and data storage is done using web services like Couch DB.

Drupal is finding more uses in mega institutions, not in NGOs. 8 years of full-time engagement enable me to cope with its complexity, but none of the volunteers or institutions I want to partner with have the knowledge or resources to own enterprise-grade software. In 8 years, not one volunteer has contributed code to the accounting module or to Hamlets. While we are wed to Drupal, Community Forge relies absolutely on my special skills. To replace me with a team in India might cost thirty times more money than we currently receive in donations, and we would still be isolating ourselves technically.

Time to pivot. We have come far by building software ourselves without concern for fundraising. But we risk not only creating an impossible dependence, but also becoming irrelevant as we rely on too narrow skill sets. Drupal has helped a lot, and is still IMHO a great web platform for grass roots communities who have those skills; It would be an option for us if our movement were better aligned; but now the tide has turned; in order to stay technically relevant, engage volunteers, give a better user experience to module phone users, something else is needed!

Categories: Blogs

Which way forward for the Credit Commons?

December 14, 2016 - 00:48

I'm honoured to say that the idea I first formulated is growing bigger than just me, and there are some strong supporters with various skills and connections. I've made it clear to them that I don't really know how to go about building and promoting a new economic system apart from doing what I'm doing slowly building the software for existing networks. I don't know how to leverage their skills and connections, I don't know what tasks need doing, how to raise money, how to craft messages, how to bring people on board. So far the best plan I have produced is this list of kinds of help needed:

  • Fundraising
  • Amplifying the idea in academia
  • Amplifying the idea in social media
  • blockchain development
  • explaining with a video
  • Education about money
  • building a 'viral app'
  • networking to involve more complementary currency projects
  • disrupting the Business barter industry with a new, open model

The problem is that such a list as this isn't very actionable, for volunteers. My inclination is to lay out the scope of the work and invite people to bring whatever they want to it - to be creative and free with it. But this isn't working - would be volunteers aren't seeing in that list either anything which inspires them or anything they can reasonably do - some of those are very big items! If I get more specific about tasks, then I end up doing volunteer management which hasn't worked out for me in the past.

So the credit commons slack channel where we've enticed over 30 people isn't the appropriate tool at the moment. We have a small core team which should coordinate privately while sharing progress publically.

Here are the short and medium tasks for the core team:

  • Learn about appropriate technologies
  • Encourage academics to write
  • Build relationships with business barter networks i.e. Sardex and RES
  • Build relationships with a region with overlapping CCs, eg Catalyunia / Lac Leman
  • Inform existing alternative money educators and users about CCommons ideas
  • Seek money to support the above activities
So how do we build a movement? How do we design, develop, implement, and promote a new protocol, not only for payments, but for trust itself? What are the precedents and patterns we might draw on? How much we learn from Bitcoin, a movement whose strength derives very largely from speculation of its currency, which is antithetical to everything the credit commons intends? Could it all depend perhaps on the right person coming along to coordinate, plan and extrapolate these ideas into doable tasks?


Categories: Blogs

3 lessons for Bitcoiners from an old school monetary activist.

December 13, 2016 - 23:11

This week I was honoured to be part of the Money & Society Summit, organised by Jem Bendell. It was a chance to bring some unusual monetary thinking to newcomers and especially some Bitcoin enthusiasts who have a stronghold here in Bali! During the final Panel, Gary Dykstra, host of the Bitcoin Filter, asked the panelists, me included, what the Bitcoin movement could learn from its elder sibling the complementary currency movement.

I was happy to hear this question because for the last six years I have watched as cryptographers, teenagers and business people have grappled with monetary ideas, and applied limited, simplistic and sometimes just wrong thinking to the task at hand. Money is a social technology and has been thoroughly explored throughout the last 2 1/2 Millennia and understanding it goes very far beyond the simplistic revelation that modern money is 'no longer' 'backed'.

In fact it took me a couple of years to reach my own understanding of what Bitcoin was; to untangle the rhetoric, the dogma, the technology. To me now, Bitcoin seems very close to a fiat currency, especially in the way it comes from nothing, to circulate indefinitely, and thus is viewed by the market as a commodity, making its price ever subject to the whims of supply and demand. That volatility discouraged their use by people who actually wanted to make payments, which meant that in practice Bitcoin wasn't for the most part performing the most important function of money.

1. A social technology has to be governed.

With bank-money and legal tender money, the bank and government are needed for the currency to function and hold its value. Abuse by those institutions can lead to the erosion of your savings money. Bitcoin allowed no such abuses, all the coins being released according to a predetermined algorithm and not being subject to political interference. Furthermore users held their own Bitcoin wallets rather than trusting banks. Thus is was said to be trustless. But the trust was simply moved away from the known entities onto more nebulous entities. Never mind that natural market movements invite manipuation and redistribute wealth all over the place. You could own your Bitcoin but you still had to trust that the market would be liquid when wanted your dollars back, and that the miners wouldn't collude and that the algorithm was secure, and that it wasn't secretly a black Pentagon project!

The Quantitative easing that Satoshi Nakamoto so deplored certainly was an abuse of the currency, but it was also (and still is!) a desperate short-term measure to prevent the economy imploding. A deeper analysis shows that abuse of power was not so much in the government printing of money but in the systems of private bank credit creation which inflated the original bubble. History shows that banks find a way to do this regardless of whether the currency is said to be backed.

Another approach to the problem of financial institutions losing our trust is to build new institutions which would have to earn our trust rather than granting them legal privileges which give us no choice but to trust them. Removing trust from the monetary equation also removes the ability to negotiate, to respond to real-world circumstances, to make certain kinds of corrections or management decisions. Better to make social arrangements which actually reflect where trust exists and which reward socially beneficial behaviours.

2. Most payments in history and indeed now are made using credit. Money is only used for settlement.

Aristotle and David Graeber tell us that the right and proper use of trustless currency (gold) is when trading between jurisdictions, or in war, when the value of the state's money is questionable, and deferred settlement might not be possible. But trustless money is by nature posessed commodity, and if you don't already own it you must pay to borrow. Within jurisdictions where there is law or even trust, credit-money is a much better option because it is elastic, free to issue, and its value can be adjusted by the government to suit the needs of the economy. Credit is extremely divisible, transportable, measurable, and here's the smart part: parties who are both buying and selling need never handle money because the credit cancels out to nothing and no payment i.e. troublesome movement of a valuable commodity, is required.

3. Understand that accumulation necessitates something valuable while exchange only needs accounting.

There's an assumption or maybe a definition in economics that in order to be money, a thing has to perform the three functions reasonably well. But before the Bank of England these functions were rarely collapsed into the same financial instrument. Ideally a store of value should be valuable, like a house or a lump of gold, or a business or many things. It doesn't have to be very liquid. Conversely insofar as we can say that the economy is about exchange, a great many transactions can be cancelled out against other transactions and a valuable currency becomes a burden. Further, a currency that really encourages exchange will decline in value over time to encourage it to be spent and not hoarded. A store of value needs to be somewhat scarce and desirable, but a medium of exchange needs to be sufficient and available when needed, which strongly implies credit. In trying to fulfil all these functions, Bitcoin and its clones replicate many of the problems of fiat money, doing none of these functions well. I wrote more about this in OpenDemocracy.

Finally it seems to me that the main reason for Bitcoin's meteoric initial success was the way it made its holders rich as the price went up. Not then because it was a good currency but because it was a highly volatile investment which made a few geeks unexpectedly rich. As a money geek coming from a different tradition, I want to see less exciting monies which are stable in value because they are adjustable in quantity, and which are of no interest to speculators. To me, a currency that piles up instead of flowing is not a currency and is not serving the economy at large.

That's why I encourage everyone who is serious about building a better money system to look at mutual credit systems, which is the accounting philosophy behind the business barter systems and LETS. Also have a look at my proposal to use mutual credit on a blockchain to build a new financial system from the bottom up, called the Credit Commons, which I briefly describe in the talk below.

Many thanks to Stephen de Meulenaere for producing the video.
Categories: Blogs