The Money Protocols - Bitcoin, blockchain and others

I was recently sent a link to an article discussing the development of "the money protocol". The idea has been around for awhile - we have standardized protocols for communicating between computers in form of TCP/IP and others, so it would similarly make sense to develop protocols for moving money around on the Internet just like now we move information around it. However, we will likely have more one new protocol created from Bitcoin and related technologies...

Accounting for all payments

In an ideal world, we would have everyone using the same currency on the same network. However, there are many reasons why this probably won't happen. Instead of hoping everyone will start using Bitcoin in the near future, we should assume that we will be dealing with many different currencies, both cryptographic, fiat and otherwise. We will need a protocol that can handle:

• Native cryptographic currencies like Bitcoin
• IOUs, assets and debt, like what we see on Ripple
• Financial derivatives, like BitUSD on BitShares
• Private currencies on permissioned blockchains
• Legacy banking systems
• Credit, debit and gift cards
• Other currencies created / tracked by private companies (perhaps shares, digital commodities, etc.)

Moreover, the protocol would also need to cover:

• Sending payments across networks (bank->Bitcoin, altcoin to sidechain, etc.)
• Finding an optimal payment path between the start and end of the payment
• Atomically trading between multiple currencies at the same time
• Locking in / confirming trades and money transfers
• Providing digital receipts for the payment

All of those would need to be included in the same "money protocol". Once we figure out how to convey the information of who is sending the money, who is the receiver, which type of money is being spent and received (more on how this could look), we can finally start to connect different networks together. Whether it would be through W3C's Web Payments Community Group, something like Interledger or some other forms of bridges, we could finally be able to easily send money around (hopefully).

What's left?

When dealing with crypto as they say, money is the least interesting application. We also have smart contracts, proof of existence, etc. A lot of those applications of crypto will probably also warrant their own protocol - they don't exactly fall under "money protocol". I do believe the following will eventually become their own protocol on par with TCP/IP:

Proof of existence. As we all know, the Bitcoin blockchain is the most secure, inalterable record of history currently available due to the amount of computing effort put into it. Anything embedded in the blockchain can be forever referenced as the latest date some file could've been created. This functionality, perhaps expanded with protocols like Factom, can be a useful protocol for creating timestamped receipts and other applications.

Smart contracts / smart oracles / proof of execution. With Ethereum being released, we can expect to see more use of smart contracts for business applications. Smart oracles, such as the ones proposed by Codius. would compliment them to interface between the crypto and the real world. All in all, we could bundle those up into "proof of execution" - a protocol dictating what code needs to be run, at what time and by how many independent parties (some of them in form of computers, some in form of autonomous contracts), as well as what was the result of the execution. This could enable, for example, to build autonomous financial derivatives or contracts ("code is law").

Conclusions

It is very likely in the future we will see a "money protocol" similar to TCP/IP for money. It will have to encompass more than a single currency and network however. We are also likely to see more blockchain-based protocols emerge from the non-monetary applications of crypto.

Gaming Proof of Stake

While working on a draft for a paper for the upcoming Ledger academic journal I came across the concept of "stake grinding". After considering this problem for awhile, I think I came up with a neat solution to it under some specific conditions. Lets discuss...

Proof of Stake and Stake Grinding

Proof of Stake is an alternative block generation algorithm to Proof of Work. In it, blocks are not generated by mining pools roughly in proportion to the computing power they hold, but by block producers / minters / notaries or however you want to call them roughly in proportion to the amount of coins they own / stake.

In PoW, blocks are created at random whenever a solution is found, making the network block creation time somewhat random and unpredictable.

In PoS, the blocks can be generated on a more fixed schedule since once a block is created there is no randomness as to who should create the next block - the minter is picked using the randomness inherent in block creation and the balances in the network.

However, if we use a naive implementation of PoS, we open ourselves to the block minters grinding the block to ensure they are also the creators of the next block or some other block in the future (say, if you use a scheme where a block minter is selected by an entropy from 100 blocks back). If you have only one attacker grinding the blocks, they will eventually become the only entity creating the blocks no matter how small their balance is. Since honest minters would select them to mine the blocks every now and then and the attacker would make sure their blocks nominate them to be the minters with 100% certainty, they will be minting more and more blocks.

From what I could find (see section 6.4), stake grinding has been used on a few systems like NXT or Peercoin with success, forcing the networks to abandon the naive approach.

Potential solutions

There are a few solutions to stake grinding. Peercoin appears to have adopted a hybrid PoS-PoW model to make grinding less trivial. BitShares used a Delegated Proof of Stake where the block minters each get to create one block before the order is reshuffled and everyone gets another turn - an interesting approach, but it treats a minter with 50% of support the same as one with 10% of support.

Now, there might be a way to implement Proof of Stake in such a way as to avoid the grinding problem altogether and reward all minters in proportion to their stake / support. It is inspired by CGP Grey's video on Mixed-Member Proportional Representation voting system (a part of his very interesting series "Politics in the Animal Kingdom"):

