Andrew Miller - Enabling Blockchain Innovations with Pegged Sidechains lyrics

Published

0 67 0

Andrew Miller - Enabling Blockchain Innovations with Pegged Sidechains lyrics

Introduction David Chaum introduced digital cash as a research topic in 1983, in a setting with a central server that is trusted to prevent double-spending[Cha83]. To mitigate the privacy risk to individuals from this central trusted party, and to enforce fungibility, Chaum introduced the blind signature, which he used to provide a cryptographic means to prevent linking of the central server's signatures (which represent coins), while still allowing the central server to perform double-spend prevention. The requirement for a central server became the Achilles' heel of digital cash[Gri99]. While it is possible to distribute this single point of failure by replacing the central server's signature with a threshold signature of several signers, it is important for auditability that the signers be distinct and identifiable. This still leaves the system vulnerable to failure, since each signer can fail, or be made to fail, one by one. In January of 2009, Satoshi Nakamoto released the first widely used implementation of peer- to-peer trustless electronic cash[Nak09], replacing the central server's signature with a consensus mechanism based on proof of work[Bac02], with economic incentives to act cooperatively. Bitcoin tracks payments by aggregating them into blocks, each with an a**ociated blockheader, which cryptographically commits1 to: the contents of the block, a timestamp, and the previous blockheader. The commitments to previous headers form a blockchain, or chain, which provides a well-defined ordering for transactions. We observe that Bitcoin's blockheaders can be regarded as an example of a dynamic membership multi-party signature (or DMMS), which we consider to be of independent interest as a new type of group signature. Bitcoin provides the first embodiment of such a signature, although this has not appeared in the literature until now. A DMMS is a digital signature formed by a set of signers which has no fixed size. Bitcoin's blockheaders are DMMSes because their proof-of-work has the property that anyone can contribute with no enrolment process. Further, contribution is weighted by computational power rather than one threshold signature contribution per party, which allows anonymous membership without risk of a Sybil attack (when one party joins many times and has disproportionate input into the signature). For this reason, the DMMS has also been described as a solution to the Byzantine Generals Problem[AJK05]. Because the blocks are chained together, Bitcoin's DMMS is cumulative: any chain (or chain fragment) of blockheaders is also a DMMS on its first block, with computational strength equal to the sum of the strengths of the DMMSes it is composed of. Nakamoto's key innovation is the aforementioned use of a DMMS as a signature of computational power rather than a signature of knowledge. Because signers prove computational work, rather than proving secret knowledge as is typical for digital signatures, we refer to them as miners. To achieve stable consensus on the blockchain history, economic incentives are provided where miners are rewarded with fees and subsidies in the form of coins that are valuable only if the miners form a shared valid history, incentivising them to behave honestly. Because the strength of Bitcoin's cumulative DMMS is directly proportional to the total computational power contributed by all miners[Poe14a], it becomes infeasible for a computational minority to change the chain. If they try to revise the DMMS-secured 40 ledger, they will fall behind and be continually unable to catch up to the moving target of the progressing consensus blockchain. 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. For this reason, Bitcoin's objective is relatively simple: it is a blockchain supporting the transfer of a single native digital a**et, which is not redeemable for anything else. This allowed 50 many simplifications in the implementation, but real-world demands are now challenging those simplifications. In particular, current innovation is focused around the following areas: There are trade-offs between scalability and decentralisation. For example, a larger block size would allow the network to support a higher transaction rate, at the cost of placing more work on validators — a centralisation risk. Similarly, there are trade-offs between security and cost. Bitcoin stores every transaction in its history with the same level of irreversibility. This is expensive to maintain and may not be appropriate for low value or low-risk transactions (e.g. where all parties already have shared legal infrastructure in place to handle fraud). These trade-offs should be made for each transaction, as transactions vary widely in value and risk profile. However, Bitcoin by construction supports only a “one size fits all” solution. There are many more trade-offs for blockchain features. For example, Bitcoin's script could be more powerful to enable succinct and useful contracts, or could be made less powerful to a**ist in auditability. There are a**ets besides currencies that may be traded on blockchains, such as IOUs and other contracts, as well as smart property [Sza97]. There is a risk of monoculture: Bitcoin is composed of many cryptographic components, any one of whose failures could cause a total loss of value. If possible, it would be prudent not to secure every bitcoin with the same set of algorithms. New technology might enable new features not imagined when Bitcoin was first developed. For example, privacy and censorship-resistance could be improved by use of cryptographic accumulators[Mou13], ring signatures[vS13], or Chaumian blinding[Cha83]. Even if there is a pressing need to do so, there is no safe upgrade path for Bitcoin, in the sense that all participants must act in concert for any change to be effected. There is consensus amongst Bitcoin developers that changes to Bitcoin must be done slowly, cautiously, and only with clear a**ent from the community. The fact that functionality must be broadly acceptable to gain adoption limits participants' personal freedom and autonomy over their own coins. Small groups are unable to implement features, such as special-purpose script extensions[jl213], because they lack broad consensus. An early solution to these problems with Bitcoin has been the development of alternate 80 blockchains, or altchains, which share the Bitcoin codebase except for modifications to address the above concerns. However, implementing technical changes through the creation of independent but essentially similar systems is problematic. 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 an*logy, 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. 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 a**ociated 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 100 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). It appears that we desire a world in which interoperable altchains can be easily created and used, but without unnecessarily fragmenting markets and development. In this paper, we argue that it is possible to simultaneously achieve these seemingly contradictory goals. The core observation is that “Bitcoin” the blockchain is conceptually independent from “bitcoin” the a**et: if we had technology to support the movement of a**ets between blockchains, new systems could be developed which users could adopt by simply reusing the existing bitcoin currency.2 We refer to such interoperable blockchains as pegged sidechains. We will give a precise 110 definition in Section 3, but for now we list the following desired properties for pegged sidechains: Assets which are moved between sidechains should be able to be moved back by whomever their current holder is, and nobody else (including previous holders). Assets should be moved without counterparty risk; that is, there should be no ability for a dishonest party to prevent the transfer occurring. Transfers should be atomic, i.e. happen entirely or not at all. There should not be failure modes that result in loss or allow fraudulent creation of a**ets. Sidechains should be firewalled: a bug in one sidechain enabling creation (or theft) of a**ets in that chain should not result in creation or theft of a**ets on any other chain. Blockchain reorganisations3 should be handled cleanly, even during transfers; any disruption should be localised to the sidechain on which it occurs. In general, sidechains should ideally be fully independent, with users providing any necessary data from other chains. Validators of a sidechain should only be required to track another chain if that is an explicit consensus rule of the sidechain itself. Users should not be required to track sidechains that they are not actively using. An early solution was to “transfer” coins by destroying bitcoins in a publicly recognisable way4, which would be detected by a new blockchain to allow creation of new coins[Bac13b]. This is a partial solution to the problems listed above, but since it allows only unidirectional transfers between chains, it is not sufficient for our purposes. Our proposed solution is to transfer a**ets by providing proofs of possession in the transferring 130 transactions themselves, avoiding the need for nodes to track the sending chain. On a high level, when moving a**ets from one blockchain to another, we create a transaction on the first blockchain locking the a**ets, 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 a**et type, e.g. the genesis hash of its originating blockchain. We refer to the first blockchain as the parent chain, and the second simply as the sidechain. In some models, both chains are treated symmetrically, so this terminology should be considered relative. Conceptually, we would like to transfer an a**et from the (original) parent chain to a sidechain, possibly onward to another sidechain, and eventually back to the parent chain, preserving the original a**et. Generally we can think of the parent chain as being Bitcoin and the sidechain as one of many other blockchains. Of course, sidechain coins could be transferred between sidechains, not just to and from Bitcoin; however, since any coin originally moved from Bitcoin could be moved back, it would nonetheless remain a bitcoin. This lets us solve the problem of fragmentation described in the previous section, which is good news for cryptocurrency developers who want to focus solely on technical innovation. Furthermore, because sidechains transfer existing a**ets from the parent chain rather than creating new ones, sidechains cannot cause unauthorised creation of coins, relying instead on the parent chain to maintain the security and scarcity of its a**ets5. Further still, participants do not need to be as concerned that their holdings are locked in a single experimental altchain, since sidechain coins can be redeemed for an equal number of parent chain coins. This provides an exit strategy, reducing harm from unmaintained software. A reorganisation, or reorg, occurs locally in clients when a previously accepted chain is overtaken by a competitor chain with more proof of work, causing any blocks on the losing side of the fork to be removed from consensus history. On the other hand, because sidechains are still blockchains independent of Bitcoin, they are free to experiment with new transaction designs, trust models, economic models, a**et issuance semantics, or cryptographic features. We will explore many of the possibilities for sidechains further in Section 5. An additional benefit to this infrastructure is that making changes to Bitcoin itself becomes much less pressing: rather than orchestrating a fork which all parties need to agree on and implement in tandem, a new “changed Bitcoin” could be created as a sidechain. If, in the medium term, there were wide agreement that the new system was an improvement, it may end up seeing significantly more use than Bitcoin. As there are no changes to parent chain consensus rules, everyone can switch 160 in their own time without any of the risks a**ociated with consensus failure. Then, in the longer term, the success of the changes in the sidechain would provide the needed confidence to change the parent chain, if and when it is deemed necessary to do so. 2. Design rationale Trustlessness is the property of not relying on trusting external parties for correct operation, typically by enabling all parties to verify on their own that information is correct. For example, in cryptographic signature systems trustlessness is an implicit requirement (signature systems where an attacker can forge signatures would be considered utterly broken). While this is not typical for distributed systems, Bitcoin does provide trustless operation for most parts of its system6. A major design goal of pegged sidechains is to minimise additional trust over Bitcoin's model. 170 The hard part is securing transfers of coins between sidechains: the receiving chain must see that the coins on the sending chain were correctly locked. Following Bitcoin's lead, we propose solving this using DMMSes. Although it is possible to use a simple trust-based solution involving fixed signers (see Appendix A) to verify locking of coins, there are important reasons to avoid the introduction of single points of failure: Trusting individual signers does not only mean expecting them to behave honestly; they must also never be compromised, never leak secret key material, never be coerced, and never stop participating in the network. Because digital a**ets are long-lived, any trust requirements must be as well. Experience has shown that trust requirements are dangerous expectations even for timespans on the order of months, let alone the generational timespans we expect financial systems to last. Digital currencies were unable to gain traction until Bitcoin was able to eliminate single points of failure, and the community is strongly averse to the introduction of such weaknesses. Community mistrust is reinforced by financial events since 2007; public trust in the financial system and other public institutions is likewise at historical lows. 3. Two-way peg The technical underpinning of pegged sidechains is called the two-way peg. In this section we explain the workings thereof, beginning with some definitions. 3.1. Definitions A coin, or a**et, is a digital property whose controller can be cryptographically ascertained. A block is a collection of transactions describing changes in a**et control. A blockchain is a well-ordered collection of blocks, on which all users must (eventually) come to consensus. This determines the history of a**et control and provides a computationally unforgeable time ordering for transactions. A reorganisation, or reorg, occurs locally in clients when a previously accepted chain is overtaken by a competitor chain with more proof of work, causing any blocks on the losing side of the fork to be removed from consensus history. A sidechain is a blockchain that validates data from other blockchains. Two-way peg refers to the mechanism by which coins are transferred between sidechains and back at a fixed or otherwise deterministic exchange rate. A pegged sidechain is a sidechain whose a**ets can be imported from and returned to other chains; that is, a sidechain that supports two-way pegged a**ets. A simplified payment verification proof (or SPV proof7) is a DMMS that an action occurred on a Bitcoin-like proof-of-work blockchain. Essentially, an SPV proof is composed of (a) a list of blockheaders demonstrating proof-of- work, and (b) a cryptographic proof that an output was created in one of the blocks in the list. This allows verifiers to check that some amount of work has been committed to the existence of an output. Such a proof may be invalidated by another proof demonstrating the existence of a chain with more work which does not include the block which created the output. Using SPV proofs to determine history, implicitly trusting that the longest blockchain is also the longest correct blockchain, is done by so-called SPV clients in Bitcoin. Only a dishonest collusion with greater than 50% of the hashpower can persistently fool an SPV client (unless the client is under a long-term Sybil attack, preventing it from seeing the actual longest chain), since the honest hashpower will not contribute work to an invalid chain. Optionally, by requiring each blockheader to commit to the blockchain's unspent output set8, anyone in possession of an SPV proof can determine the state of the chain without needing to “replay” every block. (In Bitcoin, full verifiers need to do this when they first start tracking the blockchain.) As we will discuss in Appendix B, by including some additional data in Bitcoin's block structure, we can produce smaller proofs than a full list of headers, which will improve scalability. Still, these proofs will be much larger than ordinary Bitcoin transactions. Fortunately, they are not necessary for most transfers: holders of coins on each chain may exchange them directly using atomic swaps[Nol13], as described in Appendix C. 3.2. Symmetric two-way peg We can use these ideas to SPV peg one sidechain to another. This works as follows: to transfer parent chain coins into sidechain coins, the parent chain coins are sent to a special output on the parent chain that can only be unlocked by an SPV proof of possession on the sidechain. To synchronise the two chains, we need to define two waiting periods: The confirmation period of a transfer between sidechains is a duration for which a coin must be locked on the parent chain before it can be transferred to the sidechain. The purpose of this confirmation period is to allow for sufficient work to be created such that a denial of service attack in the next waiting period becomes more difficult. A typical confirmation period would be on the order of a day or two. After creating the special output on the parent chain, the user waits out the confirmation period, then creates a transaction on the sidechain referencing this output, providing an SPV proof that it was created and buried under sufficient work on the the parent chain. The confirmation period is a per-sidechain security parameter, which trades cross-chain transfer speed for security. The user must then wait for the contest period. This is a duration in which a newly-transferred coin may not be spent on the sidechain. The purpose of a contest period is to prevent double- spending by transferring previously-locked coins during a reorganisation. If at any point during this delay, a new proof is published containing a chain with more aggregate work which does not include the block in which the lock output was created, the conversion is retroactively invalidated. We call this a reorganisation proof. All users of the sidechain have an incentive to produce reorganisation proofs if possible, as the consequence of a bad proof being admitted is a dilution in the value of all coins. A typical contest period would also be on the order of a day or two. To avoid these delays, users will likely use atomic swaps (described in Appendix C) for most transfers, as long as a liquid market is available. While locked on the parent chain, the coin can be freely transferred within the sidechain without 250 further interaction with the parent chain. However, it retains its identity as a parent chain coin, and can only be transferred back to the same chain that it came from. When a user wants to transfer coins from the sidechain back to the parent chain, they do the same thing as the original transfer: send the coins on the sidechain to an SPV-locked output, produce a sufficient SPV proof that this was done, and use the proof to unlock a number of previously-locked outputs with equal denomination on the parent chain. The entire transfer process is demonstrated in Figure 1. Since pegged sidechains may carry a**ets from many chains, and cannot make a**umptions about the security of these chains, it is important that different a**ets are not interchangeable (except by an explicit trade). Otherwise a malicious user may execute a theft by creating a worthless chain with a worthless a**et, move such an a**et to a sidechain, and exchange it for something else. To combat this, sidechains must effectively treat a**ets from separate parent chains as separate a**et types. In summary, we propose to make the parent chain and sidechains do SPV validation of data on each other. Since the parent chain clients cannot be expected to observe every sidechain, users import proofs of work from the sidechain into the parent chain in order to prove possession. In a symmetric two-way peg, the converse is also true. To use Bitcoin as the parent chain, an extension to script which can recognise and validate such SPV proofs would be required. At the very least, such proofs would need to be made compact enough to fit in a Bitcoin transaction. However, this is just a soft-forking change9, without effect on transactions which do not use the new features. 3.3. Asymmetric two-way peg The previous section was titled “Symmetric Two-Way Peg” because the transfer mechanisms from parent chain to sidechain and back were the same: both had SPV security10. An alternate scheme is an asymmetric two-way peg: here users of the sidechain are full validators of the parent chain, and transfers from parent chain to sidechain do not require SPV proofs, since all validators are aware of the state of the parent chain. On the other hand, the parent chain is still unaware of the sidechain, so SPV proofs are required to transfer back. 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 280 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. 4. Drawbacks While sidechains provide solutions to many problems in the cryptocurrency space, and create countless opportunities for innovation to Bitcoin, they are not without their drawbacks. In this section we review a few potential problems, along with solutions or workarounds. 4.1. Complexity Sidechains introduce additional complexity on several levels. On the network level, we have multiple independent unsynchronised blockchains supporting transfers between each other. They must support transaction scripts which can be invalidated by a later reorganisation proof. We also need software which can automatically detect misbehaviour and produce and publish such proofs. On the level of a**ets, we no longer have a simple “one chain, one a**et” maxim; individual chains may support arbitrarily many a**ets, even ones that did not exist when the chain was first created. Each of these a**ets is labelled with the chain it was transferred from to ensure that their transfers can be unwound correctly. Enabling the blockchain infrastructure to handle advanced features isn't sufficient: user interfaces for managing wallets will need to be reconsidered. Currently in the altcoin world, each chain has its own wallet which supports transactions of that chain's coin. These will need to adapt 300 to support multiple chains (with potentially different feature sets) and transfers of a**ets between chains. Of course, there is always the option of not using some functionality when the interface would be too complex. 4.2. Fraudulent transfers Reorganisations of arbitrary depth are in principle possible, which could allow an attacker to completely transfer coins between sidechains before causing a reorganisation longer than the contest period on the sending chain to undo its half of the transfer. The result would be an imbalance between the number of coins on the recipient chain and the amount of locked output value backing them on the sending chain. If the attacker is allowed to return the transferred coins to the original chain, he would increase the number of coins in his possession at the expense of other users of the sidechain. Before discussing how to handle this, we observe that this risk can be made arbitrarily small by simply increasing the contest period for transfers. Better, the duration of the contest period could be made a function of the relative hashpower of the two chains: the recipient chain might only unlock coins given an SPV proof of one day's worth of its own proof-of-work, which might correspond to several days of the sending chain's proof-of-work. Security parameters like these are properties of the particular sidechain and can be optimised for each sidechain's application. Regardless of how unlikely this event is, it is important that the sidechain not respond with catastrophic failure. It is possible to create an SPV proof witnessing such an event, and sidechains may accept such proofs. They may be designed to react in one of many possible ways: No reaction. The result is that the sidechain is a “fractional reserve” of the a**ets 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 a**ets. 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. The peg and all dependent transactions could be reversed. However, as coins tend to diffuse and histories intermingle, the effect of such a reversal could be catastrophic after even short periods of time. It also limits fungibility, as recipients would prefer coins with “clean” histories (no recent pegs). We expect that such a loss of fungibility might have disastrous consequences. The amount of all coins could be reduced, while leaving the exchange rate intact. Now users who transferred coins to the sidechain prior to the attack are disadvantaged relative to new ones. Reducing the exchange rate for sidechain coins would be equivalent. Many variations on these reactions are possible: for example, temporarily decreasing the exchange rate so those who “make a run” on the sidechain cover the loss of those who don't. 4.3. Risk of centralisation of mining An important concern is whether the introduction of sidechains with mining fees places resource pressure on miners, creating Bitcoin centralisation risks. Because miners receive compensation from the block subsidy and fees of each chain they provide work for, it is in their economic interest to switch between providing DMMSes for different similarly-valued blockchains following changes in difficulty and movements in market value. One response is that some blockchains have tweaked their blockheader definition such that it includes a part of Bitcoin's DMMS, thus enabling miners to provide a single DMMS that commits to Bitcoin as well as one or more other blockchains — this is called merged mining. Since merged mining enables re-use of work for multiple blockchains, miners are able to claim compensation from each blockchain that they provide DMMSes for. 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 350 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 exchange for increased validation decentralisation. 4.4 Risk of soft-fork In Bitcoin, a soft-fork is an addition to the Bitcoin protocol made backwards compatible by being designed to strictly reduce the set of valid transactions or blocks. A soft-fork can be implemented with merely a supermajority of the mining computational power participating, rather than all full nodes. However, participants' security with respect to the soft-forked features is only SPV-level until they upgrade. Soft-forks have been used several times to deploy new features and fix security issues in Bitcoin (see [And12b]). A two-way peg, implemented as described in this paper, has only SPV security and therefore has greater short-term dependence on miner honesty than Bitcoin does (see the attack described in 370 Section 4.2). However, a two-way peg can be boosted to security absolutely equal to Bitcoin's if all full nodes on both systems inspect each other's chain and demand mutual validity as a soft-forking rule. A negative consequence of this would be loss of isolation of any soft-fork-required sidechain. Since isolation was one of the goals of using pegged sidechains, this result would be undesirable unless a sidechain was almost universally used. Absent pegged sidechains, however, the next alternative would be to deploy individual changes as hard- or soft-forks in Bitcoin directly. This is even more abrupt, and provides no real mechanism for the new facility to prove its maturity and demand before risking Bitcoin's consensus on it. 5. Applications With the technical underpinnings out of the way, in this section we explore user-facing applications of sidechains, which effectively extend Bitcoin to do things that it cannot today. 5.1. Altchain experiments The first application, already mentioned many times, is simply creating altchains with coins that derive their scarcity and supply from Bitcoin. 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 a**ets. 5.1.1 Technical experimentation Because sidechains are technically still fully-independent chains, they are able to change features 390 of Bitcoin such as block structure or transaction chaining. Some examples of such features are: By fixing undesired transaction malleability11 — which can only be fixed partially in Bitcoin [Wui14] — protocols which involve chains of unconfirmed transactions can be executed safely. Transaction malleability is a problem in Bitcoin which allows arbitrary users to tweak transaction data in a way that breaks any later transactions which depend on them, even though the actual content of the transaction is unchanged. An example of a protocol broken by transaction malleability is probabilistic payments[Cal12]. Improved payer privacy, e.g. the ring signature scheme used by Monero, can reduce the systemic risk of the transactions of particular parties being censored, protecting the fungibility of the cryptocurrency. Improvements to this have been suggested by Maxwell and Poelstra [MP14, Poe14b] and Back[Bac13a], which would allow for even greater privacy. Today, ring signatures can be used with Monero coins, but not bitcoins; sidechains would avoid this exclusivity. Script extensions (for example, to efficiently support coloured coins[jl213]) have been proposed for Bitcoin. Since such extensions are usable only by a small subset of users, but all users would need to deal with the increased complexity and risk of subtle interactions, these extensions have not been accepted into Bitcoin. Other suggested script extensions include support for new cryptographic primitives. For example, Lamport signatures[Lam79], while large, are secure against quantum computers. Many ideas for extending Bitcoin in incompatible ways are described at [Max14] and at http://www.bitcoin.ninja. Since changes like these affect only the transfer of coins, rather than their creation, there is no need for them to require a separate currency. With sidechains, users can safely and temporarily experiment with them. This encourages adoption for the sidechain, and is less risky for participants relative to using an entirely separate altcoin. 5.1.2. Economic experimentation Bitcoin's reward structure a**igns new coins to miners. This effectively inflates the currency but it winds down over time according to a step-wise schedule. Using this inflation to subsidise mining has been a successful complement to transaction fees to secure the network. 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. Other economic changes include required miner fees, transaction reversibility, outputs which are simply deleted once they reach a certain age, or inflation/demurrage rates pegged to events outside of the sidechain. All of these changes are difficult to do safely, but the ease of creation and reduced risk of sidechains provide the necessary environment for them to be viable. 5.2. Issued a**ets To this point, we have mostly been thinking about sidechains which do not need their own native currency: all coins on the sidechain are initially locked, until they are activated by a transfer from some other sidechain. However, it is possible for sidechains to produce their own tokens, or issued a**ets, which carry their own semantics. These can be transferred to other sidechains and traded for other a**ets and currencies, all without trusting a central party, even if a trusted party is needed for future redemption. Issued a**et chains have many applications, including traditional financial instruments such as shares, bonds, vouchers, and IOUs. This allows external protocols to delegate ownership and transfer tracking to the sidechain on which the ownership shares were issued. Issued a**et chains may also support more innovative instruments such as smart property. These technologies can also be used in complementary currencies[Lie01]. Examples of complementary currencies include community currencies, which are designed to preferentially boost local businesses; business barter a**ociations, which support social programs like education or elderly care; and limited-purpose tokens which are used within organisations such as ma**ive multiplayer games, loyalty programs, and online communities12. A suitably extended scripting system and an a**et-aware transaction format would allow the creation of useful transactions from well-audited components, such as the merger of a bid and an ask to form an exchange transaction, enabling the creation of completely trustless peer-to-peer marketplaces for a**et exchange and more complex contracts such as trustless options[FT13]. These contracts could, for example, help reduce the volatility of bitcoin itself. 6. Future directions 6.1. Hashpower attack resistance The main thrust of this paper surrounds two-way peg using SPV proofs, which are forgeable by a 51%-majority and blockable by however much hashpower is needed to build a sufficiently-long proof during the transfer's contest period. (There is a tradeoff on this latter point — if 33% hashpower can block a proof, then 67% is needed to successfully use a false one, and so on.) Some other ideas worth exploring in sidechains are: Assurance contracts. The sidechain's transaction fees are withheld from miners unless their hashpower is at least, say, 66% of that of Bitcoin. These sorts of contracts are easy for a cryptocurrency to implement, if they are designed in from the start, and serve to increase the cost of blocking transfers. Time-shifted fees. Miners receive part of their fees in a block far in the future (or spread across many blocks) so that they have incentive to keep the chain operational. This may incentivise miners to simply receive fees out-of-band, avoiding the need to wait for future in-chain rewards. A variation on this scheme is for miners to receive a token enabling them to mine a low-difficulty block far in the future; this has the same effect, but directly incentivises its recipient to mine the chain. Demurrage. Block subsidies can be given to miners through demurrage to incentivise honest mining. Since only as much can be transferred to Bitcoin or another sidechain as was transferred out, this fund reallocation would be localised to the sidechain in which it occurs. Subsidy. A sidechain could also issue its own separate native currency as reward, effectively forming an altcoin. However, these coins would have a free-floating value and as a result would not solve the volatility and market fragmentation issues with altcoins. Cosigned 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. SNARKs. An exciting recent development in academic cryptography has been the invention of SNARKs [BSCG+13]. SNARKs are space-efficient, quickly verifiable zero-knowledge cryptographic proofs that some computation was done. However, their use is currently inhibited because the proofs for most programs are too slow to generate on today's computers, and the existing constructions require a trusted setup, meaning that the creator of the system is able to create false proofs. A futuristic idea for a low-value or experimental sidechain is to invoke a trusted authority, whose only job is to execute a trusted setup for a SNARK scheme. Then blocks could be constructed which prove their changes to the unspent-output set, but do so in zero-knowledge in the actual transactions. They could even commit to the full verification of all previous blocks, allowing new users to get up to speed by verifying only the single latest block. These proofs could also replace the DMMSes used to move coins from another chain by proving that the sending chain is valid according to some rules previously defined. 7. Acknowledgements We would like to thank Gavin Andresen, Corinne Dashjr, Mathias Dybvik, Daniel Folkinshteyn, Ian Grigg, Shaul Kfir, midnightmagic, Patrick Strateman, Kat Walsh, and Glenn Willen for reviewer 500 comments.