http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf

all the suggested approaches you mention (reduction of “settlement” time, security, interest payments) are possible to implement without either using a new instrument, or without this instrument being usable as a medium of exchange.

Split-signature transactions provide enhanced security, and scripts can implement escrow. Green addresses and zipconf provide a way to avoid waiting time for settlement. These do not require a new medium.

Before it shut down, Bitcoinica used to pay interest for deposits. While this technically creates a new instrument (leveraged balances), it’s unusable as a payment method. And I’m not even sure if interest plus the technical possibility of using it as a payment method is a sufficient reason for it to actually become a substitute medium of exchange, I’m just accepting it for argument’s sake, as others make the argument as well. Demand for interest payments could well evolve into something like savings accounts, which provide interest payments and even though they might be leveraged, they are not a medium of exchange.

Furthermore, these new instruments would be/are technologically incompatible with Bitcoin, which increases transaction costs and decreases the likelihood they can act as a substitute medium of exchange.

So, I think your conclusion is premature. It’s not as easy. Bitcoin is form-invariant and can exist on any medium capable of storing 64 bytes. There are casascius coins, bitbills, printbills and so on. You can have them in your brain, on a tungsten brick, on your computer or your phone. In the “worst case”, you can “package” a private key into something else (e.g. send a gpg encrypted mail). So, the form-invariance means that theoretically, all the deficiencies can be solved. Can they be solved efficiently? Will it be enough or not? I don’t know, but I’m skeptical of viability of Bitcoin-substitute media of exchange.

Nevertheless, I praise your article very highly because unlike many others, you realise that for an increase in the money supply, there must be a demand for a new medium of exchange, and this means it needs to provide certain features which the original medium of exchange does not. You also realise (in a comment to Jon Matonis) that Bitcoin already provides features which banks cannot compete with. This is a crucial point and you got my respect.

A comment on dividing the karma score by the distance from the origin; this is fine as long as the sum of the scores over subsets of nodes doesn’t matter, but if it does (and it does if this is being used as i think you are suggesting, because a group’s ability to call in favors would increase linearly with the sum of their karma), then dividing the karma score by the distance of the origin would allow a colluding group (or one user with multiple pseudonyms, same thing) to accumulate an arbitrarily large proportion of the total karma.

Proof: imagine one “bad” user who makes a zillion pseudonyms and then gives 100% of their thanks to their own pseudonyms; and then each pseudonym gives 100% of its thanks to other of the same users’ pseudonyms, etc. If the bad user were k hops from the root, then let BAD := the amount of karma they were given, and the total karma amassed by all of the pseudonyms would be BAD*(1/(k+1) + 1/(k+2) + 1/(k+3) + …) . But that is the tail end of a harmonic series, which diverges. So the bad user and hir pseudonyms could accumulate, in sum, as much karma as they want.

If the karma decreases geometrically, rather than arithmetically, with hops, then you’re safe. E.g. you could say that the maximal karmic boost that any node can provide its recipients is 1/2 of its own karma; in which case the maximum that a node n hops from the root could get is 1/(2^(n-1)) of the total (and the maximum amount that it and all of its descendants can get via collusion is twice that).

Also, what happens with cycles? Our approach at PieTrust is to allow cycles and to think in terms of an iterative algorithm rather than an algorithm that visits each node only once. In this case, what we do is to decrease karma each time it travels over a hop, rather than assigning a fixed factor to each node based on distance from the root.

If you know that there are no pseudonyms in your user population, then you can take a different approach involving disallowing cycles.

Also, for readers who followed the link in the blog post to http://www.pietrust.com but wanted more detail, it’s here: http://devwiki.pietrust.com/FunSpec and here: http://devwiki.pietrust.com/IteratedGiving (pages with more details are linked from those).