Who stands to benefit from a spam attack on the Bitcoin network?

As discussed earlier, the Bitcoin network has recently been flooded with a lot of spam transactions. While at least some of this was an honest stress test, it brought more attention to the fact that the Bitcoin network can be pushed to its limits with relatively low cost by anyone. While the network should be resilient against zero fee transaction spam attack, putting some money and effort into the attack can make it seem like a lot of honest transactions with relative ease.

Now, since we know how the Bitcoin network could be destabilized, let us ponder who might benefit from such actions.

DISCLAIMER: while I will be mentioning a lot of specific examples of peoples and projects that might benefit from such an attack, please treat them only as illustrative examples. I have no evidence of their involvement in the attacks, nor do I believe any of them would employ such a strategy.

The usuals

Since we're talking about an attack on Bitcoin, lets get the usuals out of the way - governments, big banks, PayPal, etc. wanting to bring Bitcoin down since it challenges "the old ways". There isn't much new to add to these speculations or motivations, so might as well skip this part of the debate for expediency's sake.

The direct competitors

Bitcoin has been copied so many times people lose count. There is never a shortage of copycoins out there. Since Bitcoin has a throughput issue of handling a lot of transactions, you can easily see someone creating an altcoin with higher block sizes and faster blocks to sell itself as the solution to Bitcoin. More ambitiously, you can look at coins that have added some improvements to the protocol to combat spam, like Litecoin for example. Sustain a spam attack on the Bitcoin network long enough to sell your story of being the savior of cryptocurrencies and you might just be able to push up the price of your coin high enough to turn a profit.

The speculators

Just like you can speculate on the price of altcoin alternatives going up, you can also try speculating on the price of Bitcoin being affected by the spam. Alternatively, you could try to cause something similar to "trade engine lag" on the Bitcoin network and try to game some exchanges while other traders would have trouble moving their coins onto the exchange to cash in.

The solution evangelists

Even if we don't look at the altcoin space, we can see a lot of people with an agenda of where the Bitcoin code should move towards. Whether they are doing it for profit or for personal satisfaction, there is a potential for those evangelist of their own solutions to attack the network and push their code onto others.

Below are some examples (again, only illustrative examples, read the disclaimer) of potential solution evangelists.

Sidechains is an interesting concept of how to move a lot of transactions off the Bitcoin blockchain while still having a currency tightly tied into the Bitcoin itself. As (to the best of my knowledge) sidechains are still impossible to fully implement into the Bitcoin network without a soft fork, using the spam attack as an opportunity to push for a fork would be beneficial to them and enable sidechains to come to the Bitcoin network.

The debate over Bitcoin block size increase has been a hot topic for a few months now. The topic has been pushed most notably by Gavin Andresen, with some people even speculating on "gavincoin" becoming a reality (read more here). More so than Sidechains, the concept is not possible without a hard fork to the Bitcoin protocol, thus pushing the block size increase amid the spam attack would make the core developers more urged to consider going through with the fork to solve the issue.

Finally, something that doesn't require a hard fork - transaction filtering. This approach relies on being able to identify which Bitcoin transactions are spam and which are legitimate use cases and prevent the spam from propagating through the network. If enough nodes in the network would stop spam transactions, the network as a whole could develop herd immunity against spam. However, the same mechanism could be used to deny some Bitcoin businesses' transactions from reaching the miners. Such transaction censorship has been tried to pass unnoticed in the past by Luke-Jr, and could possibly be tried again along with more honest spam filtering.

The off-chain alternatives

Since moving transaction on the chain can be a problem, some people might propose solutions based on transactions being processed off-chain instead. Examples of such alternatives would include the Lightning Network, Ripple, Open Transactions or shared wallet providers such as Coinbase. If the off-chain solution can deliver bitcoins to people faster than the real network and some people don't know or don't care how they receive the coins, they might appear as a legitimate replacement for sending real Bitcoin transactions to some people. This might be also the case when Bitcoin transactions are too pricey to be included in the blockchain.

