Sat, 07 Feb 2004
One objection to email fees is related to email viruses: if every email you send costs a cent, and you get a virus that sends out 20,000 emails you’ve just lost $200. That sucks. Fortunately, that’s straightforward avoidable by limiting the amount of money your computer can access without your authorisation (by way of password, eg). If you limit the amount of money your computer has access to to $5, that’s 500 emails you can send before you have to worry about recharging your account (more presuming you get sent some emails), and if you do get infected by a virus, you only lose $5, which is a nuisance, but not a big deal. Odds are you lose that much in time anyway. And even better, instead of sending out 20,000 emails, you’ve only sent out 500, reducing the problem globally.
There are other protection measures you can use too. If you’re in an organisation, and you don’t want your 1000 staff members all losing $5 at once to a virus, you can setup your mail server to require manual authorisation if anyone tries sending more than a couple of emails every few minutes. That’s possible now, of course, but there’s no reason to do it: it doesn’t stop the organisation from getting infected by the virus, since it already is, and it doesn’t much matter that other people get infected. By moving the cost onto the sender you setup an incentive for people to start using email programs that are resistant to email viruses, and to setup procedures to ensure that even if they are infected, that they don’t cause problems for everyone else.
Martin responds to the above post (without permalinking, tsktsk), and makes a couple of points. One is that it opens a new avenue for insecure monetary transactions -- in this case from your bank account or credit card company to your mail client's moneybox. If that avenue is too easily accessible it'll be exploited by tricksters. I don't think that's a major concern because it doesn't have to be easily accessible: most of the time you're going to be aiming to come out square in the email fees you send and receive; and given that the amounts per email are so small, you should only be expecting to withdraw a few dollars a month. Having this be a fairly automatic part of your ISP billing cycle (and thus out-of-band as far as trojans and viruses are concerned) is also possible, for example.
Martin also writes:
Another way to produce that backpressure would be to sue or prosecure someone for negligently continuing to transmit viruses. I think it is fairly clearly negligent to send mail; it might even be covered by existing computer crime legislation.
Coming from someone whose Orkut profile lists him as a "libertarian", this seems odd -- resorting to legislation and police intervention is pretty heavy handed; and doing so when solutions that only require agreement between consenting parties haven't even been tried seems quite anti-libertarian, at least as I understand it.
The obvious problem with legislation is that it's slow, not very reactive, and by it's nature is a one-size-fits-all solution. For things like spam, where different people have different classifications of what's a problem and what's not, it'll never be a good solution. If I don't like real estate agents sending me mails just because I talked to them once a year ago, a legislative approach isn't going to help me, because it would hurt both the real estate agent, and the people who are interested in getting those emails.
Martin's final remark is:
So we only need to worry about high-volume senders. Most people won't need to send more than say 100-200 emails per day, and it would be a good start to cap dial-up/DSL users to that. Perhaps organizations which do need to send in large volumes should pay a bond to some kind of underwriter.
(This comment is in reponse to the claim that email postage is free as long as you send less mail than you recieve; which implies that if the spammers find a way to work around this and keep sending you spam, at least you don't lose out; otoh if you are losing money, then you've also managed to substantially decrease the amount of spam you get. ie, you can't lose! In theory, anyway. I don't think Martin's comment follows from this, because it assumes we already have email postage. Maybe I'm misunderstanding, though)
Anyway. 100-200 emails a day just means you need to infect 10k machines to send a million emails every day. If the owners of those machines don't really care about that -- they're not losing their money and their computer is still working fine, eg -- then that ought to be relatively easy, so it's questionable whether the problem would actually be solved. Paying a bond to "some kind" of underwriter, meanwhile, makes a system that's only useful for a few people (and thus doesn't get many network effect benefits), and opens up similar scope for monetary abuse: either getting funds by claiming to have gotten spammed by one of the bond payers (possibly after trojaning their systems yourself), or simply depriving the target of funds (by convincing the bond holder that the group is a spammer and causing them to not return the bond).
The real benefits of email postage compared to other money-based solutions is that it's broad-based and fair (no one has to worry about following a different system to anyone else, which is a nice equalising property of the Internet that's worth retaining, and there aren't areas for big businesses to position themselves so they can extort money from users); that it is implementable entirely at the endpoints (you just need to upgrade mutt or Outlook, you don't need to change ISPs), that it's flexible (you can change the fees you expect depending on who the mail's from, who it's to, or what it's about), and it has very few external costs (you don't need to reimplement the internet, you don't need to create a new police taskforce, or put more cases through the courts, or add lots of new restrictions to ISPs -- basically it has the property when people don't follow the rules, you just don't get their mail, you don't get hurt and have to seek a remedy).
The Gnu Hunter writes:
Yahoo and Microsoft are looking at ways of imposing a postage fee for emails as a way of reducing the ever increasing number of junk emails or spam.
No, Yahoo and Microsoft are looking at ways of making more money by charging for something that was previously “free” and are using junk mail as an excuse to do so. They will only impose this charge if they can impose it.
[…]
40% of the many millions of emails sent each year are spam mail. Whoever could tax it would be worth a fortune. Whoever reaped the tax would be very reluctant to eliminate spam. Spam would be here forever. It would be renamed to non optional business marketing or some such.
I’ve thought about similar things to what Microsoft are proposing, and been met with similar criticism trying to discuss it. Criticism’s fair enough, but this criticism is, I think, terribly misguided.
First, I’ll note that the response isn’t a rational one. There’s two ways of responding to ideas you don’t like: one is to say it’s got evil outcomes, the other’s to say they’re inspired from evil motivations. The former’s a sensible thing to analyse, the latter is both impossible to know and useless to boot. Gnu Hunter’s rant is entirely attacking Microsoft’s motivations, rather than analysing what harm it will do, or what good will be obtained. So it can be dismissed on that basis.
But the motivation being attacked isn’t one that you’d expect a rabid right-winger to attack: it’s the profit motive. The argument’s one that left-wingers make regularly: that a good service, which is currently readily available and effectively free to use, is going to be taken over by evil corporate influences, made unaffordable and otherwise ruined, all in the name of the unholy dollar. Compare Gnu Hunter’s remarks with “The Government’s looking at ways of making more money by charging for University places that were previously free, and are using the current funding crisis as an excuse to do so”, for example.
The real flaw here, I think, is due to a knee-jerk fear, almost a loathing, of money and the profit motive. Not an unjustified one, perhaps, but rather an unjust one.
Going through the post above in too much detail is a bit cruel – it’s presumably intended as a dashed off comment, not a thoughtful response – but I’m going to do it anyway. The first claim is that Microsoft “are looking at ways of making more money by charging for something that was previously free”. Is that bad? One of the big things that’s happened in our culture recently that I find terribly amusing is the sale of bottled water. Tap water’s perfectly drinkable in most places I go to, yet I quite happily shell out a couple of bucks for a bottle of water every now and then. Why? Mostly because it’s convenient, it’s cold, and I’ve got a lot more confidence it hasn’t been spat on, urinated on or thrown up on recently than I do with most bubblers around the place. Sure, it used to be free, but now some company’s making money off me for the privelege of having a drink of water. Actually it still is free – they’re still plenty of bubblers and taps around and as far as I know you can go into most cafes or pubs and get an glass of water without too much hassle.
The next comment is that Microsoft “will only impose this charge if they can impose it”. Except, well, they won’t do anything of the sort: if you want to keep receiving spam, and people want to keep sending it to you, and your ISPs don’t mind either, there’s nothing Microsoft can do to stop you. There’s no chance of anything being imposed against your will here at all. But chances are you don’t want to keep getting spam, and your ISP doesn’t either, so that one or both of you will be eager to play ball if it actually works out. Worst case, you can switch to using competing email software, and avoid whatever Microsoft and your ISP might try to conspire to get you to do. So this case is much the same as for bottled water: maybe there’ll be a pay-to-play option, but anyone who doesn’t like that can always keep using email exactly as they do now.
Another comment is “whoever could tax [spam] would be worth a fortune”. Well, that’s kind of true: governments are already doing that by income tax on the spammers, and by most standards, governments are worth a fortune. The real issue isn’t taxing spam though; it’s annihilating it; if the only way to do so is via a new tax, well, so be it. One way, possibly the only way, to stop spam is to increase the cost of sending an email to more than the value of a spam. The value of a spam is very small – it can take millions of them to get up to being worth a couple of hundred dollars – but the cost of sending an email is far smaller. If you don’t increase the cost of spamming (either directly like Microsoft are attempting, or indirectly by having stiffer laws or terms of service and stiffer penalties), then it’ll keep getting sent, and your only option is to try to get your computer to filter it out once it’s already gotten to you. That works, but it doesn’t work well.
Now, there’s an interesting conundrum here. Increasing costs is fundamentally evil. It’s inconvenient at best. By definition it’s wasteful. It goes against our drive towards efficiency. But if it’s the only way of stopping spam, there must be some good in it.
The trick is that we’re not trying to increase costs globally; we’re trying to reduce them. The particular costs we’re trying to reduce are on the reciever: the cost of anti-spam software and services, the cost of lost mail due to false positives when checking for spam, and the cost of wasted time and computer resources in dealing with email you aren’t interested in that nevertheless makes it through your filters. What we’re thus trying to do isn’t increase the costs, but shift them onto the individuals getting the benefit from spam, ie the spammers themselves.
In a sense, what that means is that we’re not talking about increasing the cost of sending an email, but rather increasing the price of sending an email. The difference is very subtle, but it’s important. Increasing the cost increases the friction in the system: it means that more time and energy and resources are being lost than is necessary. Increasing the price does not. If I want you to bake me a cake, and you say you won’t unless I spend an hour digging a hole in the ground, then fill it back in again, then that’s a cost. If you instead demand an hour’s wages from me, that’s a price. The difference doesn’t matter to me, but it does matter to both you and the person for whom I did an hour’s useful work. You because you know have some money you can use, and my employer because they’ve now had their garden hoed.
The logic is simple: if the number of spams to be sent is to be reduced, then the cost of sending spam must be increased. If the cost of sending spam must be increased, then spammers must either devote more money or effort to sending spams. The only question left is who should benefit from that extra money of effort: Microsoft, the government, the recipient of the spam, or the dread lord Entropy?
At the moment, it’s the recipient who pays the most – in wasted time, and in unnecessary annoyance – and entropy that does all the collecting. That’s doubly bad in my opinion. The technology to do this right, to have all the costs borne by the spammer, and any excess benefits accrue to the recipient, and to ensure the energy and effort expended and lost to entropy in sending a message remains minimised, already exists. It’s called money, and it allows the spammer to encode efforts and work she’s done in the past in an easily transferred form, and give that to someone else, who can than decode it into effort and work that he in turn finds valuable.
And yet, the possibility that money may become involved in something previously pecuniarily pristine is enough to inspire fear and horror in even the most educated and rational.
I find that really rather bizarre. But it’s nevertheless nice to see
it in an avowed apparent right-winger: sometimes the
differences between left and right seem far less surmountable than they
have any right to be.
(For what it’s worth, the economics here seem to make sense: the cost of looking at a spam’s subject and sender and deleting it without actually reading it seems to be about a second for me, and at $20/hr, that amounts to about half a cent per email. Charging the sender half a cent per email is noise for most people (I send a fair bit of email, and it’d cost me about $2/month), and in any case can generally be made up from the profits you make receiving email. But by contrast, for spammers, it’s bankrupting: they’d need to pay me well over $300/yr to send me what they send now; email viruses would net me another $200/yr at the current rate. With a little care – less than goes into dealing with spam filtering rule sets, by my estimation – most of the obvious problems, such as mailing lists and server load, can be dealt with to at least not be significantly worse than they are now. While some new external effects will no doubt be introduced, all the ones I can think of encourage good trends over the long term.)
Maybe a good way of looking at this is thus: email postage is free to you as long as the number of emails you send is less than the number of spams you receive.
Tue, 04 Nov 2003
Some more thoughts on this topic.
Ecash is actually something of a distraction in the description; there’s no particular need for people to be able to do anonymous transactions, or to transact without talking to a central market – so you can do this just as effectively with market accounts. In that case, it makes more sense to call the “bids” contracts: initially you buy, for a dollar, two contracts: one that offers you a dollar at a certain time if something doesn’t happen; the other offers you a dollar when something does happen, as long as it happens before that certain time. We’ll call these “lose” and “win” contracts, where “winning” is when the feature gets implemented.
So far, we’ve really only dealt with half the problems of financing free software: ensuring users get a fair deal for their money. That’s important, because the money has to come from somewhere, but that’s only useful if it goes somewhere too. If people put up their money, and don’t get anything back but they’re money, they’re sensibly going to stop wasting their time and go do something useful. And so far we’re requiring software developers to have a fair chunk of capital up front that they can invest in themselves. That’s nice and all, but most free software hackers aren’t all that cashed up (which is the problem we’re trying to solve here after all!) so it’s not terribly realistic.
One of the questions that most annoyed me about the Wall Street Performer Protocol and that still annoys me here is the issue of giving the winning contracts to people. If you charge for them, then you necessarily preclude all the poor starving hackers from being able to participate; but if you don’t charge for them, the poor starving hackers will have an incentive to just sell them immediately for the going rate (5c each), so they can eat. Both of which kind-of defeat the purpose of this. One way of dealing with this is probably to give out options. Say the current market value of a win contract is 5c. Say you have a friend who thinks he can implement 50% of the feature in a couple of weeks, and that that should raise the market value to 40c. Say you’re willing to invest $500 in this feature. Then what you can do is buy 500 win+lose contracts, and offer your friend an option to buy as many as he likes in two weeks’ time for 7c each. If all goes to plan, the feature gets half implemented, he exercises his options, by giving you $35, then sells them at the market rate (for $200). If things don’t go to plan, you still either get your $500 back, or your feature implemented; and your friend doesn’t have to invest any of his savings or run any financial risk.
The key point here is that if the current value is 5c, an option to buy at 7c is (almost) worthless; so you’re not actually giving anything of value away. But if you give that option to someone who can increase the value of the contracts significantly, and they do, then you win (because you got 7c for something that was only worth 5c) and they win (because they get to buy something for 7c and sell it for 40c). And you both win again, because you get your feature half implemented, and they get to spend some time doing some fun coding. This further means that you don’t have to worry as much about giving options to people you trust – since the option is worthless, they’re not going to be able to make any huge profits just by immediately reselling it. This at least gives you the possibility of dealing with people that you don’t know, without them having to put up some capital in the first place.
There’s no conclusion here, just some thoughts.
Sat, 18 Oct 2003
Martin notes that:
One fairly silly argument sometimes advanced against Linux is that by reducing towards zero the cost of getting a good operating system, it is somehow communist or anti-capitalist.
He’s right: people do make that argument, and it’s silly. It’s especially silly because people already do it for a profit, and even sillier when you realise that there isn’t even anything anti-capitalist about charity. And it’s even sillier when you note that Linux and open source have demonstrated that they have a viable business model: there’s plenty of open source being produced given existing incentives; even if those incentives aren’t insanely great.
What’s even sillier though, is that there is a real problem here. The
business model for developing free software isn’t a very good one. It’s
either financed by charity (whether it be the author’s own, or users,
or some other group), or it’s parasitic symbiotic with
some other business model, like hardware sales or support or just as
in-house development. To be fair, that really is great.
But. The problem with this is that it’s just not reliable. It’s not reliable for the employees, who are at serious risk of being restructured as not being part of the “core business”, and it’s not reliable for users of the software that are willing to part with their cash to keep the development going, but aren’t interested in the primary product these companies are selling.
The real issue here is providing a stand-alone business model for free software development. To backfill a little, Joel’s essay (if you didn’t already click the link above) talks about complementary products; where if one product is available, or cheaper, the other product is likely to sell more. He gives the example of dinners and babysitters:
And babysitters are a complement of dinner at fine restaurants. In a small town, when the local five star restaurant has a two-for-one Valentine’s day special, the local babysitters double their rates. (Actually, the nine-year-olds get roped into early service.)
The thought here is that if babysitters aren’t available, married couples aren’t going to have as many nice romantic dinners. Whereas if they’re cheap, easy and reliable, they’re going to go out for dinner more often. It’s easy to imagine a restaurant putting two and two together and deciding to setup a creche to encourage more couples to come along. Now imagine that that’s the only way to get a babysitter. That’s pretty much the situation we have with open source development. It’s bearable, but it’s not ideal.
By contrast if we could setup a viable stand-alone business model for free software development then we could do things like setup a Microsoft-like campus filled with a hundred well paid free software developers, working full time on doing old stuff better, and making new stuff possible. Given we can compete with Microsoft without those resources, having them should be a significant improvement, and considering the sorts of energy you can get at developers conferences that’s not even completely theoretical.
A question is why consumers would want to give money to developers. Obviously not for the product itself, or for support or other add-ons; since the former’s ruled out by open source licenses and competition, and the latter’s ruled out by assumption. The only thing that seems reasonable to “buy” is what developers spend their time working on. And that’s hard to buy because it’s unpredictable – both because developers don’t tend to have consistent output, and it’s hard to work out how much time and effort is needed to get a useful product out. That is it’s hard to know what you’re actually getting, and it’s hard to know what you should expect to get for your money. But hard’s not the same as impossible.
I’ve been interested in gambling lately, or more descriptively using markets to predict things, such as the next Pope or Governor of California. I’ve been thinking that one way of handling such things is with ecash. Say you setup two currencies, A and B, and allow people to buy 1A and 1B for $1, and allow them to freely trade them. You keep the dollars you collect until the end, at which point if Arnold wins, you buy back the A currencies for $1 each, and let the B currency become worthless. If Bustamante wins, you buy back the B currencies for $1 each, and let the A currency become worthless. If you buy an A and a B, you know it’s worth paying a full dollar, because you’ll get a full dollar back at the end. In a well informed market with the opportunity to average out risks over a long period, the cost of each currency should end up matching the probability that the appropriate candidate will win. It seems nice and simple, and doesn’t requiring any gambling on the house’s behalf – the market works the odds out naturally, and the house just has to charge for its overhead in managing the moneys, which can either come via transaction fees, or by charging slightly more for the initial A+B bets than it pays for the eventual A/B payouts. Simple, honest and effective, as far as I can see.
Putting this together with the above thoughts on software development seems interesting too. One way of doing it would be to let people bet on a particular feature being implemented by a particular date. Fun and exciting, for sure. Let’s suppose you’re a user, who’d really like that feature by that date – enough that you’d part with $1000 for it. Okay, so you buy 1000 W + 1000 L tickets for $1000. You keep the 1000 L tickets – that way if your feature doesn’t get implemented, you’re no worse off. You can either give the 1000 W tickets to someone you know who can work on it, or can sell it on the market – both have their drawbacks, but oh well. At least you win either way: you get your feature or your money back. Interestingly, there’s even some incentive to invest: if your feature doesn’t get implemented, you’ll make a profit on your initial $1 of whatever you can sell your W ticket for. Not sure if that could compete with other investment opportunities, but hey, anything that improves the accuracy of release schedules has got to be a win, right?
For developers, there are two incentives. Obviously if you can afford to implement the feature for $49,000 and can afford say $1,000 upfront to buy 50k W tickets at 2% odds, you’re fine. Spend the money, implement the feature, win. There’s even an incentive to half-implement a feature: if the odds are initially at 5%, and implementing a feature will get those odds up to 40%, you can make a 7x profit on your initial investment, by buying low and selling high after you announce. It doesn’t even really discourage cooperation: if someone else beats you to the punch, you still get the winnings. Unfortunately you have to have some money up front to play, but that’s kind-of true of any business.
There are more significant problems though. One is working out whether a feature has actually been implemented or not – you probably don’t want to let whoever decides that have too much money locked up in either W or L shares; imagine if everyone thought the feature was implemented, so were selling L shares for 1c, and imagine buying 1000 such shares for $10, declaring the feature wasn’t implemented, and getting $1000 back. Yick. At least we quite specifically don’t have to worry about insider trader (we encourage it after all!), so it’s not all bad news.
The ideas here are very similar to those developed in Chris Rasch’s Wall Street Performer Protocol. The main functional difference is in the setting of a time-limit, and the possibility of getting your money back.
Martin followed up drawing the analogy to Jim Bell's Assassination Politics. Why should this sort of scheme work for open source and fail for assassinations? First, there's nothing questionable about writing open source software: it's legal and it's moral. Assassinations presumably aren't. As such, you presumably need fewer incentives to promote open source than you do for assassinations, and further, if assassination politics becomes successful due to this betting mechanism, you're likely to see the betting mechanism become either banned outright, or tightly regulated (removing anonymity, eg).
Also worth a quick link is the Rational Street Performer Protocol, which rather than offering software outcomes, guarantees that other people will donate a certain amount for every cent you donate. The theory is that it should create a virtuous cycle of everyone donating more money.
Finally, a big hello to the Carnival of the Capitalists!
Oh! There's more here.
Thu, 25 Sep 2003
One risk of solving spam (by doing cool ecash stuff, or by any other means) is that you might be attacked by people who don’t want it solved.
I underestimated both the enemy’s level of sophistication, and also the enemy’s level of brute malevolence. I always knew that spammers had no principals and no ethics, but up until recently, I had no idea that they could or would stoop this low, or that they would engage in quite this level of criminality.
Finding a provider that can cope with DoS attacks might be interesting. Avoiding DoS attacks that exploit the protocol properties might be challenging too. On the upside, perhaps serious DoS attacks are unlikely until there’s already enough money in running the service that it’s not a major issue. On the other hand:
If there are people on the net that can DDoS the likes of Yahoo and eBay out of existance (as happened in the year 2000), then little Ron Guilmette and Monkeys.Com hasn’t got a chance.
We’d need to (eventually) reach a level of reliability similar to that of the root DNS servers, rather than eBay or Yahoo. Challenging. Or just avoid being a monopoly. But where’d be the fun in that?
Sun, 24 Aug 2003
The inimitable White Glenn received one of those obnoxious confirmation-bounces anti-spam software occassionally does these days. As a man of good taste and high ideals, he didn’t like it. How to avoid this problem with our hypothetical $MTP protocol? The only possibility I can see is over analysing all our email – if you get a reply with an In-Response-To: header matching an email you sent, or one whose From: and Subject: match a To:/Subject: you’ve sent.
TMDA does some of this sort of stuff, apparently. Alone, though, it's just increasing the arms race.
Some more on why email challenges suck. A promising comment from that:
Any effective spam remedy must attack one or the other side (or both) of this equation: raise the costs or reduce the technological effectiveness, on the one side, or reduce revenues on the other.
Thu, 26 Jun 2003
One of the tricks with paying for http requests is that you screw up the protocol. Normal http requests are a simple request/response pair, and that’s it – you ask for a page, and you get given it. Worse, the protocol is optimised for that: if you want to do more than just send a request, you usually have to open additional connections for each, which has a significant overhead.
The easiest way to work around this, is probably to make the protocol for requesting a webpage be to send a HEAD request, which will confirm the webpage exists and that you don’t have a current cached copy and can also tell you how much it costs to download, and then send a GET request with the appropriate ecoin as a header. With HTTP/1.1 you can, I believe, make persistant connections to make this possible. I think this is also optimally efficient, and involves minimal changes to the protocol. (There’s even a “Payment required” error code, how convenient)
Thu, 05 Jun 2003
One of the fashionable things about ecash is (or at least was back in the mid 90’s when ecash was fashionable, and pre-September 11) that it can provide anonymity: neither the bank, or the merchant, or the government can track how you spend your money. Lucre provides anonymity to the degree that you can’t do any correlations at all except by traffic analysis. This potentially allows vast amounts of money laundering, and the benefit is somewhat questionable.
It should be trivial to do away the anonymity in lucre by requiring the blinding factor to be 1. Other possibilities are only issuing particular variants of the currency to suspected launderers: so any currency marked with a big “D” that’s spent anywhere is likely to be drug money, and you can see where the money goes, but not where it came from. You can’t do this with a great deal of secrecy from the person you’re trying to spy on, which makes their choice “accept that the bank can see what I’m doing, or don’t use ecash”, but that’s going to happen anyway. To a point, it trades off law enforcements ability to easily monitor criminal activity and trace it, to the ability to stop criminals from being able to accept money. Except that it doesn’t really work that well.
What benefits does anonymity provide? It means you don’t have to keep track of accounts, but I think you have to do that to keep your bank in the black anyway. Since you have to track transactions anyway, it doesn’t give you an excuse to use significantly less storage, either. On the upside, it avoids embarrassment, if you know you’re never going to get a statement, but that can be arranged by never giving out statements. Non-anonymity might be a lie, in that you can do money laundering in someone else’s name anyway, and get the cash yourself with good assurance, without having any of your accounts ever used – but knowing who your launderer is is probably more important anyway (Drew buys a car from Joe, using Laura’s cash - police track down Joe, ask for his receipts, start wondering who this Laura is…)
Probably better to provide something that’s anonymous, then remove the anonymity if it’s not valuable, though – doing it the other way around would probably be hard.
Mon, 02 Jun 2003
There’s an interesting paper on millicents (digital cash worth about a thousandth of a cent) from a guy who seems to be involved in Microsoft’s Penny Black project.
A decade hence, assuming that computers (and their components) continue on the price and performance curves of the last two decades, the minimum transaction grain will be an order of magnitude smaller than it is today. The smallest transactions will be in the sub-penny range. In a decade, we will see pricing by the web page. We can unbundle the newspaper and the magazine, derive revenue from the newspaper morgue, and sell information without restricting consumers to a subscription to a small number of sources.
Interesting thought experiment: imagine an average fee of about .1c/MB ($1/GB) integrated into http. You can probably setup a browser to obey this, so that it just displays “this image too expensive, right click to download anyway” when appropiate. It’s no more expensive than traditional bandwidth charges (10c/MB in Australia), and it sets up an economy so that when you’re slashdotted for writing something way cool you have a chance at making a profit instead of a loss. It potentially gives you a way of rate-limiting users too if you’re overloaded – just raise the prices until you’re not. The numbers might not work out, but in theory should do. Search engines might have problems – they need to scour the web, which would potentially cost a lot of money; but either it already does that, or it’s already subsidised elsewhere, and they already get a bunch of hits. Still, a market should be able to cope with this, possibly by making google.com marginally more expensive to view than other sites.
Note that this doesn’t quite match the email scheme – it presumes downloaders stop paying their ISP per MB, and pay the websites they view instead. Which means the websites pay their ISPs instead, which means fees can be based on outgoing traffic instead of incoming traffic, which in turn puts the burden of paying for the traffic of slammer worms and the like where it belongs. I may be drawing to long a bow at this point.
I’m obsessed with market theory :(
If this theory pans out, then you could make a good argument for allocating the entire social cost of spam to David Chaum’s patent on ecash.
Oh, the double entendres. Anyway, this Infoworld article quotes Ryan Hamlin, the general manager of Microsoft’s antispam technology and strategy:
“It won’t surprise me at all if we spend close to $18 billion a year next year to deal with spam,” he said. This cost includes the price of filtering software and storage hardware and other costs. Loss of productivity is not factored in, Hamlin said.
…
“An occasional spam might show up, but it is kind of noise and you will just delete it. Spam [fighting] will evolve into a measure-countermeasure cycle similar to the antivirus landscape,” he said.
No offense, but the antivirus landscape is abhorrent and a symptom of shoddy security measures in common systems, and $18 billion dollars of market friction isn’t something that should be tolerated. For reference, 35c per year, by the population of America is around $.07 billion USD, or per person, $60 USD versus 22 US cents wasted per year.
Sat, 31 May 2003
Each currency has to have a single dedicated bank to handle transactions. It requires a database containing an entry for every transaction that’s taken place. Each transaction needs to do a single element lookup from that database, and there shouldn’t be any locality of reference. Your storage requirements are O(T), and your transaction overhead is O(lg(T)) secondary storage operations. If each transaction takes 512 bytes of storage, then you can store about two million transactions per gigabyte.
As such, you have to retire a currency on a regular basis – otherwise you need arbitrarily large resources. How regular? If you have 1000 people, getting 1000 emails per day, that probably fills your two million transactions. A month’s email traffic for a small town would thus take up around 30GB. Covering a million people, say Brisbane, for a day hits a terabyte, or 10 100GB hard disks, ignoring redundancy. Coping with everyone in America, say 200 million people, would require 2000 100GB hard disks, per day. Doing that for a month, would take you up to six petabytes. Ouch. At $1/GB, each user costs 0.1c per 1000 transactions. That’s 35c/year per user for storage, which isn’t exactly going to break the bank. It does indicate costs would have to be very carefully managed, and that switching to actual charging (albeit small amounts) would be necessary fairly quickly.
It’s probably necessary to have the storage decentralised, rather than having to query a single, multi-petabyte datastore for every email anyone sends ever. Well, more certainly than probably. That necessitates multiple currencies, and an easy way to convert amongst them. Is it better to just have many floating currencies (which will happen due to competition anyway), or should we have multiple concurrent versions of a currency? ie, AJD.1, AJD.2, AJD.3, which a fixed 1:1 exchange rate? You only need to consult the transaction database to validate a coin, not to generate a new one, so that would make it easy for you to contact s1.ajcurrencyserver to exchange a coin denominated it AJD.1 and to get back a coin denominated in AJD.3. That allows you to do a reasonable degree of load balancing, doesn’t it? As long as the values are very small, it doesn’t let the bank mark the notes in a meaningful way (well, strictly it does, but you should be able to programmatically avoid any problems due to it easily enough). It does mean you have to be willing to accept AJD.* rather than a single currency, which could be awkward. I’m not sure if there are any cases where you care about the race condition where you can check one coin, have it pass, then check the second and have it fail. For email, you just take the coins and drop the mail. For markets, you refund the valid coins and start over.
Conclusions? Per transaction fees are required to pay for storage, as well as other running costs. Multiple currencies are necessary, probably even to the point of splitting a single notional currency at the implementation level, in spite of the complexities that introduces.
Thu, 29 May 2003
An obvious problem is how to transition from charging nothing for all your mail to charging something, without having everyone else do the same thing at the same time, or not getting any email ever again. There are a few ways we can ease this in.
The first and biggest problem is mailing lists. Coping with them at all is difficult: if you have a 5c mail going into the list, you somehow have to produce 5000 5c (or 30c) mails going out. Where’s the money come from? Obviously posters can’t afford it. An easy answer is the subscribers – if you subscribe for 500c, you can get 100 5c mails from the mailing list (and thus a full 500c refund!) before your subscription runs out. Coping with the initial subscription is easy too: you send a 5c subscription request, you get a 5c confirmation, and you reply to it.
All that’s well and good, but it doesn’t work unless the list manager is in on our scheme, which is the transition problem. If we’re going to solve it, we have to have an address in “our” control that accepts mails from the mailing list, without coins. It can either then verify them somehow (X-Mailing-List headers, eg) and add them to our inbox, or it can add a coin to them before forwarding them onto our real address. The latter lets you setup a subscription server during the transition that gateways old mailing lists into cashed up mailing lists for individual users. If the mailing list software doesn’t give out lists of subscribers, you can use an address like aj-123456789abcdef@example.com that’s unpredictable and different for each list to avoid spammers and strangers getting you directly. If it does give out lists of subscribers, you need to manage to drop non-list posts to that address somehow, which could get a bit flakey, but should be reliable enough. The other problem is posting to the list – if the list accepts posts from anyone (and is thus a spam trap itself), then you don’t have a problem; but if it’s for subscribers only, you do. You probably have to subscribe twice, and either elect for your real address not to receive mail, or just drop the mails that go there. All of that should be doable.
The next problem is that of strangers emailing you. This is the set of people to whom spammers belong, but it also contains “friends you haven’t met yet”. Obviously the most convenient thing for them to do is to setup ecash themselves, so that needs to be easy. Basically, you pretty much have to bounce them a reply saying “You haven’t paid enough money” and get them to either resend it with a coin, or to go to some website and confirm it. Ideally you want going to the website to be about as easy as it would be if they installed all the software locally. Basically, that website has to store the rejected mails, and allow you to send them on. The URL can contain the Message-ID easily enough, and maybe a nonce. Ways of approving mails could include presenting a coin (if your email software can’t cope), or doing one of the cute problems that aren’t difficult, but require human interaction. You could do this in the same way as subscriptions (ie, put up 500c, for every 100 emails from strangers, and recycle the funds), or you could let people get new coins from the mint when they solve such problems.
Those are really the easy problems, though. The hard one is dealing with friends emailing you. You can’t just tell them to get a new email program, and you can’t expect them to bother solving irritating problems whenever they want to mail you. You also can’t just drop their email. The only way to solve this problem is to hope they change their minds eventually. Work arounds have to involve identifying mails from friends and restricting them less. Possible ways to do so are by special addresses (aj-foo-123456) which suck, matching on From: lines, which spammers can and do fake, or cryptographic signatures, which no one does. Some combination of those would probably work; which means you definitely want your filter to cope well with all of them.
The final issue here is getting coins into the system. One way is letting people buy coins for real money. That seems unlikely to happen, at least early on. Another is for them to do computationally intensive stuff like run a distributed.net client, which seems like a good idea, although working out how many coins for how many blocks might be difficlt. Proving you’re a human is also probably worth a handful of coins. Basically, you need to have enough coins to cope with a few days’ mailing list mails, and enough to attach to all the mails you want to send. That might be, say, 5000c for the lists, and 20c a day for mails, which shouldn’t be too hard to manage. If you equate $1 with 1000c, it’s not particularly expensive to set up, and $0.005 per spam, would net me $350/yr, which ought to be horrendously unaffordable for spammers.
Wed, 28 May 2003
The biggest difficulty in running an experiment like that is to make sure that it’s possible to get involved in the market. That’s a wildly difficult undertaking: it essentially requires everyone who might ever want to send you email to obtain the tools and understanding to operate in the market. That can be made fairly easy, but it’s a step up on just using regular email. On the other hand, the spam problem has gotten bad enough that people are doing that sort of thing anyway, often in ways that will simply continue the spam arms race in ways we don’t particularly like (eg, spammers faking From: lines to pretend to be from people you know).
Our goal then is to add a pricing system to email, so that you can set a fee for incoming mail. We want this to be as easy as possible, both for senders and receivers, and we want it to be as flexible as possible, so that you can have ways of charging your friends less than strangers, or use the fees you collect from email for other things – most obviously simply reimbursing whoever sent you that gem of an email.
Our first step is to get some functioning electronic money. Paypal and credit cards are an obvious first choice, but both are utterly unacceptable due to high overheads (currency conversion fees, transaction fees, %ge fees, setup fees, etc). They’re also not very efficient at a protocol level – having to receive an email (from paypal, confirming a deposit) is a lot of overhead just to, well, receive an email. Efficient protocols for digital cash have been known for a while, but unfortunately have been mostly unusable and unused due to David Chaum’s patents in the area, and the failure of his company, DigiCash. Ben Laurie’s Lucre, based on an idea by David Wagner seems to be a workable and unpatented alternative.
Workable, in this context, means that it’s possible to have a number that represents a coin, and to be able to “give” that coin to someone else, without having any way of retaining it yourself – people don’t forget their own phone numbers when they give it to someone else, for example. There are two possible tricks here: the easiest is to talk to a “bank” everytime you spend money, and have them record the number you used, and create a new number for the shop keeper to spend later. If you try to give the same number to someone else, the bank will look it up in its list, and say “no”, and that’s that, the trade doesn’t take place, no one’s worse off. This is a nuisance, since you have to ask permission from a bank everytime you want to spend money, both for you and the bank, but it’s workable. The other way to attack the problem is to allow you to use the number twice or more, but to catch you when you do. This can allow you to spend money without talking to the bank immediately, if you’re also willing not to catch crooks immediately. The problem with this, is that if you don’t catch the crooks immediately, you might not ever be able to catch them, and if the crooks can manage to make that fairly likely (by, say, stealing a credit card, withdrawing $5, then spending that $5 a million times in a million places around the world, all in under a couple of minutes), well, you’re probably pretty screwed.
So, we’ll go with Lucre, for the time being.
We’ll make a few simplifying assumptions. First, the currency won’t be backed. That is, it won’t be tied to the dollar, or to gold, or to anything else. You can exchange it for other things freely, but you aren’t guaranteed to get any particular rate. This means that you need to be careful about monetary policy, but it also means you can minimise up-front costs, and give emoney away for free without running any personal risk.
Second, the bank won’t have accounts. Since each coin is useless once its spent (you can’t rely on it since whoever you gave it to could use it first, and they can’t rely on it since you could spend it again), we’ll simply allow you to go to the bank and get a coin changed for another whenever you like – which is to say, every deposit at the bank will also necessitate a withdrawal of the same amount. This doesn’t add any risk or remove any flexibility – it just exchanges account numbers for coin numbers, and removes a layer of state, ie complexity.
Third, we’ll expect there to be many different currencies, all competing. If I can set this up, obviously so can others. Further, competition is a good thing. This doesn’t simplify things technically, but it does simplify things globally – it means you can distribute the load of all the world’s transactions over many currencies, which is a good thing if every transaction in a given currency has to go through a single bank.
Fourth, as much of the cash management as possible will be done using an electronic market. This particularly concerns “buying” electronic cash (trading real money for electronic money, or some other limited resource for electronic money), and converting between different electronic currencies. The theory here is that a single “market” interface should be the standard for as much trade as possible. It will need to provide, in code and reputation, the ability to trade with people you don’t trust remotely – which means binding contracts. There are probably other caveats.
And fifth, we need what I’ll call an $MTP protocol that allows you to send money and mail, and correctly deal with errors throughout the transmission. That’s going to be fairly tricky. In fact, doing Lucre reliably is probably a little tricky, and will require something like “journalling” to ensure system crashes during transactions don’t result in lost money.
And thus ends today’s discussion. Also of interest is Lucrative, who call ecoins “digital bearer instruments”, and expect things to be strongly backed.
Thomas Sowell makes a very convincing argument for markets in his book Basic Economics. In principle, the idea is that markets allow people to redistribute scarce goods (food, labour, materials, land, etc) according to where it’s most useful to society. The more creative you are, the more and better work you do, the more other people trust your judgement, the more say you get, which is to say, the more money you have. It’s not particularly difficult to argue that most of the flaws in a market economy (lack of jobs, lack of investment) are due to misprioritising the desirability of possible outcomes. A possible conclusion is that the market system can’t do away with philanthropy and altruism, but can reduce they’re necessity immensely, and can also reduce government intervention massively.
Anyway, while that’s a possible conclusion, it’s not the one we’re going to work from. What we’re going to work from instead is the theory that free markets are the best possible way of allocating scarce resources. That might or mightn’t be true, but there’s a lot of evidence for it, so it’s worth considering.
Our additional assumption is that the time I’m willing to spend only a limited amount of time reading emails, and that there’s more email that would like me to read it than I have time for. This assumption, and the preceeding theory have an obvious implication: that there should be a market in which sellers (people with email addresses), and buyers (spammers, admirers, confidants, whatever) can negotiate a fair price, and, further, creating such a market is the fairest and most efficient way of dealing with the spam problem.
This is a straightforward conclusion in a mathematical sense. The only way, at least as far as I can see, to disagree with it is to disagree with one or both of the assumptions: that is to say either that free markets are not the most effective way of allocating scarce resources, or that I don’t get too much email. Which should leave us an interesting experiment that has two possible outcomes: either an effective means of reducing spam, or a demonstation that free markets are not effective.