Shipping without incentives and features

Recently I was doing some research into Factom, a new project that aims to embed a lot of data into the Bitcoin blockchain and create a "proof of existence as a service", among other things. I stumbled upon some criticisms of the software (Google Cache link, as the original was taken down). One of the crucial features missing from the Factom code at the current time appears to be the lack of incentive for nodes to store any data after it is embedded into the Bitcoin blockchain. Pondering this for awhile, a few similar issues with other systems came to mind, and thus I'm writing this blog entry on various Bitcoin-related software that launched without some important features or incentives.

"Convenient bugs and arbitrary features" is also a recommended reading related to this topic.

Red balloons - Bitcoin is not without its flaws

When I was doing research for my master thesis on Bitcoin, some researchers from Microsoft and Cornell University released a paper called On Bitcoin and Red Balloons, where they pointed out the Bitcoin nodes have no incentive to propagate transaction information through the network, and miners have all the incentive to actively withhold that information.

The gist of the research is that while anyone creating a transaction has the incentive to propagate it through the network (they want the transaction to be put in a block, so they spread it to everyone), miners have the incentive to include paid transactions into blocks (to earn fees), Bitcoin nodes have no incentive to relay the transaction information. They are not getting paid to do so, nor do they benefit from the transactions they transmit directly. Moreover, if a miner knows of a transaction with a fee, they benefit from not broadcasting it - this way it is less likely to be mined by their competitors and they are more likely to earn that particular transaction fee.

One can argue, however, that every business built on top of Bitcoin has the incentive to run a full node that relays all the information. While they don't benefit directly, the abundance of full nodes makes the network more resilient to attacks and more distributed. What benefits the community at large is also beneficial to the individuals in some way.

Mastercoin - a token without a purpose

Back in the day when Mastercoin launched (and has since re-branded into Omni), my biggest question surrounding this technology was - "what are mastercoins used for?". In the Bitcoin space, you would use bitcoins to pay the transaction fees. In the Mastercoin space, well, there wasn't a clear use for mastercoins. Sure, the project itself benefited from the crowdsale to fund the development of the protocol, and some people earned some pretty penny speculating on the price of the coins, but there was no immediate use for the tokens themselves. There were no mastercoin-denominated fees in the system, the transactions instead paid the standard Bitcoin transaction fees. Only much later did the developers include a clear use case for the tokens - to burn them for crowdsales. A little bit of an arbitrary feature in my opinion, but at least it is some feature.

Ripple validators - a big burden with no reward

In a similar vein to Bitcoin's lack of incentives for running full nodes, the Ripple network provides no incentive for network validators. A validator is similar to a miner on the Bitcoin network - they process all the transactions taking place on the network and create new ledgers. While mining bitcoins is a computationally-intensive task due to proof of work, the Ripple network is more heavy on the disk space (full network history taking up 100-500GB of data at the moment).

Unlike Bitcoin however, Ripple fees are not paid to the miners / validators, they are instead burned. Similarly, Ripple has no coin distribution schedule - all the XRPs have been created in the genesis ledger. This leaves validators with no incentive for a potentially burdensome effort (most of them are currently run by Ripple Labs last I heard).

There are two approaches to solving this issue however. One is the idea that the Ripple gateways should also run validators, as they are the ones earning the most money from the network operating. The second approach could build on top of Stellar's token creation - the validators can be compensated by the users of the networks for their contributions with newly minted stellars.

Factom - pay to save, never load

As mentioned in the opening paragraph, it appears that the Factom network allows its users to save any pieces of information into the network for a fee, but fetching the data in the future carries no cost and thus no reward for the nodes to carry out that request. If someone decided to abuse the network, they could try flooding it with a lot of requests similar to a denial of service attack - honest nodes would be overburdened with having to provide a lot of data, while lazy nodes that wouldn't even attempt to provide the information would be better off.

As such, it appears that the Factom network will need to expand its fee and reward structure to provide incentives for nodes to store information as long as it is useful, similar to how MaidSafe is supposed to work.

Branded coins - start with a purpose

I heard a few similar pitches - a company wants to release a new, branded coin and tie it to their service. They usually have some grand vision of how everyone will want to use their coin since they will be able to spend it in their system and pay anyone just as easily as they do with Bitcoin. Sometimes it's customer rewards for shopping, sometimes it's some coin to raise brand awareness. However, quite often such pitches lack one crucial thing - why would anyone want to use the branded coin over Bitcoin? If you say, have a payment processor that accepts Bitcoin and their branded coin, I personally see no reason to use the branded coin over Bitcoin, nor to hold it any longer than it takes to convert it back into BTC. Even the usefulness of presale tokens can sometimes be dubious.

In the end, a branded coin needs to serve some purpose other than just existing for the sake of it.

Conclusions

There have been a lot of projects in the past that have launched without all the necessary features or without proper incentives to support all of the functionality. While we can expect some level of altruistic behaviour from the people running the software, a well-run system shouldn't rely on altruism alone - either you pay to use the resource, or you lose it.