Over the past couple of months there has been a number of discussions revolving around increasing the Bitcoin block size from its current 1 MB limit to 20 MB. One such plan is Gavin Andresen’s proposal (this is not to single him out as there are others with similar proposals). The code change itself is trivial, as it can simply be changed to any arbitrary number in a couple of keystrokes (for instance, see Vitalik Buterin discuss this at 14:15).

However, getting the majority of validating nodes, miners and the rest of the ecosystem on-board in a timely fashion is a very non-trivial matter.

Recall that, as illustrated by Organ of Corti and Dave Hudson, the average block size has increased over the past year to the point where we will likely max out at around 3 transactions per second with the current 1 MB limit. Since many of the investors, developers and entrepreneurs in this space would like to make Bitcoin ‘competitive’ to other payment platforms such as Visa, according to their view, this number eventually needs to increase by several orders of magnitude.

Fundamentally there are two trade-offs in block size economics:

• Keeping a 1 MB block size requires higher fees to end-users but results in a more decentralized network
• With a larger, 20 MB block size, fees are (temporarily) subsidized to end-users but with fewer validating nodes on the network

A quick explanation of both:

• Retaining a 1 MB block size ultimately results in higher transaction fees because block space is scarce and miners will only process and include transactions based on market-based prioritization rates (e.g., pay higher to be included faster). While this would likely mean the end of certain types of transactions (such as “long chain” transactions) as well as fee-less transactions which have disproportionally increased the size of the blockchain over the past six months relative to actual commerce, simultaneously this design decision would have the effect of retaining some nominal decentralization as the increase in blockchain size would remain relatively linear and thus the blockchain could be validated by several thousand nodes as it is done today without (much) additional cost.

In early March 2014, there were approximately 10,000 nodes however over the past year there has been a decline by roughly 1/3. What does this distribution of roughly 6,400 current nodes look like?

Recall that the original value proposition of the Bitcoin blockchain was its decentralized characteristic, thus the more miners and validation nodes that are geographically distributed, the less prone the network is to single-points of failure. Furthermore, while many people call the various artifacts that have increased the blockchain size “bloat,” because this is a public good and no one owns it, it is imprecise to do so (e.g., one man’s 80 byte “trash” OP_RETURN is another man’s data storing “treasure“).

Whether consumers are sensitive to this change in fees is another matter due to elastic demand, they may simply switch over substitute goods (e.g., competing chains and ledgers).  What does this mean exactly?

• An increase to a 20 MB block size would likely continue the same “low” fee (donation) structure practiced and promoted today as there is purportedly more room for non-priority transactions. The known challenge however is that if 20 MB blocks became “filled,” this would require a corresponding increase in bandwidth and disk space which would require more costs to be borne by the validating nodes which are already operating as public goods. That is to say, a blockchain that increased in size by 20 MB every 10 minutes would fill over 1 terabyte a year which would create additional costs for participants and likely reduce the amount of verification nodes and therefore reduce the decentralization of the network.

The other challenge to Andresen’s plan is, that because the prioritization of transactions would still not be adjusting towards via fees to miners, this would in turn continue the status quo in which miners continue to largely rely on seigniorage to operate. This is an unhealthy trend as it stalls the transition from block rewards to fees which was the narrative stated since day one on October 31, 2008 (see section 6).

What will happen?

It is difficult to predict what exactly will happen as the key actors in this space are still deciding what to use social capital on.

Gavin Andresen, as recently as two weeks ago, stated that most of the large payment processors, exchanges and other service companies are on-board with his plan (see also David Davout’s recent dialogue with Andresen). Furthermore, others in the community have (likely erroneously) found correlation between market cap and transaction volume yet as we know, correlation does not actually imply causation. Similarly, ‘Death and Taxes’ recently presented a narrative reinforcing Andresen’s view yet for some reason glossed over the all-important miners perspective.  Others, such as in the ideological wing personified by Mircea Popescu claim that they will fight this effort with an actual attack.

Irrespective as to what size a block is increased to, it will likely create at least a temporary fork as validating nodes need to upgrade and they are not being compensated for storage and traffic (Andresen’s plan is to “future proof” the protocol such that the 20 MB change is included in a patch this year but isn’t “turned on” until needed later on). There is at least one open question: what is the minimal amount of full nodes that are required for network to operate within current trust/security model?  Unlike miners, their value to the system is hard to measure.

What the experts say

While the field is young, one expert in this space is Jonathan Levin who modeled network propagation in his masters thesis. I reached out to him and in his view:

I think that the 20mb proposal is untenable given the current way that blocks are propagated around the Bitcoin network. The Bitcoin network and specifically the Bitcoin miners use a gossip network to relay blocks to each other. That means that as the size of the block increases, the time that it takes to spread around the network also increases linearly. We have seen this first in the work of Decker and Wattenhofer as well as my own work.

