Month: February 2014

Can we value Bitcoin?

/ Robert Sams / 3 Comments

In a post a few weeks ago I wrote:

A more sophisticated defence of Bitcoin’s valuation goes like this. Bitcoin is great SOV not just because of its limited supply and those hashing cost network effects. It’s a great SOV because in future more and more people will use it as a medium-of-exchange (MOE). As the volume of bitcoin transactions increases, so will the demand to hold bitcoin balances for the purpose of making transactions in goods and services. But a total of only 21 million bitcoins will ever be produced, so the price of a bitcoin must reflect the ratio of expected future MOE money demand to 21 million. The price of Bitcoin, one might argue, is the market’s prediction of the long-term growth rate of bitcoin transaction demand.

Now, on Twitter today Marc Andreessen, links to Fortune article citing Stanford economist Susan Athey, who apparently makes an argument virtually identical to the above:

An anonymous viral email circulating among bitcoin watchers and partisans lays out a few simple hypothetical usage and adoption scenarios, and their consequences for bitcoin’s price. If Amazon.com adopted bitcoin for all payments, its volume of $38 billion, divided by a supply of (at the time of the email’s writing) about 7 million bitcoin, would make each bitcoin worth $5,400. If $300 billion in international remittance was conducted in bitcoin, that volume alone would push the price to $42,000. Adding these, along with online poker and gas station transactions, would lead to a total transaction volume of $602 billion – and a bitcoin, even at today’s expanded supply of 12 million coins, worth $50,000.

“Those numbers are good ones to start with. In some sense, that’s like a maximum,” says Susan Athey, a professor of economics at the Stanford Graduate School of Business who has been studying bitcoin. Few would realistically argue that bitcoin will service 100% of even these silos in the near term, but the volume/supply ratio is the starting point for understanding bitcoin price – as more consumers or organizations choose to use bitcoin, increased volume will drive the price up.

Building from that basic formula, Athey adds a variety of variables to build an analytic framework. The first is velocity – how frequently a bitcoin can be spent. Because bitcoin, unlike paper money, is very low-friction, there’s the possibility of a very high-velocity bitcoin, if, for example, vendors or traders only held bitcoin very briefly, cashing it in and out to government currencies on either end of transfers. That, Athey says, would allow a small volume of bitcoin to process a large volume of payments, keeping the price of bitcoin relatively low.

I’m not privy to this exchange, so I don’t know how much of this argument is attributed to Athey and how much is the Fortune journalist’s own thinking. A bit of Googling turned up this interview with Athey in November of last year:

What do you think about the bitcoin price increases recently? Well, if you expect the volume of transactions to grow a lot, then the exchange rate from dollars to bitcoins has to grow too, because each bitcoin can only be used so many times per day. The market value of all bitcoins has to be enough to support transaction volume. You could interpret the price increases as reflecting increased optimism about the future volume of transactions, driven by China implicitly signaling that it will allow bitcoins to be used for commerce there.

As I pointed out in my previous post, this is a more sophisticated rationalisation of a Bitcoin’s valuation than one usually reads. As a cryptocurrency pays no income, the only way to value it fundamentally is in terms of expected future cryptomoney demand (uncertain) in relation to its future supply (deterministic and completely predictable in Bitcoin). By “cryptomoney demand” we mean: crypto coin balances held for the purpose of facilitating transactions in that coin.

Money demand is proportional to the level of transaction volume if velocity–the number of times the coin supply changes hands over the period–is stable. So, if we can make that assumption of stable velocity, the price of Bitcoin today should reflect expectations of future bitcoin transaction volume. Let t be some future time when the growth rate of transaction volume TX(t) levels out and let V(t) be the velocity at time t, and S(t) is the supply of bitcoin:

price(BTC) = \frac{TX(t)}{V(t)} \times \frac{1}{S(t)}

