Blockstream’s sidechain’s is announced

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 ( 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.

2 thoughts on “Blockstream’s sidechain’s is announced

  1. > 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.?

    Sidechains is an idea, not a specific implementation. But for what it’s worth, we will be releasing an open source implementation as well as the tools necessary to do one yourself.

    A rough first version of a tool for implementing the pay-to-contract protocol specified in Appendix A is available on Github already:

  2. Pingback: Windhovercraft « Trade With Dave

Leave a Reply

Your email address will not be published. Required fields are marked *