The problem is that the increased time that blocks take to propagate around the network increase the probability of orphan races between different mining pools. If you create blocks that are 20mb and a competing pool is creating blocks under 1mb or even empty ones, they have a higher expected return per hash. This is because you would expect your blocks to lose out to smaller blocks in an orphan race if both are found in quick succession. Now we can argue that miners will continue to create large blocks out of altruism but if we continue to increase the size of the blocks without greater utilisation of better block relaying protocols we risk breaking this equilibrium and miners resorting to nasty strategies like creating empty blocks which suit no one.

I also spoke with several other professionals in this space.

For instance, I spoke with Atif Nazir, co-founder of Block.io and an instructor at Blockchain University. According to him:

On the one hand, increasing block sizes, as you say, may result in lower transaction fee requirements. However, if the transaction fees actually are lowered by, say, 1000x what they are now (0.00001 is the minimum accepted by the reference client), this will lower the cost of “institutional attacks” on the Bitcoin infrastructure, where an attacker can push 1000 transactions for an erstwhile cost of 1. The attack will basically be “make infrastructure expensive to run for the average joe, drive them towards centralized infrastructure services that run APIs, Blockchain Explorers, etc.” It is good for business, bad for the decentralization of the network in the near term.

We’ve seen something like this occur on the Dogecoin Network in the past few months, where one user or a group of individuals were pushing transactions with 0 transaction fees. These transactions were accepted as valid by the Dogecoin reference clients, and as a result, caused bandwidth consumption hikes for the dorm-room nodes, which populate most of the current network(s). The resulting change by the Dogecoin Core team was to add a fee of 1.0 DOGE for every transaction, which isn’t yet mandatory, but is on its way there. The dorm-room nodes, however, are already on the decline in both Bitcoin and Dogecoin due to the increasing size of the Blockchain, and the bandwidth consumed by them.

Increasing the Block sizes sounds like a good idea for the number of transactions flowing on the network, but in the near term it will drive a lot of the nodes out of the system because of CPU/bandwidth/disk IO hikes. Increasing the Block sizes will definitely increase infrastructure costs, driving more users towards centralized places that can afford to host API services for the Blockchain. However, given this crunch on the average joe Bitcoin nodes, this will lead to a more concentrated effort towards “pick what you need” style nodes (say, SPV). Again, in the near term, the number of “full nodes” on the network will dwindle, but as more companies come into the ecosystem, this number will inevitably rise.

Bitcoin as a whole is headed towards a network where most nodes don’t actually host the entire Blockchain — increasing the block size will only accelerate this change. This will lead to more innovative solutions, and who knows, we might find a way for nodes to communicate cost-effectively rather than the current “gossip”-style protocol we use, where you inform all your peers when you hear about a new transaction. The community can very dynamic, and I think the longer term outlook for the network looks good regardless. Bitcoin is powered by nerds like you and I, and we tend to find solutions where others walk away.

Nazir raises an interesting point in terms of a hypothetical time horizon for when a transition (between short term and long term) could take place.

Another individual who has done a lot of modeling of incentives, mining and block sizes is Dave Hudson, a software developer who also writes at HashingIt. According to him:

Changes to the distributed consensus software within Bitcoin raise really interesting questions about the evolution of cryptocurrencies and how truly decentralised they really are. With each change we’re actually seeing something interesting happen where the ongoing participants in the system all effectively agree to move to a new system: BTC becomes BTC’ becomes BTC”, etc. We might be calling BTC” Bitcoin but any legacy nodes running BTC’ or BTC also think they’re Bitcoin too. At some point in time something happens and the various systems start to disagree about what is or isn’t valid and those could be very subtle. Imagine for example that BTC” introduced a subtle change that inadvertently made some of Satoshi’s coins unspendable; nobody might ever know until someone with Satoshi’s keys tries to spend their Bitcoins. Arguably it might already have happened as the result of some random compiler bug (not a fault in the Bitcoin-core code, but a bug in the way that’s transformed into something that runs on the node CPUs).

Clearly the Bitcoin-core developers try very hard to ensure that this sort of thing doesn’t happen by accident, but in order to sustain all participants holdings within the system they really do have to try to ensure that every node moves from BTC to BTC’ to BTC”, etc. In order to do this they essentially have to persuade everyone to migrate to each new version within some specific time window.

Now let’s imagine for a moment that instead of miners all tending to mine through centralised infrastructure (mining pools), that we really did have true decentralisation and had hundreds of thousands, or millions, of nodes that all did their own transaction selection and mining. Perhaps they’re even embedded into things that their users didn’t even realise were contributing to mining. At this scale it would probably be almost impossible to get them all to move to adopt a planned fork. We would either see the protocol totally stagnate or else we would see potentially very significant forks occurring.

In practice the system holds together in a cohesive way because, in the absence of a precise protocol spec, the core devs try to ensure that everyone uses the same consensus-critical software, runs it on the same sorts of hardware that all do things the same way and with some reasonably consistent set of capabilities.