The calculation cited above arriving at that BTC = $50,000 is implicitly assuming a money velocity of 1, which goes against the Silicon Valley vision of a Bitcoin-as-payments unit that people swap in and out of via intermediaries like Coinbase and BitPay. In that scenario, velocity will be very high.

Here is a back-of-envelope valuation. Let’s say that t represents year 2024 and that bitcoin transaction growth levels out in about 10yrs time. Now, let’s fix an assumption of velocity at that time. The money velocity of USD M1 is about 7, so I would guess that Bitcoin velocity will be rather higher than that. Let’s just say, arbitrarily, that Bitcoin velocity will be 10X USD money velocity. So BTC = $650, V(t) = 70, and S(t) = 20 million, making TX(t) = $910 billion, almost 6% of the US economy.

The result isn’t totally crazy. Here are the blockchain transaction volume figures for the last four years, converted into USD values at the time of transaction (as calculated by blockchain.info): 

year         volume  growth
2010        985,887      0%
2011    418,050,216 42,303%
2012    601,415,369     44%
2013 15,216,615,077  2,430%

Much of that volume will be FX settlements and payments between addresses controlled by a single entity, and those volumes shouldn’t be included in the analysis. How much is difficult to estimate (something that we’ll look into in a future post), but let’s say that half of that volume should be excluded, so the current base is 7.6 billion per-year. Annual volume of 910 billion annual in a decade’s time is a bit over 60% compounded growth per year. In light of recent history, the result is conservative!

The problem with this sort of valuation analysis is that the inputs TX(t) and V(t) are entirely speculative. Assumptions, assumptions, assumptions. You can plug-in anything you like. It’s like valuing a new business.. but worse. In Bitcoin the S(t) is basically fixed in future horizons (never more than 21 million), so any change in the market’s assumptions translates into changes in the exchange rate. Bitcoin translates that uncertainty about its future prospects into present exchange rate volatility. And that exchange rate volatility dampens demand today for using bitcoin as a medium-of-exchange, undermining the very assumptions behind its current valuation. To me Bitcoin–not cryptocurrency in general, but Bitcoin–is like one of those M.C. Escher drawings, where the impossible looks deceptively plausible.

The Bitcoin-as-payments people will reply that the volatility doesn’t matter, that I’m wrong in saying that the volatility undermines the transactional demand for bitcoin. Here’s a recent claim by Andreessen:

The criticism that merchants will not accept Bitcoin because of its volatility is also incorrect. Bitcoin can be used entirely as a payment system; merchants do not need to hold any Bitcoin currency or be exposed to Bitcoin volatility at any time. Any consumer or merchant can trade in and out of Bitcoin and other currencies any time they want.

Athey qualifies this position a little (from the same interview above):

What about the extreme volatility? Volatility is bad because it increases frictions—if I just want to send you $100, the exchange rate might change between when I buy the bitcoins and send them to you, and when you receive and cash them out. That creates risk and frictions. But the level of the exchange rate is irrelevant for the efficiency of the payment rail—if I knew it would be $1000/bitcoin all day long, or $100/bitcoin, either way I can buy bitcoins, send them to you, and you can sell them, while avoiding paying exorbitant bank fees. You still incur some fees when getting money in and out, but those are relatively low and should fall over time with competition.

But the irreducible component of the costs facing those merchants Andreessen speaks about are those very “risks and frictions”, they make the price of offloading that volatility to someone else. Competition will not reduce those costs any more than competition among options dealers will reduce the price of a put on the S&P 500.

Is the 1% fee that Coinbase charges for the service of offloading exchange rate volatility sufficient to cover their cost of hedging a coin whose USD volatility is more than 7 times that of the stock market? There are a smart bunch of people behind that company, so I’m reluctant to second-guess the business model. But I feel I must.. and may do so in detail in a future post.