In the new scheme, we would need to create a list of all minters that want to participate in the block creation process and figure out their weight based on the amount of stake / support / votes they represent. The list would have to be locked in for a certain minting period, similarly to BitShares' implementation. Given this information, we can start creating blocks in a deterministic fashion. Each block minter would be chosen based on who is the most underrepresented in a given minting period. They would be chosen to be the next block minter. After a new block is created, the representation is updated and the next minter is chosen in the same fashion. You could also deterministically break up large chains of blocks being created by the same minter to prevent 51% attacks, or implement a punishment algorithm for creating forks.

This approach would both eliminate grinding and give fairer rewards than DPoS.

Liquid - when sidechains say "fuck it"

We had big news in the Bitcoin world - Blockstream, the company that has been working on sidechains for awhile has announced they will be launching their first sidechain called Liquid. The announcement is all over CoinDesk, BitcoinMagazine, IHB and others. Unfortunately, when you look closer, what is being proposed is not really fulfilling the promise of sidechains...

What is Liquid?

Liquid is a settlement system for Bitcoin exchanges. It allows one to "[reduce] the time in which bitcoin-denominated funds can be transferred between accounts at these institutions" [1] and "allowing partner exchanges to move funds between order books without the need to transfer funds on the bitcoin blockchain" [1] for "an undisclosed monthly subscription fee" [1]. This will be accomplished by "[finding] partner exchanges transferring funds to a shared multi-signature wallet address, with a Byzantine round robin consensus protocol used to process transactions"[1]. The network will be run by known exchanges, essentially boiling down to a permissioned blockchain. The block signers will be running on proprietary hardware to prevent "tampering with the block signers when they are up and running [, further minimizing trust].".

What are sidechains?

Even more so than "blockchain", "sidechain" is a bit of a nebulous term. Blockstream, who are pretty much the main developers in this space have defined the term in their whitepaper as

"A sidechain is a blockchain that validates data from other blockchains"

This opens it up to interpretation as to what is and isn't a blockchain. Is Bitcoin a sidechain since it contains Factom blockchain data? Is Counterparty a sidechain since you can trade BTC on it? Is Ripple a sidechain since we have services like BitStamp and SnapSwap being Bitcoin gateways onto the system?

I personally expand the term to "a blockchain with a distributed two-way pegged currency from other blockchains" (a quick refresher on centralized, decentralized and distributed definitions). Generally, it should be a system that is not rely on a handful of centralized gateway / bridges to move value back and forth between the networks, but a more protocol-level way of achieving deposits and withdrawals.

Having a one-way peg is dead easy - we've done proof-of-burn years back. Two-way peg, unfortunately, requires a soft fork in the Bitcoin protocol, or an entirely new system to be built from grounds-up.

Liquid is not innovative

Looking at what has been said about Liquid - it's not an innovative technology. It can be boiled down to:

• Funds are deposited in a multisig address controlled by multiple exchanges [2]
• Transfers between the exchanges happen when multiple exchanges sign off on the transaction in a mechanism similar to green addresses [2]
• Transfers require no confirmations because the network won't sign a double-spend against itself

The technology is nothing new - we've had multisig since 2012, and even frigging MtGox used a green address in 2011.

I'm also not yet sure whether Liquid provides some cryptographic receipts for deposits. If they don't - the network isn't entirely gox-proof. You may have proof-of-liquidity (balance in the multisig address), but you'd be lacking proof-of-liabilities - exchange clients or counterparties being able to prove who is owed how much in case the servers blow up due to incompetent PHP programming. Having a pile of bitcoins and a mob of people is not enough to know who is owed how much.

If Liquid has proof-of-liabilities or some other form of cryptographic receipts, that is great! It means they can be compared to Open Transactions' Voting Pools idea from 2014.

Now, to be fair - you don't need to be innovative to be useful, just be honest about it. What Liquid is, I wouldn't classify as a sidechain, but it can still bring a lot of value to their customers. That being said...

Liquid is not enough

Do I believe being able to speed up BTC transfers between exchanges is a useful thing? Yes. However, do you know what is the biggest pain point in Bitcoin exchanges and arbitrage? The fiat part. I'll be able to save an hour or two on my Bitcoin deposits to lock in a trade at a good exchange on another continent, but then I'll have to wait a few days for my fiat to move around so I can arbitrage in the other direction, great. Well, maybe pairing this with something like Tether would be good enough...

Other points

A few last points that don't fit anywhere before I wrap up:

• Proprietary hardware requirement - if someone told me that to run some system that takes care of my coins I would have to use their proprietary hardware, that's where the conversation would end. I understand, you want the system to be hardened against attacks, but that's exactly why you need heterogeneous network - if everyone has the same hardware and software, you can take down the entire network with the same exploit. Not to mention, proprietary hardware doesn't fit well with "trust but verify" model of Bitcoin.
• Obfuscated balances and trade data - cool feature, as long as it doesn't interfere with proof-of-liabilities

Conclusions

