little big cookie shake

[keturn]

I've been spending a lot of my attention on alternative currencies lately, driven by an interest in the Portland Timebank community and partners. I've been in some discussions lately about different directions the timebank might develop in, and some of these conversations have succeeded in challenging enough of my assumptions about economies that

Comments

[pmb]

Your confusion in large part also mirrors a confusion that actual economists had until they started actually measuring these complementary currencies. You give all of these examples of how one might collude or cheat or otherwise-weird-up the system, but all of these things also all have social pressure not to do them. Previously, it was thought that money was a neutral carrier of value, and, while there were exchange rates between currencies, the upshot was that there was no difference between buying something in dollars versus euros versus local-exchange-time-hours. It turns out that this is false. For reasons we don't understand relating to human psychology, we treat different currencies differently. The best example of this is the studies regarding the Japanese time-banking system for elder care where people could pay in time-hours or in yen, and weird things happened.

This also means that different currencies have different in-practice problems, despite the fact that any reasonable mathematical model would treat all of the currencies as the same, and therefore the only problems "should" only be related to things like the size of the monetary base of each currency. The models that we intuitively make seem to be in-practice incorrect. http://www.predictablyirrational.com/?p=317&date=1

[keturn]

This largely mirrors what our local PDX Timebank ringleader says when she sits down with a few of us software engineers. We say "but there's this attack vector here and what about this and that and the other thing," and she says "yeah, but... I've never seen that actually happen."

So I guess in this discussion I'm trying to find out two things:

1. 
   How do I explain the system so that geeks are willing to trust its integrity.
   
2. 
   What elements are important to encode in the software? Do we need strict control of account provisioning, do we need a hard limit on negative balances, do we need people's balances or their transaction histories to be viewable to the rest of the community, etc.
   
   Because a "anyone can do any transaction at any time" platform is, if nothing else, much quicker to write. ;)
   

[pmb]

I would be very nervous about instituting this in software. We relate to physical things much better than numbers on a screen. People aren't willing to steal currency, but usually are quite wiling to be dishonest about numbers or to take small items from work. Use physical tokens is my advice.

This smells of attempting to use technology to solve a social problem, which is generally not the right thing unless you know both teach and people at a deep intuitive level. If I had to implement it, I would go for maximum transparency and utility and allow any transaction at any time, but also allow rollback by either party at any time. Make it a wiki of fake money, and give it the same robustness that a wiki has - it can be attacked, but the damage can be easily undone.

No geek will trust it until they see it working for a few years. Even then, they will delight in pointing out how it is unreliable and can be attacked. Hardcore security nerds still say that *Wikipedia* should be 100% untrusted, despite the fact that it contains more material at a measured accuracy only slightly behind the Encyclopedia Britannica. No geek will intuitively trust this system unless they are also already either a wiki-type or a hippie or both. And even then they will probably want more technological controls than is appropriate or good.

[pmb]

...know both teach and people...

know both tech and people

a wiki of fake money

[keturn]

the name WikiWikiMoney has been claimed by the Twollars people.

[freyley]

For an answer to 1, I would say you should point to Bruce Schneier's comments on credit card security and fraud. transaction authorization and compliance. And build your software from the point of view of changesets.

social pressure and the monkeysphere

[keturn]

also, how do social pressures change with questions of scale? Do the same systems that work with a local elder care community work if we scale it up to the thirty thousand people in the Woodlawn neighborhood? Does it work with the half a million people in the city of Portland? Does it work with 85 million ebay users?

Re: social pressure and the monkeysphere

[pmb]

Nobody knows. Anyone who claims to know is either a researcher in the field or a liar or both. At least, nobody knows the answer to YOUR question. People and groups thereof tend to generalize very poorly.

What is known is that big is different in kind from small. Solutions for large are usually incorrect for small and vice-versa. My mom knows all of the baggage checkers at her local airport (which operates only 3 days a week) and yet they still check all her luggage and make her take of her shoes and everything else. What is appropriate at a large airport is ludicrous at a small one. The most important thing to understand is that there are no known "laws of people" like their are laws of physics or principles of program design. People are hideously complicated bizarre nonlinear things.

http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development