The implicit assumption behind the comments of Andreessen and Athey is that Bitcoin’s money velocity can be arbitrarily large, a hot potato that gets passed around so quickly that the volatility of the coin can be made negligible to the party using it as medium-of-exchange. But the Bitcoin protocol itself places a lower limit on the speed of transaction confirmations, placing an upper limit on Bitcoin’s velocity. Whatever that velocity turns out to be, the interval between time coin received and time coin paid will impose an irreducible risk on the party who wishes to use Bitcoin to make payments. A risk that is costly to layoff to someone else.

But I am a believer in cryptocurrency, I would just prefer to back a cryptocurrency where whose supply was more responsive to its demand, where \Delta S(t) is a function of \Delta TX(t), or a function of the exchange rate itself. This can be done in an entirely trustless way, and such a coin is likely to have a much more stable exchange rate and be a better medium-of-exchange.

Bitcoin, Ethereum and Pigou: the economics of transaction fees

/ Robert Sams / 2 Comments

The economics of transaction fees in cryptocurrencies are poorly understood. In a previous post I raised some questions about how using tx fees to compensate for hashing costs (as Bitcoin’s declining coinbase award increasingly does over time) can be incentive-compatible with transaction demand for cryptocurrency. There, I was concerned about the distribution of seigniorage between existing coin holders and hashing costs, and what this implies for tx fees.

A new post on the Ethereum blog focuses on another aspect of transaction fee economics: a tragedy of the transaction verification commons.

The essence of the problem is this. In Bitcoin, tx fees are effectively set by what tx miners choose to include in their blocks. The creator of a tx can pay any fee he chooses, but miners are free to ignore a tx, so a payer who pays a relatively large fee is more likely to have a faster-than-average confirmation time. On the surface, this looks like a market mechanism. But it isn’t. The miner gets the tx fees of every tx included in a block that the miner solves. But every node on the network pays the costs of verifying a transaction; tx must be verified before relaying and building on top of a solved block. Therefore, a miner will include any tx with a fee in excess of his computational costs of verifying it (and reassembling the Merkel tree of his block), not the network’s computational costs of verifying it.

A single, very large block containing many transactions with many inputs/outputs can bog down the network. To deal with this, the Bitcoin protocol imposes a 1MB upper limit on the size of a block. This isn’t a great solution. Not only does it put an upper limit on the number of tx Bitcoin can process per unit of time, it does nothing to rationalise tx fees to tx verification costs.

It’s like an airline that puts a 1000 suitcase (irrespective of size/weight) limit on luggage per flight, and deals with the problem of >1000 suitcases by prioritising those passengers that volunteered to pay a fee. Those who pay the lowest/no fees have their bags kicked off the flight, and placed in a que to for inclusion in subsequent flights (that employ the same 1000 suitecase limit). What will eventually happen is that those with big, heavy bags will pay the highest fees and have their bags included in the flight, as those fees will still be lower than the actual cost of shipping the luggage. Those with small/light bags will get kicked off, unless the passenger is willing to pay more than the marginal cost of shipping his bag. If airlines are a competitive market, those guys will eventually just chose to travel on a different airline that doesn’t ask them to subsidise pack rats.

From Ethereum’s post:

The question is, is this kind of market the right model for Bitcoin transactions? To answer this question, let us try to put all of the players into roles. The resource is the service of transaction processing, and the people benefiting from the resource, the transaction senders, are also the buyers paying transaction fees. So far, so good. The sellers are obvious the miners. But who is incurring
the costs? Here, things get tricky. For each individual transaction that a miner includes, the costs are borne not just by that miner, but by every single node in the entire network. The cost per transaction is tiny; a miner can process a transaction and include it in a block for less than $0.00001 worth of electricity and data storage. The reason why transaction fees need to be high is because that $0.00001 is being paid by thousands of nodes all around the world.