Liquid looks like a very interesting project, but it's not the sidechains we are looking for. I guess it's a fair compromise between not being able to do anything because one needs a soft fork to implement the full vision and launching a whole altcoin just to have sidechains properly implemented. I guess you can only wait so long for things to improve before you say "fuck it" and create something between where we're now and where you're aiming to be in the future.

[1] - http://www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/
[2] - https://www.reddit.com/r/Bitcoin/comments/3ok8ga/blockstream_announces_liquid_bitcoins_first/cvydu7r

EDIT:

I heard rumours about the proprietary hardware used for Liquid being secured by thermite that would destroy the hardware if it was tampered with. Reportedly, the hardware would have to be picked up in person as well. While I can't find a reference for those statements, if they were true it would make the situation even weirder (perhaps making it quite problematic for companies to get a hold of those outside of the country they would be produced in - try bringing such highly flammable package onto a plane...).

Related discussions:

• https://www.reddit.com/r/Bitcoin/comments/3orjmz/liquid_when_sidechains_say_fuck_it/ 
• https://www.reddit.com/r/Bitcoin/comments/3p6mn2/liquid_created_the_beating_heart_of_a_new_banking/

Blockchain for banks - an overview

As discussed before, the banking world appears to be looking into the blockchain space with companies like Digital Asset Holdings or R3 CEV gaining some momentum. However, a lot of people seem to see the blockchain as a silver bullet to solve a number of unspecified problems for the banking industry. Today, I would like to share with you a possible overview of how a blockchain-powered banking system might work using both public and permissioned blockchains.

Identifying the problem

There are many different needs that both the banks and their customers have. A commercial bank will have different priorities from a retail bank, and they both will have different priorities from an investment bank. The blockchain technology is very well suited for settlement between parties. More complicated functionality can be either accomplished by a more focused technology like Open Transactions or more general smart contracts available for example on Ethereum. We will mainly focus on the settlement problem in this post, but will mention other issues as they fit in.

Is blockchain the way to go?

A blockchain is a very specialized tool. As discussed before, it is similar to a database, with a few notable differences. Performance-wise, blockchains might not be as efficient as centralized or distributed databases, but what they lack in performance they make up in other areas for some projects.

A blockchain enables accountability. A public blockchain like Bitcoin is a publicly verifiable, unalterable record of history. A permissioned blockchain may still be subject to forging of records if it is kept completely private, but if it is shared with an independent auditor or a digest of the records are anchored in projects like Factom, they can also be provably unalterable.

A blockchain is also a good way of reaching distributed consensus if the involved parties don't trust one another, say for international bank settlement between Russia and USA. If all parties run on the same protocol with conflict resolution, there is no doubt which transactions came through and in what order for example.

On the flip side, depending on the technology used, the blockchain might have lower transaction throughput than a dedicated, centralized server / database. At the moment the fastest ledgers update in 2-5 second intervals (in case of Ripple). To go faster, one would need to use ledgerless technology, such as Open Transactions.

Public versus permissioned blockchains

When we have identified which problem to solve and believe using the blockchain is the way to go, we should consider whether to use public or permissioned blockchains to help us achieve our goal. Pretty much everything that can be done on a public blockchain can be also achieved on a permissioned blockchain. Bitcoin and coloured coins act similarly to MultiChain. Ethereum can be approximated by Eris, and Ripple - by Hyperledger. Worst case scenario, most crypto projects can be forked from their open source repositories and modified to suit the particular needs.

Since the permissioned blockchain is handled by known, controlled servers, it can be pushed to achieve higher performance than a public blockchain by using higher-end hardware and network capabilities. Similarly, the more controlled environment is not at a whim of spammers, transaction fee fluctuation or any external forces.

That being said, a permissioned blockchain in many cases is a walled garden barring entry to a lot of possible innovators. While this can be useful for protecting sensitive information, you can also miss out on the network effect from using the public blockchain. It's just like the internet and the intra-net - both have their uses and drawbacks.

For a lot of applications, it might make sense to either be completely on a public blockchain, or at the very least operate on both the public and permissioned blockchains at the same time. For example, if SEPA operated its own permissioned blockchain to offer settlement between all the European banks, it could also offer similar services on a public blockchain for lower-frequency transactions and perhaps a bridge to connect between the blockchains. This way if someone decided to build, say, a settlement corridor between Europe and America, they could use the already available public blockchain without having to apply for a banking license to get access to the premissioned one. This would enable more innovation to take place on low-performance environment while keeping the core network performing very efficiently for high-volume transactions.

Just to note - a public blockchain does not mean everyone would be able to use the solution indiscriminately. Pretty much every blockchain offers some way of controlling who can access various currencies issued on it, either through the use of white- and blacklists or through multisignature. This means that the banks or governments can still follow with KYC and AML requirements, even if the blockchain is public for viewing.

Picking the right approach

As with most situations, there are many ways to approach a problem on a blockchain. For example, in order to do international settlement, one can issue fiat-denominated currencies, copy an existing FX market and use that for currency conversion, use an intermediary cryptocurrency like Bitcoin (an approach used by Abra for example), or perhaps create a smart contract to handle the trades. The number and kind of options will depend on your problem at hand and it's hard to generalize this point.