It’s seems a slight irony that one of the key factors in the successful maintaining and sustaining of the Bitcoin network is continual centralised actions, and that things aren’t actually massively decentralised.

This last point is intriguing in that a lot of the software in this space is still relatively homogeneous and that if a network were to scale to become as distributed (or decentralized) as is hoped while simultaneously incorporating many nodes and clients, then it is likely that a diverse set (or lackthereof) of developer tools could prevent or perhaps even incentivize attacks (e.g., if every actor in the ecosystem uses the same client then that could create a vulnerability to the network).

In an exchange with Peter Todd, a contributor and developer on Bitcoin core and other related protocols (such as ClearingHouse), he framed the issue:

At the recent O’Reilly Media conference basically I pointed out that because this is an externality / tragedy-of-the-commons problem we may have to see Bitcoin fail due to a blocksize increase first before the community actually groks the issue. Personally I’m inclined to not oppose a blocksize increase on this grounds – Bitcoin failing cleanly is probably good for my interests.

In terms of “getting people on board” – to a degree you inherently can’t do this, because a blocksize increase will inherently exclude people from the system. See for example the discussion between Greg Maxwell and Gavin Andresen several weeks ago on the #bitcoin-dev IRC channel.

I spoke with Robert Sams, co-founder of a fintech startup who has previously written analysis covering the marginal costs of Bitcoin-like systems. In his view:

Levin’s point about network propagation is key: mining a larger block has a lower expected return because of the increased probability of losing out to a smaller block in an orphan race.

Now all of what you argue is a totally sound economic conjecture based on the assumption of distributed mining economics. Miners include tx until the marginal cost of tx inclusion (opportunity cost of including a different tx when up against the block limit + block propagation effect) equals marginal revenue (the fee).

However, for me the crucial economic force here is what happens to fees under concentrated mining. The logic changes from the marginal costs equals the marginal revenue logic in the above distributed case to a more strategic, oligopolistic pricing dynamic. What I mean is this. In the distributed case, whether or not a given miner includes a given tx has no material effect on the expected confirmation time for the tx sender. But in the concentrated mining scenario it does. If some pool is 35% of the network, the decision by that pool to not include the tx will materially increase the confirmation time of that transaction. So miners can extract more of the value that a tx senders place on fast confirmation times by setting their own minimum fee threshold, knowing that this threshold will over time effect the fees that tx senders include. What that optimal threshold is depends upon how much senders are willing to pay for faster tx confirmation times. Who knows what that is, but the implication is clear: under concentrated mining, fees levels will start to reflect more what tx senders are willing to pay rather than the cost to miners of including them.

So when you cast the blocksize issue in this concentrated mining context, it’s really not clear what will happen. My bets are that fees will go up and we won’t have to worry about blocksizes because higher fees will act as a break on adoption.

If block sizes are increased we will learn a lot about the dynamics of the community, the interplay between incentives such as fees and seigniorage have for on-boarding (and off-boarding) miners as well as how price sensitive users are in this space.

Ultimately it is the miners who decide as they are the entities creating Sybil protection and preventing double-spend attacks (or in some cases, providing that service). Or as Raffael Danielli, a quantitative research analyst at ING explained:

In theory, fee rewards should incentivize miners to include as many transactions as possible. In reality though fee rewards are a tiny percentage of block rewards and the risk-rewards ratio simply doesn’t add up at the moment (risking a (almost) sure 25 BTC payoff to get a potential say 25.1 BTC). What are the rational incentives for miners to upgrade and actually fill 20mb blocks? At the moment there are none that I am aware of. If there are no incentives for miners then this is not going to happen. Period. There is no altruism when it comes mining and anyone who bets on it is in for a rude awakening.

But this crosses over into the new field of cryptoeconomics which is a topic for another day.

[Thanks to Anton Bolotinksy for his thoughts on measuring the value of nodes within the system.]

Update from Organ of Corti:

I would add that there is a downward pressure on block size for block makers. I’ve done some research with Nadi Sarrer that proves the larger the block, the longer propagation takes. Even if a pool uses the relay network, increased latency also increases the chance of a pool losing an orphan race.

So block makers have to decide how to maximise fees while at the same time minimising block size. Some, like Discus Fish (f2pool) have tested both minimum block size (only including coinbase tx) and maximum block size, and lately seem comfortable producing maximum sized block each time. (They also seem to have a ‘pay for tx inclusion’ scheme here, but I don’t know much about it)

I think eventually pools will aim to use a decision making algorithm to:

a) Pick a block size they think will make losing an orphan race less likely.
b) Include all available high fee density (fee/kb) transactions in the block
c) then include high fee transactions
d) any left over space can be given to low and zero fee txs

With more data, this sort of process could be optimised to calculate the expected value of a block including the probability of losing orphan races. This would only lead to larger blocks when the value of the included txs outweighed the losses due to orphan races in the long term.

