2015-06-28

Bitcoin vs Blockchain

In the recent months there has been a lot of buzz in the financial world about the "blockchain technology". It seems that everyone from Overstock to NASDAQ are getting into the game, but the Bitcoin name is uttered less and less often. The consensus is that the blockchain technology is interesting, but Bitcoin is not. On the flip side, the Bitcoin community appears to detest the notion countering that the blockchain cannot exist without Bitcoin. Lets analyse this topic and figure out what is going on...

What is a blockchain?


There appears to be some confusion among some people as to what the blockchain is. The technology bears some resemblance to a database and git in particular. The general consensus appears to be that a blockchain:
  • Is a database consisting of atomic transaction records
  • It is write-only (barring a 51% attack)
  • It is immutable (transactions cannot be changed, again barring a 51% attack)
  • Commits to the blockchain come in a form of a block
  • Commits have an unambiguous sequence (every block refers to a previous block)
  • The blockchain protocol enforces some rules as to how each transaction is handled (through a protocol and smart contracts)
  • The blockchain protocol has a way of resolving forks in the chain (for example, longest chain)
  • At any time, the blockchain is in a predictable, unambiguous state (given by the current block)
Beyond those, there is some disagreement as to whether or not some features are needed:
  • Does a blockchain need a native currency?
  • Do blocks need to be mined?
  • Is a blockchain controlled by a single entity still a blockchain, or just a database?
Lets explore some of the disagreements and possible misconceptions in greater detail.

"You can't have a blockchain without Bitcoin"


If we're talking in a literal sense, that statement is obviously false - there is nothing in Bitcoin that imbues its blockchain with some special properties unobtainable by say, Litecoin or Dogecoin. However, if we're talking in a more broad sense about blockchains without native coins that provide an incentive for the miners to be creating more blocks, things get a bit more complicated.

In a traditional blockchain like Bitcoin, the native currency is not only used to incentivise the miners, but also to prevent spam. It is quite an elegant solution - anyone wishing to send a payment won't mind spending less than a penny to get their transaction included in a block, but someone flooding the network with spam transactions will feel the burden of the fees compounding on them.