Crypto 2.0s eliminating competition

There are a lot of Crypto 2.0s out there. A good deal of them rely on the Bitcoin network to function - Colored Coins, Omni or Counterparty for example. There are also some emergent platforms that offer services tied to the Bitcoin blockchain, such as Factom. If the transactions for those networks can't make it into the Bitcoin blockchain, the network itself performs worse and suffers as a result. Their alternatives on the other hand stand to benefit from people potentially switching over. Ripple could benefit if Omni is not performing well, Ethereum stands to benefit from Counterparty being slow, etc. While being on the Bitcoin blockchain has been a selling point for a lot of companies, it can turn into a detriment if the Bitcoin network is overloaded.

Extra: bribing the miners for their compliance

As a side-note, it might be interesting to consider how some parties might want to even further push their agenda onto the network by essentially bribing the miners for their compliance.

Say, if someone wanted to eliminate some "spammy" transactions from the Bitcoin network, whether it's SatoshiDice's dust transactions or perhaps Omni transactions. They could easily set up an anonymous website claiming they will pay every miner X amount of bits for every block they create that complies with their spam filter. As long as they offer more than the miners stand to earn from the transaction fees, there is a benefit to them complying. With the excuse of excess spam, the miners can't be entirely held accountable for some transactions not making it into the block. Since the miners can be paid directly to their coinbase address, everything is transparent and nobody needs to agree to collude.

Conclusions

A stress test of the Bitcoin network can be all about preparing for the higher transaction volumes that are to come in the future, but it can also be a way for some people and organizations to further their agenda. While it might be still really early for such high-level politics to surface around Bitcoin, who knows what the future might hold?

Mining versus Consensus algorithms in Crypto 2.0 systems

Recently, I had the pleasure of talking with David Schwartz, Chief Cryptographer at Ripple Labs about a topic that I haven't heard covered before - the implications of using a Consensus algorithm for ledger creation rather than a Mining approach, such as the one used in Bitcoin. This seemingly insignificant difference can affect the long-term viability of a Crypto 2.0 system as it turns out. But first, some theory...

Mining algorithms

As pretty much everyone knows, new Bitcoin blocks are created through a process called mining. Every miner on the network competes to produce the next Bitcoin block by the use of Proof of Work algorithm. If you find the solution first, you have successfully created the next block and thus get the block reward plus fees for included transactions - pretty simple.

There have been a lot of tweaks made to this simple algorithm in many altcoins out there. A number of different coins use different hashing functions for their Proof of Work, some networks introduce Proof of Stake or Distributed Proof of Stake and so on. What all of those algorithms have in common is that every block is created by a single entity - it might be a lone miner, or perhaps a mining pool aggregating a number of workers, but there is still a singular authority that dictates how a block looks.

Consensus algorithms

The Consensus algorithm as popularized by Ripple and also used in Stellar works on a different principle (some videos on this subject - 1, 2). Instead of performing any mining, a number of validators agree on which transactions should be included in the next ledger. Based on that agreement, every validator creates the same ledger.

While the way the validators are chosen can be a a difficult and important design decision, the result is similar - there is no single entity that creates the next ledger.

Malicious miners - what can they do?

While most people have heard about the dangers of a 51% attack and some are also aware of the Finney attack, today we would be talking about more benign things every miner can do to every block they create.

Any miner that creates a block can:

• Control which transactions are part of the block, if any
• They can prevent certain transactions from appearing in the block they mine
• They can include any number of valid transactions into the block. Even if fees are forced for any such transactions, the miner will earn those fees back
• If there are multiple conflicting transactions, the miners get to pick which are included in the block, thus invalidating their double-spend counterparts
• Control the order the transactions are included in the block
• Decide whether to release the block they created at all
• Set the various block parameters within some limits (they control the nonce and timestamp)