Of course, if all block makers had the same sized blocks, this would not be an issue. But if a block maker can win an orphan race by the expedient of having a smaller block, then they will.

Some open questions for the community: How will fewer network nodes affect orphan races? If the blocks are solved many seconds apart, I would think that fewer network nodes will mean fewer orphan races since the time for a block to propagate to most of the network will reduce significantly. However, if the blocks are solved at the same time, an orphan race might be more likely since the paths taken by the blocks propagating will have less affect on the overall propagation time. Which do you think is more likely?

In summary: If block makers are rational actors and the risk of losing orphan races is a significant downward pressure on block size, I don’t think increasing the available block space will have a significant effect on actual block size. There’s a lot of room for improvement in the tx inclusion algorithms used by most pools, and if I was a block maker I would increase the fee density of blocks and include far fewer low-fee and fee-free txs.

Send to Kindle

About two weeks ago I was interviewed over at Epicenter Bitcoin.

We covered a number of topics, some of which were previously covered by a few recent guests of the show (such as Robert Sams, Vitalik Buterin and Preston Byrne).

This episode also spawned a number of comments over at Reddit this past week, where I responded to a couple of people.

One clarification I would like to make regarding a specific comment I made on the show.  At around the 53 minute mark I discuss something called “trusted transparency.”  Guy Corem, CEO of Spondoolies Tech (an Israeli-based mining company) reached out to me this morning and explained that there is a misunderstanding and the area he is working on is more akin to an odometer.  I’ll probably write something up later next month as more information becomes public.

Also, the usual caveats: these alone are my opinions and I could be incorrect.

Send to Kindle

I have a new O’Reilly Media presentation up online called: “Moving Beyond Bitcoin (BINO) Beta:Transitioning mindshare from Bitcoin-for-everything monopoly to a competitive consensus-as-a-service marketplace.”

It is largely based on an earlier presentation (older slides) I gave in Singapore in November plus a few more updated slides from my R3 talk last month (slides).

Note: in order to listen and view you need to register (for free).

Send to Kindle

Yesterday there was a discussion on a listserve about Brian Kelly’s hypothesis’ regarding bitcoin exchange rates and below is an answer I used to discuss where payment processors fit into the ecosystem.

At their core BitPay is basically a forex company, a broker that matches merchants with liquidity providers.  Microsoft and some 44,000 merchants can convert bitcoins into fiat through them (and/or hold portions or all of the coins they receive too).  Some miners also use them to process BTC to USD.

To do this, they have built an exchange (you can also call a few of their team members to place block orders with), which effectively sorts the bid/asks among other exchanges and OTC providers (such as Buttercoin, Mirror, Xapo, Sator Square Partners, Bitfinex, Coinbase, etc.).  I tried describing some of how this plumbing system works in a article a couple months ago.

While I do not have the full details of other payment processors (like Coinsimple or Bitnet), they likely try to build similar relationships with liquidity providers.  And this is important because all payment processors — or really, forex brokers — are faced with the following three situations during an arbitrary 15 minute window:

1) order from merchant is canceled by payment processor
2) order from merchant is accepted and then sold to inventory partner (such as Buttercoin)
3) order from merchant is accepted but the coin is put on payment processor’s books

Payment processors ultimately want commerce to flow so they do their best to match up partners; so in practice there has to be partner on the other end with the same or greater demand for the coins being sold by the consumer/merchant.

I do not have exact numbers for how often #1 happens though I do understand it happens on a daily basis (again, the 15 minute window is to help lock in a price and the OTC demand from partners such as Coinbase may not be fast enough at times) or how often #3 happens (my understanding is US payment processors typically used to hold coins on their own books prior to the IRS ruling last year but have sold their inventory for tax purposes).  Obviously during a heavily volatile period like yesterday (or even today on the upside), there is a possibility that the coins could get placed on the payment processors’s books due to a lack of bids on the OTC partners side, but none of that is really public knowledge.

The point is however, that there has to be a demand side to absorb the sales of coins coming from merchants and payment processors have built some pretty good systems to handle that (incentivized in large part to limit their exposure to exchange rate volatility).  If these partners were to disappear or the coins they decide to purchase declines in aggregate, payment processors are then left with having to choose #1 or #3.  This doesn’t seem to be the case the last few days, the behavior seems to be on the exchanges themselves and not from merchants.

What does this mean in practice?

The current supply pressure on a daily basis: aside from a couple firms such as BitFury (which according to some sources has around a ~$180 total cost of production), miners as a whole end up having to sell the majority of coins each day (~2,000 – 3,000+ coins) and as a whole, merchants process about 5,000 – 6,000 coins a day.  So this means 10,000 coins x 365 days or 3,650,000 coins.  Thus, to maintain a $300 price with that sell pressure the market needs to have ~$1 billion a year in capital come into this space.  And to maintain a $1,200 price with the same merchant/miner behavior the market would need to have ~$4.4 billion.  Therefore it is likely that payment processors try to reduce the amount of exposure to #3, otherwise the coins would eat up the internal budget and increase the burn rate at these startups.