A blockchain without an internal currency loses both the incentive for the miners to create new blocks and prevent spam through the use of fees. While this would probably cripple any decentralized blockchain, it might not be the case with more centralized blockchains (we'll discuss them in detail later on).

The miners can be subsidized in other fashion, or even ran for free by the businesses that rely on the network. This is the case with Ripple's validators - most of them are run by Ripple Labs, since they have a strong stake to keep the network running, but one could imagine a more decentralized network with validators being run by the various gateways on the network. Since the validators earn money in some other way (running gateways, providing other services, etc.), it makes sense to keep the servers running.

If we're talking about blockchains without fees, Hyperledger and Eris come to mind. While those solutions don't appear to be suitable for decentralized networks, they make sense if we're talking about a finite number of known servers communicating with one another. In this scenario, similar to a private network, you don't expect spam or DOS attacks to be an issue - all the parties are known and they have no motivation to attack the network. Moreover, if the users of the network are known, they can be punished if they try to break the network - either by having their access revoked, or possibly by some legal actions being taken against them. 

So all in all, it looks like decentralized networks do need a token to run their blockchain, while more centralized solutions can get by without them through other means.

"Centralized blockchain is just a database"


While in the previous section we touched on the economics of running a centralized blockchain, here we will be discussing what is the point of running a centralized blockchain in the first place.

There are many reasons to connect to a decentralized blockchain like Bitcoin - you can transact with anyone in the world, nobody can ban you from the network and all your transactions are forever stored and distributed among many computers all around the world. However, there are also some needs that can't be achieved in a public ledger - protection of private data, instant transaction speed, dealing with only known parties, etc. All of those are features needed by some companies - perhaps they need to follow strict KYC rules on all clients, or they are dealing with sensitive financial information that need to be kept private. One way or the other - there are some valid reasons to run a private blockchain.

Given all that, what advantages and disadvantages are there to using a blockchain over a database?

There are certainly many disadvantages - since the blockchain is a new technology, it might not be as optimized as a database. If we're talking about a distributed network, there is also a lot of delay when the data is transmitted, not to mention the block creation time itself.

There are also some advantages to a blockchain over a database:
  • The entire status of the system can be summarized in a single hash (latest blockchain hash)
  • Every full node in the system is synchronized with the rest of the network and will reach consistency with it
  • Every transaction is authorized by a private key, meaning every action and actor can be held accountable
  • Every block can be similarly authorized by a known entity / private key, meaning that any "51% attacks" can be traced and punished externally
  • There is certainty for whether or not a transaction committed successfully to the blockchain and what is its outcome (especially if we're talking about more complex systems like Ripple or Ethereum)
While there might be little use for a blockchain technology if it's used by a single entity, it certainly bring up a lot of benefits if we're considering multiple parties using the blockchain technology to conduct business:
  • All transactions on the network can be legally binding as per agreement (especially if we're talking about making business decisions using smart contracts or tracking debt using a Ripple-like ledger)
  • There is no confusion as to the current state of the network - everyone will be on the same page once fully synchronized
  • Given the block creators are trusted entities (in a model similar to BitShares or Eris), or everyone using the network is also a block creator (in an ideal consensus mechanism), there is a strong disincentive to attack the network through a 51%-esque attack (block creators can be legally liable for doing such a thing)
  • Audits of the network are unambiguous, since all transactions are public (provided the auditor has access to the full blockchain)

Centralized versus decentralized blockchains


While centralized blockchains have their uses, there are certainly some advantages to using a decentralized blockchain (Bitcoin or otherwise).

First of all, anything that happens on a large, decentralized blockchain such as Bitcoin can be verified to have happened at the given time. Centralized blockchains can be re-written or forged if all the involved parties collude, while a decentralized blockchain is much harder to corrupt. This is why we see companies like Factom using the Bitcoin blockchain for timestamping - the record is public and provably immutable. Any private blockchain wishing to prove their records were not altered would similarly have to use the Bitcoin blockchain and embed the block hashes into it to prove the data was not altered later down the line.

Secondly, it may be much easier for multiple companies to agree to use a decentralized network as a middleware, rather than them agreeing to use a proprietary blockchain. This is especially true if we would be talking about companies dealing with entities they don't know or don't trust. Using a decentralized network allows you to tap into its network effect - you're not only connected to a few parties, but to potentially everyone in the world.

Conclusions


All in all, there are advantages and disadvantages to both using centralized and decentralized blockchains. Every one of them is a tool of its own, and some might be more suitable for problems than others. While the Bitcoin network certainly has a lot of value on its own, it's not a silver bullet solution to all problems and use cases. Blockchain without Bitcoin is certainly possible, but even in the world filled with centralized blockchains, Bitcoin has a place of its own.

2015-06-10

Handling bitcoins during a hard fork - pondering Bitcoin XT

As everyone might've heard by now, there is a big debate in the Bitcoin community about whether or not we should increase the block size limit. Some core devs are pushing for the size increase with the Bitcoin XT version, and it looks like some people might be committed to the hard fork even if the community would be against it. This can be a potentially dangerous move that fragments the Bitcoin world to those that use Bitcoin QT and those that use Bitcoin XT. If this was to happen and both of the versions were to coexist, there is a lot more than just confusion to be had for anyone that holds funds on behalf of their customers.

Hard fork and the transactions


Initially, when the hard fork happens, all transactions will be interchangeable between the two blockchains - after all, they will be spending the same outputs using the same algorithms. You could broadcast the same transaction to both blockchains and they will be able to get into the blocks just fine. However, this also means that any withdrawal from shared wallet, like from an exchange or CoinBase, may siphon the funds out of both chains even if the service is using only one chain. If a service was to ever switch over to the other chain, their balances might be out of order.

Over time, the networks will start drifting apart. Any transaction that spends the coinbase transaction of a block minted post-fork won't be copyable to the other chain. Similarly, any conflicting transactions will only be valid on one chain.

Since Bitcoin network currently has a lot of unspent outputs (such as the ones tied in physical bitcoins), we will probably see transactions valid on both chains for years to come.

Confusion about addresses


After the fork happens, there can be a lot of confusion as to what network everyone is on. If the address structure remains identical, someone asking you "to send 1BTC to 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm" might be confused when you send that amount of money to the listed address, but on a different network.

Maybe the devs behind BitcoinXT will take some precautions to prevent such mistakes by altering the Base58 alphabet in a similar fashion to Ripple (yes, Ripple addresses are identical to Bitcoin with the difference of the final Base58 alphabet used). Perhaps BitcoinXT addresses would start with an X instead of 1 without changing the underlying mathematics behind address creation or net bytes?

Recommendations for exchanges and other services


Even if one side of the fork will be more likely to stick around than the other, it is still useful to be prepared to exist on both sides of the fork. My recommendation for any exchange or service relying on a shared wallet is to make a backup of all user balances on the day the fork occurs. Since those Bitcoin balances would be valid on both chains, if the service was to support both sides of the fork, users should receive the same balance in BitcoinQT and BitcoinXT.

After that, both the hot and cold wallet balances should be spent on both chains in a conflicting fashion (send all funds to A on BitcoinQT, and all funds to B on BitcoinXT). After both transactions are confirmed on the separate forks, there will be no chance of the same transaction being copied between the chains. The balance of whichever chain is not used should be safely stored for the time being along with the backup of user balances.

If an exchange was to support both of the chains, supporting them straight away would create the least amount of confusion. Users should receive the same balance on BitcoinXT as they currently have on BitcoinQT, with their fiat balance remaining intact. Afterwards, the users would be free to trade both coins like they would be separate altcoins.

Conclusions


A Bitcoin hard fork might be coming. Exchanges and hosted wallets should have a plan of action if both chains were to co-exist.