In the Bitcoin world, pretty much all of those things don't really affect the network performance all that much. Sure, the miners can censor some transactions for a block, but provided the network as a whole is not compromised, those transactions should eventually make it into someone's block. They can also spam the block with any number of their own transactions for free, but in the grand scheme of things it's just an extra megabyte of data that needs to be stored. All in all, due to Bitcoin's straightforward transaction nature and the fact that we're dealing with only one currency, a malicious miner can't really do much.

Now, lets consider the same scenario on a more sophisticated Crypto 2.0 platform, such as Ripple, BitShares, Ethereum, Omni or the like. The network not only handles their native currency, but also offers a lot of other features - derivative contracts, decentralized exchanges, smart contracts and so on. Suddenly, whether a transaction is included in a given block or a block after can start to matter a lot more.

If a malicious miner sees a big buy order coming into the market that would move the price significantly, they can engage in front running - the buy order could be pushed to the back of the queue or even left out until the next block, while the miner buys up all of the current stock and re-lists it at a higher price to turn a profit. Alternatively, when they see there is a high market pressure coming in, especially in systems that are inefficient by design, they can buy the orders up one by one by using their power to include any number of their own transactions into a block for free, and similarly re-list them for people to buy up.

When we enter into the smart contract world, we have a few more exploits.

Perhaps the system in question is relying on the miners to be smart oracles and report some price data. The miners can misrepresent the price in their favour - perhaps not so blatantly as to report different orders of magnitude, but one could use data that is a bit stale or fudged on the second or third significant digit without it looking too suspicious.

The miners could also try to influence some time-sensitive contracts - maybe someone tried to make a bet on some lottery during the last possible minute, or some contract deadline is about to come up and the miner stalls the transaction by one block? That could change the outcome of the contract.

Lastly, if some smart contracts implement gambling on the blockchain with the random number generator being influenced by the mined blocks, the miners could cheat that system by only releasing blocks favourable to their bets. Say, if we have a virtual coin flip that is heads if the block hash is even and tails if the hash is odd, if the miner stands to gain more by winning the bet rather than creating the next block, they can withhold the blocks that aren't favourable to them. Provided their computing power share in the network is greater than the house edge in the game, the miners would turn a profit in the long run.

All in all, there is a lot more a malicious miner can skew in their favour in a Crypto 2.0 system than they could do in a traditional system like Bitcoin.

Validators

In comparison to the miner-based approach, the consensus model based on validators solves the listed issues in most cases. Provided the validators are not colluding with each other to overtake the network, most of the above listed attacks are reduced if not eliminated altogether.

While a malicious validator might try to do some front-running, their transactions aren't more likely to be included into the next ledger than the transactions anyone else submits. Having multiple validators act as smart oracles could allow one to average out the answer and limit the influence of one malicious report. Time-sensitive contracts could be slightly influenced by trying to stall the consensus mechanism or vote against some transactions being included in a ledger, but since the system is designed to be fault-tolerant, one malicious entity shouldn't be able to do much.

Influencing the ledger hash is possible to some degree - the validator can try predicting what the next ledger will look like and adding which transaction could influence that hash in their favour, but everyone else can do the same. Since all parties are just as likely to influence the ledger hash, the result of this influence could make the outcome just as random as it ought to be, or at least make it very hard to predict whose influence will win in the end.

All in all, a validator-based approach to ledger generation reduces the number of exploits that can be performed in a Crypto 2.0 system.

Conclusions

One could compare the mining approach to block generation to a short-term dictatorship, while the validator approach is more akin to democracy. While both systems can be exploited or used for good (the Roman Republic elected their dictators in times of need, while democracy can spiral into mob rule), the democracy of validators requires more parties to be malicious before the system becomes compromised.

While in the Crypto 1.0 world a malicious miner can't do much to harm the system, in a Crypto 2.0 world there are a lot more exploits that need to be addressed.

As this is a topic I haven't seen properly discussed before, I would love to hear the input from the developers of various Crypto 2.0 systems - Omni, Ethereum, Counterparty, NXT, BitShares and so on as to how they view this issue potentially affecting their networks.

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.