Note: what BitPay’s volume looks like in practice was recently summarized by analysis from Jorge Stolfi.

Send to Kindle

About a week ago I gave a guest presentation (webcast) with O’Reilly media regarding the “Continued Existence of Altcoins, Appcoins and Commodity coins.”  For those interested, a short preview is found at, “Bitcoin and blockchain use cases won’t be sexy, but will be essential.”

Note: in order to listen to the webcast archive you have register for the event.

Send to Kindle

Earlier today I gave the following presenation at the R3 Cryptocurrency Round Table in Palo Alto. It covers “Bitcoin 2.0” ideas including alternative consensus mechanisms, costs of operating decentralized ledgers, use-cases for these new ledgers within existing financial institutions and potential hurdles including disproportional rewards.

[Note: citations and references can be found in the notes of each slide]

Send to Kindle

Based on comments from both reddit and Coindesk, the number one question today seems to be related to off-chain transactions.  Why aren’t these being factored in to the equation? [Note: it bears mentioning that I did discuss this on p. 84, Chapter 4]

There are multiple problems with this perspective, however before delving into that I should point out that in the previous article, I did in fact link to Coinbase’s self-reported off-chain transaction numbers.  They are relatively marginal, on most days comprising less than 5% of the total transactional numbers.  But it is not clear from these numbers alone are or what they refer to: Coinbase user to user, user to merchant, and possible user wallet to user vault?

Below is their chart:

What impact does this have on the network?

It actually makes the network insecure in two ways:

1) Users become increasingly dependent on trusted third parties (TTP) on the edges, which defeats the purpose of having a blockchain in the first place (recall that “trusted” appears 11 times in the white paper).  This also opens both consumers and entrepreneurs up to a host of vulnerabilities and abuses that the industry is continually plagued by.

2) As more users leave the actual blockchain and move off onto TTP, less funds (or “fees”) are going to pay miners for actual security, making the entire network more reliant on seigniorage (block rewards) which in the long-run has empirically been a losing battle.

Below is a chart from Blockchain.info that illustrates fees to miners:

Another chart illustrating this data was compiled from data by Jonathan Levin (formerly of Coinometrics) over the same time period:

Notice how fees have actually decreased and are now at a two year low.  This is actually the opposite trend we would want to see and potentially troubling.  In fact, contrary to prudence, instead of floating fees the core developers have “slashed” fees (more accurately called “donations“) by tenfold this past year.  From an economic sustainability point-of-view, this is the diametrically opposite action that should be taking place.  It will make the adjustment period at the next block halving much more painful to consumers as fees have to go up to incentivize miners to stay.

Earlier this summer, L.M. Goodman (creator of the Tezos protocol) noted a similar conundrum:

The race to build more hashing power (by developing ASICs for instance) means that the cost to pull off a 51% attack on the network increases. In this respect, the network is more secure. Note however that the amount of money spent on mining and mining equipment must be approximately equal, in the long run, to the amount of bitcoin paid in transaction fees or created through mining. Given off chain transactions, this could dwindle to very low levels in the future.

As Dave Hudson and others have pointed out (see Chapter 3), this fee has to increase because transactional volume simply is not increasing to the level it needs to in order to replace the block reward.

Meher Roy succinctly summed up this conundrum in a comment earlier today:

The question is how will the low-fee high volume work when off-chain is / will prove to be more convenient?  Any on-chain fee will be out-competed by speed, lower fees and convenience of off-chain transactions. Why exactly are we sure on – chain transactions will rise 10000 fold that it needs to? How exactly does Bitcoin solve this collective action problem?

These are important questions that thus far, everyone seems to punt on.

What about off-chain data from exchanges?  Surely they should be factored into this?

Unless exchanges are willing to publicly share that data, it is difficult to surmise what is taking place in their black boxes (we can have some idea based on public addresses).

But again, this is not a particularly good metric for those who believe lots of commercial trade is taking place.  Off-chain transactions on an exchange are equivalent to forex.  Value transfer, possibly.  Retail commerce, no.

We do in fact know how much Bitpay and other payment processors do in business each day, we know this through the bitcoins they sell each day to liquidity providers.  And altogether this amounts to around 5,000 – 6,000 bitcoins per day.  Although there are some merchants that keep part or all of their bitcoins, the liquidity sales is the most accurate version of retail commerce we can estimate with today.  And that has not changed much over the past six months.

[Special thanks to Dave Babbitt and Jonathan Levin for their constructive feedback]

Send to Kindle

I was asked to provide some comments related to the SKBI conference last week in Singapore.  Below are my full quotes that were lightly edited for two different publications.

Singapore Event Puts Bitcoin on Mainstream Finance Agenda from Coindesk:

“One of the discussions throughout the conference was related to bitcoin as a commodity, currency and potentially emerging asset class.  While this is ultimately an empirical issue, the market so far — based on blockchain behavior — suggests that it could be some form of commodity.  As to whether or not it can go the distance and become an entrenched asset class is another issue altogether largely due to the tendency for all proof-of-work based blockchains to ultimately “self–destruct” due to block rewards.   Perhaps this will change and bitcoin will somehow be the exception to Ray Dillinger’s rules but it may be the case that its monetary policy cannot incentivize the labor force to stick around long enough to make bitcoin a viable asset class.”

Singapore Crypto Conference Brings Together Academia, Businesses and Regulators from CoinTelegraph:

“The Singapore conference was unique in that it provided a well-balanced cross-section of academics, business professionals, decision makers at governmental organizations and entrepreneurs within the industry.  As a result, the sobering conversations that took place focused more around actual opportunities and challenges in the community today rather than the typical scifi cheerleading that is divorced from the reality that companies in this space face.”

Videos and other media should be up in the next week or so.

Bonus: some of my thoughts as to why transactional volume has increased despite a lack of corresponding increase in BDD and miner fee volume: Markets Weekly: Bitcoin Rises Amid Dark Markets Crackdown from Coindesk.

Send to Kindle

Last week I participated in a couple panels at the inaugural CAIA-SKBI Cryptocurrency Conference 2014 hosted at Singapore Management University.

Below are the slides of the presentation I did at a closed-door session on November 5th.  Citations and references can be found in the notes of each slide.

Abstract:

With nearly six years of empirical data and use-cases behind the Nakamoto consensus method the community has observed that a cryptocurrency economy behaves differently than originally envisioned and intended.  What has arisen from these half-a-decade of physical interactions is a nearly complete rollback of the primary attributes embodied within the first of these Nakamoto consensus protocols, Bitcoin – to the point where it may best to refer to it as Bitcoin-in-name-only (BINO).  Consequently there are two other challenges within this existing BINO framework: (1) the diametrically opposed forces of speculative demand versus transactional demand; (2) decoupling coins from the ledger altogether.  This presentation discusses several proposed solutions to the challenges currently being devised by a multitude of teams.

Send to Kindle

I just finished reading through the new sidechains paper (pdf).  The team has clearly been thinking of clever solutions to a multitude of challenges.

Below are my first thoughts which could change as more information is released and/or code is implemented.

The biggest issue they did not address (so far) is how to incentivize mining after block reward halvings, though that probably was not their intent.  Also, and again this is just day one, but it is also unclear if the IP will be released as open source and if someone could use that code to create Blockstream 2, 3, etc.?

My comments below each block quote:

Because the miners do not form an identifiable set, they cannot have discretion over the rules determining transaction validity. Therefore, Bitcoin’s rules must be determined at the start of its history, and new valid transaction forms cannot be added except with the agreement of every network participant.

Even with such an agreement, changes are difficult to deploy because they
require all participants to implement and execute the new rules in exactly the same way, including edge cases and unexpected interactions with other features.

How can this be done in a trustless manner? Mining was supposed to be anonymous.  If they are identifiable by good actors, then they’re also identifiable by bad actors and not-so-good actors.

One problem is infrastructure fragmentation: because each altchain uses its own technology stack, effort is frequently duplicated and lost. Because of this, and because implementers of altchains may fail to clear the very high barrier of security-specific domain knowledge in Bitcoin[Poe14c], security problems are often duplicated across altchains while their fixes are not. Substantial resources must be spent finding or building the expertise to review novel distributed cryptosystems, but when they are not, security weaknesses are often invisible until they are exploited. As a result, we have seen a volatile, unnavigable environment develop, where the most visible projects may be the least technically sound. As an analogy, imagine an Internet where every website used its own TCP implementation, advertising its customised checksum and packet splicing algorithms to end users. This would not be a viable environment, and neither is the current environment of altchains.

Non sequitur.  The same complaint could be leveled at German carmakers versus American carmakers with the fragmentation in something like unit of measurement (meters vs Imperial).  The auto industry did not collapse because of fragmentation.

In addition, there is fragmentation within Bitcoin itself, with different pools relaying different types of transactions (or censoring others).  A couple days ago Dominic Williams pointed this out (in a different email), that there are different payment processors and different wallets that are incompatible (you can send money between them, but you can’t open one wallet with another).

A second problem is that such altchains, like Bitcoin, typically have their own native cryptocurrency, or altcoin, with a floating price. To access the altchain, users must use a market to obtain this currency, exposing them to the high risk and volatility associated with new currencies. Further, the requirement to independently solve the problems of initial distribution and valuation, while at the same time contending with adverse network effects and a crowded market, discourages technical innovation while at the same time encouraging market games. This is dangerous not only
to those directly participating in these systems, but also to the cryptocurrency industry as a whole. If the field is seen as too risky by the public, adoption may be hampered, or cryptocurrencies might be deserted entirely (voluntarily or legislatively).