It gets worse. Suppose that the net cost to the network of processing a transaction is close to $0.05. In theory, even if the costs are not borne by exactly the same people who set the prices, as long as the transaction fee is close to $0.05 the system would still be in balance. But what is the equilibrium transaction fee going to be? Right now, fees are around $0.09 simply because miners are too lazy to switch. But then, in the future, what happens once fees become a larger share of a miner’s revenue and miners have a large incentive to
try to maximise their take? The obvious answer is, for a solo miner the equilibrium transaction fee is $0.00001. If a transaction with a fee of $0.00002 comes in, and the miner adds it, the miner will have earned a profit of $0.00001, and the remaining $0.04999 worth of costs will be paid by the rest of the network together – a cryptographic tragedy of the commons.

The Ethereum guys have defined the problem clearly. And I’m not encouraged by what (I think?) is the current thinking of the Bitcoin developers in dealing with this problem. From the Bitcoin Foundation’s blog:

I’ve been working on teaching the wallet code to estimate how low a fee (or priority) a transaction needs, at the moment it is sent, to be accepted by miners and included in the next block or three. The estimates are based on watching transactions as they are broadcast on the network and keeping track of which of those transactions are accepted into blocks.

The danger with estimating transaction fees is miners have an incentive to try to game the estimate to make transaction fees higher. For example, if the estimate was based on the average transaction fee for all transactions in the last N blocks, miners could add very-high-fee pay-to-self transactions to the blocks that
they mine to drive up the average. However, by only considering fees for transactions that have been broadcast on the network that threat is eliminated– miners could broadcast very-high-fee pay-to-self transactions, but would end up paying those high transaction fees to other miners. The transaction estimation code also uses median transaction fees, not averages, to make it much harder for a minority of transactions to influence transaction fees.

But this won’t work in the end, for even a perfect estimate that is not contaminated by strategic actions by miners will still be an estimate of the marginal cost of tx verification faced by a single miner, not the network as a whole.

It’s not surprising that the Ethereum developers have cut to the core of this problem. In Bitcoin, you can at least be sure that the execution of scriptSig and scriptPubKey will halt after time proportional to tx size. Not so with Ethereum’s Turing-complete scripting language. For Ethereum, the problem of rationing network resources over tx verification and contract computation is acute. The project simply will not work without an economically equilibrating solution to this problem.

Their current thinking is that tx fees should be destroyed (no recipient) and calculated along the lines of a Pigovian tax via a some mechanism of miner or ether holder consensus. I’m not convinced that this will work, but this post gives me confidence that the guys behind Ethereum are taking the economics of crypto seriously. Let’s all pitch in and help them solve this problem.

Ethereum: Turing-complete, programmable money

/ Robert Sams / 5 Comments

Ethereum is a new cryptocurrency project started by Vitalik Buterin and Charles Hoskinson and others. Part of that project is a new currency, called “ether”, but this is NOT another alt-coin. In my opinion, it’s the most interesting project in the crypto space since the introduction of Bitcoin itself. Assuming that it works, that is. The testnet was just released.

So what is Ethereum? In some respects, its design is similar to Bitcoin. Miners hash blocks of transactions and are rewarded in newly-created ether coins. It uses a new proof-of-work hashing algorithm called “Dagger”, which is, like Scrypt (the hashing algo used by Litecoin and most alt-coins), designed to be Memory-Hard. The developers are also experimenting with a new proof-of-stake mechanism called “slasher”, but the intention seems to be to promote a research effort to create a Memory-Hard algorithm that will be resistant to dedicated hardware like ASIC’s. The blockchain protocol is also different; Ethereum will use a variant of the new GHOST protocol, which should allow for a much shorter time interval between blocks.

So far, that just sounds like a state-of-the-art alt-coin. The real innovation is Ethereum’s Turing-complete scripting language. This is very cool, as it implements a new entity on the network, a programmable contract. From their whitepaper:

A contract is essentially an automated agent that lives on the Ethereum network, has an Ethereum address and balance, and can send and receive transactions. A contract is “activated” every time someone sends a transaction to it, at which point it runs its code, perhaps modifying its internal state or even sending some transactions, and then shuts down.

