No, that statement just isn't correct. The
definition of a public good is one in which exclusion isn't possible. The very first sentence of the Wikipedia page for public good says this:
In economics, a public good is a good that is both non-excludable and non-rivalrous in that individuals cannot be effectively excluded from use and where use by one individual does not reduce availability to others.
I think this disagreement over definitions may be the root of our argument. Network security is clearly a public good, anyone can use it just by bringing up a TCP connection and broadcasting some transactions. Assurance contracts are well studied way to provide such goods, albiet one that hasn't been used much until recently - but things like Kickstarter are showing the way. You haven't provided any convincing arguments as to why this won't work.
Chris, the point of this thread are that the developers have thought of lots of counter strategies, network assurance contracts are just one. cunicula rejects all of these, but that doesn't mean he's right.
I don't want to argue with you about definitions. Public good is a loosely defined term. The key characteristics as you note are "non-excludable" and "non-rivalrous", but most "public goods" do not completely fit this description. You might find these lecture notes on public goods helpful:
http://are.berkeley.edu/courses/EEP101/spring05/Chapter07.pdfYou can certainly make broadcasting TCP transactions excludable (for example by imposing a minimum fee to get them accepted in blocks). Pools can do this by forming a 51% cartel and rejecting all blocks include free or cheap transactions. Alternatively a monopoly 51% pool can form. The problem is that these solutions look very much like Paypal/Visa/MC and I once hoped that bitcoin developers had higher aspirations.
Let's examine a few problems with assurance contracts.
1) Basic Assurance Contract
Say you write some shareware that needs to a server to run. You can solicit $1 donations to support the server and say that if I get 100 of these, then I will run the server, if not then I will return the donations.
You are arguing that committing to return the donations if you get less than 100 serves as some kind of magic bullet. I think this is ridiculous.
Say that I value the service at v>1. Let x(1)>0 be the probability that the service operates if I contribute and x(0)>0 , x(0)<x(1) be the probability that the service operates if I do not contribute. The fact that I don't have to pay for nothing makes it an assurance contract. If I contribute, my payoff is x(1)(v-1). If I do not contribute then my payoff is x(0)v. Therefore, I contribute if x(1)(v-1)>x(0)v. Rearranging you get that I contribute if v>(x(1)/[x(1)-x(0)]).
Note that as x(1) approaches x(0), the valuation necessary to motivate my contribution becomes infinite. The distance between x(1) and x(0) decreases as the number of contributors increases. If you solicit small contributions from a large number of people x(1) will be very close to x(0), so no one will contribute. Even if you ask them for a very small amount.
The only approach that could work is soliciting very large contributions from a small number of big corporate donors. Then you potentially have x(1)>>x(0). I'm not sure if CorporateCoin is what everyone had in mind.
2) Dominant Assurance Contract [I have never seen an example of a contract like this in actual use, anywhere. It is easy to set up. Curious that this supposedly 'promising' concept has not been adopted by any of the assurance contract operations]
In the dominant assurance contract, there is an entrepreneur who insures the assurance contract against failure. Perversely, after they have submitted funding, the contributors may now hope the project fails. One reason we may not see this on kickstarter is that it is an advertising platform (the contributors are supposed to aid the project, not try to hamstring it.)
Okay, back to the contract. The entrepreneur promises to refund the original contribution + a penalty, y>0, if the funding goals aren't met.
Therefore the previous problem becomes,
I contribute if x(1)(v-1)+(1-x(1))y>x(0)v. Now we contribute if v>[X-y(1-X)]/[x(1)-x(0)].
This is good because we can increase the probability of funding if the goals aren't met by offering a bonus y. If the bonus is large enough, then you will always contribute here. But the bonus is not a free lunch. The entrepreneur is taking risk here. He loses money if the fundraising fails y*n, where n is the # of contributors. Thus he needs to skim some profit off the donations.
This raises a number of concerns for me:
1) Ex-post the contributors may want the project to fail and could potentially benefit from sabotaging it. This is not a good structure for a collaborative project.
2) The arrangement requires the 'entrepreneur' to skim rents off of everyone else's donations. Compare this to say a minimum fee. With a minimum fee you get $1 of hashing power for every $1 collected with this arrangement you only get whatever is left over after the 'entrepreneur' takes his cut. Thus even if the contract works well, it will still be inferior to simply imposing a minimum fee.
3) The arrangement might be vulnerable to sabotage. Suppose that 'entrepreneur 1' offers a dominant assurance contract with a payoff y. I then contribute heavily to his contract, but not enough to put it over say 50% prob of success. Now I release my own dominant assurance contract with a payoff 2y. The new contract might persuade people to switch from his contract to mine. If my contract succeeds and his fails, then I scam entrepreneur 1 for a big profit. But wait... If I could scam the entrepreneur why doesn't another entrepreneur come along and try to scam me? Maybe I should never offer a contract in the first place? The existing literature, basically just one paper by an economist (
http://www.iso.gmu.edu/~atabarro/PrivateProvision.pdf), does not consider this issue at all.
[The sabotage issue is complex and would require a lot more work than I am willing to put in to analyze. It alarms me that the existing literature hasn't even considered this.]