Why are floating prices considered a bad thing?  Besides, the issues in this paragraph are exactly the same problem bitcoin faces each day and a solution to risks/volatility is not addressed in this white paper.  See Ferdinando Ametrano’s paper as well as Robert Sams’ upcoming draft on Seigniorage Shares.

Our proposed solution is to transfer assets by providing proofs of possession in the transferring transactions themselves, avoiding the need for nodes to track the sending chain. On a high level, when moving assets from one blockchain to another, we create a transaction on the first blockchain locking the assets, then create a transaction on the second blockchain whose inputs contain a cryptographic proof that the lock was done correctly. These inputs are tagged with an asset type, e.g. the genesis hash of its originating blockchain.

This has me thinking about token history and fungibility.  Perhaps it could be argued that moving these coins to a sidechain is an act of “mixing.”  Are atomic swaps a form of mixing?

Also, if the proof-of-burn effectively means “deposits” (from one chain to another) and value transfer is taking place, is this impacted by regulations such as 12 U.S. Code § 1831t – Depository institutions lacking Federal deposit insurance

This is true for almost all aspects of Bitcoin: a user running a full node will never accept a transaction that is directly or indirectly the result of counterfeiting or spending without proving possession. However, trustless operation is not possible for preventing double spending, as there is no way to distinguish between two conflicting but otherwise valid transactions. Instead of relying on a centralised trusted party or parties to take on this arbitration function like Bitcoin’s predecessors, Bitcoin reduces the trust required — but does not remove it — by using a DMMS and economic incentives.

It is still unclear what the additional economic incentives will be in the Blockstream/sidechains model.  Is it just the fees in section 6.1, such as the clever time-shifting mentioned later on?

This gives a boost in security, since now even a 51% attacker cannot falsely move coins from the parent chain to the sidechain. However, it comes at the expense of forcing sidechain validators to track the parent chain, and also implies that reorganisations on the parent chain may cause reorganisations on the sidechain. We do not explore this possibility in detail here, as issues surrounding reorganisations result in a significant expansion in complexity.

What are the costs of running and maintaining this validator?

No reaction. The result is that the sidechain is a “fractional reserve” of the assets it is storing from other chains. This may be acceptable for tiny amounts which are believed to be less than the number of lost sidechain coins, or if an insurer promises to make good on missing assets. However, beyond some threshold, a “bank run” of withdrawals from the sidechain is likely, which would leave somebody holding the bag in the end. Indirect damage could include widespread loss of faith in sidechains, and the expense to the parent chain to process a sudden rush of transactions.

Who determines insurance of a blockchain?  Will FDIC or similar bodies have jurisdictional grounds as described in the above USC citation (not a joke, Blockstream founders are not anonymous nor most large farm & pool operators)?

As miners provide work for more blockchains, more resources are needed to track and validate them all. Miners that provide work for a subset of blockchains are compensated less than those which provide work for every possible blockchain. Smaller-scale miners may be unable to afford the full costs to mine every blockchain, and could thus be put at a disadvantage compared to larger, established miners who are able to claim greater compensation from a larger set of blockchains.

We note however that it is possible for miners to delegate validation and transaction selection of any subset of the blockchains that they provide work for. Choosing to delegate authority enables miners to avoid almost all of the additional resource requirements, or provide work for blockchains that they are still in the process of validating. However such delegation comes at the cost of centralising validation and transaction selection for the blockchain, even if the work generation itself remains distributed. Miners might also choose instead to not provide work for blockchains that they are still in the process of validating, thus voluntarily giving up some compensation in 360 exchange for increased validation decentralisation.

How can that be done trustlessly?  How does that deal with the issues Dave Hudson talked about with respect to IHPP in general?  Until IHPP is changed or modified, Hudson’s models will remain valid.

By using a sidechain which carries bitcoins rather than a completely new currency, one can avoid the thorny problems of initial distribution and market vulnerability, as well as barriers to adoption for new users, who no longer need to locate a trustworthy marketplace or invest in mining hardware to obtain altcoin assets.

This doesn’t seem to be addressing several other reasons for why alts exist: who will pay independent developers wanting to build on sidechains? What about non-SHA-based hardware (like scrypt or X11)?  What is to prevent someone from forking “sidechains” code and creating a similar business?