In Bitcoin (and the alt-coins), tx are generated and received by addresses. In Ethereum, contracts too can generate and receive tx. This creates endless possibilities. For example, in Ethereum, one could create a CFD. From an article by Buterin:

Each Ethereum contract has its own internal scripting code, and the scripting code is activated every time a transaction is sent to it. The scripting language has access to the transaction’s value, sender and optional data fields, as well some block data and its own internal memory, as inputs, and can send transactions. To make a CFD, Alice would create a contract and seed it with $1000 worth of cryptocurrency, and then wait for Bob to accept the contract by sending a transction containing $1000 as well. The contract would then be programmed to start a timer, and after 30 days Alice or Bob would be able to send a small transaction to the contract to activate it again and release the funds.

In the CFD example, I think the idea is something like this. Alice wants to bet on the change in next quarter’s US GDP. She creates a contract that includes a formula like PAYOUT = (ALICE_PREDICTION - GDP1Q2014 / GDP4Q2013 - 1) * GEARING and funds it with 10,000 ether. This is like a limit order. The script in the contract specifies that anyone who sends 10,000 ether to this contract will take the other side of this trade. The script also contains the public key of an “oracle”, eg a trusted website that publishes economic stats for the purpose of authoritatively fixing the settlement value of CFD’s. After X days the script consults the oracle, pays it a small fee, and gets signed value for GDP1Q2014, which script checks against the oracle’s public key. Script then computes the formula and sends Alice max(10000 + PAYOUT,0) ether and Bob max(10000 - PAYOUT,0) ether.

Some other contract types that have been suggested:

  • Multisignature escrows
  • Savings accounts
  • Peer-to-peer gambling
  • New currencies within Ethereum

As Buterin says:

This is the advantage of Ethereum code: because the scripting language is designed to have no restrictions except for a fee system, essentially any kind of rules can be encoded inside of it. One can even have an entire company manage its savings on the blockchain, with a contract saying that, for example, 60% of the current shareholders of a company are needed to agree to move any funds (and perhapps 30% can move a maximum of 1% per day). Other, less traditionally capitalistic, structures are also possible; one idea is for a
democratic organisation with the only rule being that two thirds of the existing members of a group must agree to invite another member.

Interesting stuff. Bitcoin’s advocates have always emphasised that Bitcoin is a decentralised payments system as well as a currency, and have gone to great lengths to build on top of it a richer set of financial exchange so that assets other than bitcoin can be traded on the blockchain. coloured coins, and protocols like Mastercoin are the best examples of these efforts.

The Ethereum guys share the same goals of these projects, but have a very different view about what the underlying technology needs to be to make them happen.

..as far as being an effective low-level protocol is concerned, Bitcoin is less effective; rather than being like a TCP on top of which one can build HTTP, Bitcoin is like SMTP: a protocol that is good at its intended task (in SMTP’s case email, in Bitcoin’s case money), but not particularly good as a foundation for anything else.

What makes Ethereum more like TCP and Bitcoin more like SMTP is that the former contains a Turing-complete scrip system whilst the latter does not. Bitcoin’s scripting system was deliberately made to be not Turing-complete to protect the network’s peers from malicious and buggy code. Instead of restricting the scripting language to deal with this problem, Ethereum uses an economic solution: tx and contract fees.

Ethereum will be like a giant distributed computer that automates all sorts of useful financial processes, as well as hashing tx blocks to define distributed ledger, like Bitcoin’s network does. But on Ethereum, contracts will have to pay fees to have their computations done, to compensate peers for resources consumed to run the contracts, and to make error and malice costly. My guess is that much rides on how effective this solution turns out to be. Bitcoin is very robust. It is also much less complex by not having Turing-complete scripting.

I will blog more on Ethereum as I learn more about it. I wish this project much success. The concept is brilliant if it actually works.