An alternate mechanism for achieving block rewards on the sidechain is demurrage, an idea pioneered for digital currency by Freicoin (http://freico.in). In a demurring cryptocurrency, all unspent outputs lose value over time, with the lost value being recollected by miners. This keeps the currency supply stable while still rewarding miners. It may be better aligned with user interests than inflation because loss to demurrage is enacted uniformly everywhere and instantaneously, unlike inflation; it also mitigates the possibility of long-unspent “lost” coins being reanimated at their current valuation and shocking the economy, which is a perceived risk in Bitcoin. Demurrage creates incentives to increase monetary velocity and lower interest rates, which are considered (e.g. by Freicoin advocates and other supporters of Silvio Gesell’s theory of interest[Ges16]) to be socially beneficial. In pegged sidechains, demurrage allows miners to be paid in existing already valued currency.

I am not sure Freicoin is a particularly good example here because in practice few participants want an asset to always lose value (what investors actively demand demurrage?).  Maybe this is reflected in its lack of adoption (thus far).  Perhaps that will change, perhaps Freicoin will grow over the course of the next few years. But this also touches on the issue of whether or not these “coins” are commodities or a currency in the first place (I have argued they are informational commodities).

The point about reanimation is an interesting one (and good) because of the uncertainties of “zombie” coins (as John Ratcliff calls them) that jump back onto the market.

Also, while the experimentation use-cases in section 5.1.1 seem to have some active demand (as measured by crowdsales and hype this past year) they could also (IANAL) lead to legal issues that these 2.0 projects are having with respect to unregistered securities (see the SEC with its Howey test).  This is a legally risky area as discussed by these lawyers.  Also, if users can create digital tokens pegged to real world assets — if these are non-deliverable, does this turn that chain into a large “bucket shop“?

Co-signed SPV proofs. Introducing signers who must sign off on valid SPV proofs, watching for false proofs. This results in a direct tradeoff between centralisation and security against a high-hashpower attack. There is a wide spectrum of trade-offs available in this area: signers may be required only for high-value transfers; they may be required only when sidechain hashpower is too small a percentage of Bitcoin’s; etc. Further discussion about the usefulness of this kind of trade-off is covered in Appendix A.

Who will maintain these?  No Free Lunch.

Send to Kindle

Turns out about 15 months ago, someone had already figured out how the mining costs of hash-based proof of work moved relative to the market prices of tokens, see “Why Bitcoin will never be a good store of value” by Stefan Loesch.  One common retort to Loesch’s argument is that at some point in the future, for some reason, users will one day start paying higher tx fees.  This is unlikely because it is a collective action problem.  Why would people pay several orders of magnitude more to have the same exact service?

A new feature/dashboard that I came across is CoinGecko — has some interesting metrics to look at.

Other links related to digital currencies and China (linking is not an endorsement of service, coin, chain, etc.):

• Asynchronous Consensus and Broadcast Protocols by Gabriel Bracha and Sam Toueg
• Chomping at the Bitcoin: An Expert’s Take on Bitcoin in China from CoinDesk (I interviewed Zennon for both GCON and The Anatomy)
• Black Friday Architect Preet Bharara Possible New US AG from Cards Chat (there are some similar parallels with the evolution in Online Poker + law enforcement with the digital currency startup segment)
• China’s WeChat introduces in-store payments for Dairy Queen and 8 other chains from Tech in Asia
• Why Convertible Notes Are Sometimes Terrible For Startups from Techcrunch
• China’s outward investment surges as growth pattern shows significant shift from South China Morning Post
• ApplePay: Debit issues from Industry Perspective and G2
• Junkets That Fuel Macau Casinos Are on a Losing Streak from The Wall Street Journal
• Resource-based relative value scale
• Feds: Butterfly Labs mined bitcoins on customers’ boxes before shipping from ArsTechnica
• Bitcoin Is Growing Up: Now You Can Hedge Your Investments from Bloomberg
• Global imbalances remain a threat to stability, IMF warns from Financial Times (“The status of the US dollar as a reserve currency seems, if anything, more secure now than in 2006”)
• Water consumption: A canal too far from The Economist
• Oh, Big Brother: you won’t believe how many sites are now blocked in China from Tech in Asia (was super annoying when I lived there, also, recall that nearly all of the Google apps are removed from Android devices and replaced by other similar apps by local phone makers)
• Mining Bitcoin with pencil and paper: 0.67 hashes per day by Ken Shirriff
• Anonymity of Cryptocurrencies Part II – Cryptonote & Darkcoin from CoinBrief
• The Internet’s Missing Link by Stefan Thomas
• Messaging with Gems from CoinFire (interview with a Gems developer)
• [BIP draft] CHECKLOCKTIMEVERIFY – Prevent a txout from being spent until an expiration time by Peter Todd
• 12 USC 378 – Dealers in securities engaging in banking business; individuals or associations engaging in banking business; examinations and reports; penalties from onecle
• Banking Interpretations from NY DFS (regarding PayPal in 2002)
• Bitcoin SF Devs Seminar: Bryan Vu’s deep dive into Coinshuffle & Decentralized coinjoin (see CoinShuffle and CoinJoin)
• FinCEN Director: We’re Not Out to Villainize Bitcoin from CoinDesk
• Assembly Coins (native asset issuance on the blockchain)
• Behold Arscoin, our own custom cryptocurrency! from ArsTechnica
• eBay and PayPal are splitting up from The Verge
• What the Hell is Going on with Monero?! from Bull Bear Analysis
• Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults by Clement et. al.
• Threshold signatures and Bitcoin wallet security: A menu of options from Freedom to Tinker

Send to Kindle