Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3869C0032 for ; Sun, 10 Sep 2023 17:26:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A7C1B60750 for ; Sun, 10 Sep 2023 17:26:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A7C1B60750 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=startmail.com header.i=@startmail.com header.a=rsa-sha256 header.s=2020-07 header.b=2ggaecXs X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ikdO8AA6xU4 for ; Sun, 10 Sep 2023 17:26:44 +0000 (UTC) X-Greylist: delayed 314 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 10 Sep 2023 17:26:43 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E51A1606C6 Received: from mx-out1.startmail.com (mx-out1.startmail.com [145.131.90.139]) by smtp3.osuosl.org (Postfix) with ESMTPS id E51A1606C6 for ; Sun, 10 Sep 2023 17:26:43 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5380483942848967400==" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=startmail.com; s=2020-07; t=1694366486; bh=7PXbAwQ3ysv4SbeeM7dUillrd2kxb01YZ8nl5BbHvto=; h=Content-Type:Subject:Message-ID:Date:From:To:Mime-Version:From: Subject:To:Date:Sender:Content-Type:Content-Transfer-Encoding: Content-Disposition:Mime-Version:Reply-To:In-Reply-To:References: Message-Id:Autocrypt; b=2ggaecXsHNIs/cdMlOiL0yxXZrZLCRvwjIR7xZXaRNi2kUKKlWixCEtwU45LTPrVT j28lt75MPBNIgkUyncc9geE1ytNHeBlCjgyCtd+ZxqomnUaHsXV2QEhqRMYuLrPlOe 2/oijMHYh582bl1Bvkk92OoCTFwdxhpkCempojHw+RSZ9Qh0S2ZkuecATTabiPLLfE 0tb2YOdXL3LYoEXYDxOhfFQf0dgcYXLxYvV2tB8odg3SaiKFJsDoYKVTiUE1Q78lU2 6nQKH7CBrz1fJuTXZYFJRG5oOIVklZMnfm+A7Cgdp2K+cj8EKQ5SDx0uQSFRJIT//1 tqinkxiy05FDw== Message-ID: <169436648600.20.13269452997265912796@startmail.com> Date: Sun, 10 Sep 2023 17:21:26 -0000 From: celeris@use.startmail.com To: bitcoin-dev@lists.linuxfoundation.org Mime-Version: 1.0 X-Mailman-Approved-At: Sun, 10 Sep 2023 17:40:50 +0000 Subject: [bitcoin-dev] Bitcoin Fusion Protocol (BFP) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2023 17:26:46 -0000 --===============5380483942848967400== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable # Bitcoin Fusion Protocol (BFP) =20 ## Motivation =20 This work builds upon, and slightly modifies the previous Sidechain= s paper by Adam Back et. al [1] to address theft concerns raised by Zmn= SCPxj [2] and others [3]. Additionally, this work is motivated by recen= t discussion suggesting that Bitcoin users give miners ownership over a= ll Bitcoins sent to Drivechains [4] by "leaning in" to the challenges t= hat all sidechain-like proposals face, as opposed to mitigating the ris= ks as best as possible at the protocol level. =20 The proposal herein is a high-level conceptual proposal, not a low-= level technical proposal. It is being sent to the list because as far a= s the author is aware, these suggestions have not been made before. It = is up to those with intimate knowledge of the inner workings and limita= tions of Bitcoin to decide how, if at all, to adapt this proposal to Bi= tcoin's constraints. =20 ## BFP Summary =20 We describe the following mechanisms (some new, some from the Sidec= hains paper): =20 1. Before transferring coins from Chain A to B we lock them on Chai= n A by creating a special transaction that says, "these coins are being= sent to Chain B". The fact that the coins are locked is stored in a me= rkle tree for easy verification by other chains. 2. On Chain B, a transaction is created to transfer the tokens cont= aining an SPV proof. Once accepted as part of the chain, the SPV proof = from Chain A cannot be reused. We recommend, to reduce the storage cost= s of remembering proofs, that proofs older than 30 days be rejected (se= e "Missing details"). Only transfers for which at least 95% of the conn= ected full nodes respond with a valid SPV proof will be accepted into a= block to reduce the risk of forks. - Note: refer to the Sidechains paper [1] for details on the "con= firmation period" and "contest period" in Section 3.2. 3. Connecting approved blockchains is accomplished through a vote. = If Chain A wishes to fuse with Chain B, it first conducts a supermajori= ty vote to do so. If the proposal passes on Chain A, this fact is sent = in a special proposal transaction asking the Chain B consensus group ("= miners") to vote on the request to fuse together. If a supermajority on= Chain B votes "yes" (say, at over 70% approval), over a certain time w= indow (say 3 weeks), then the chains are "fused" and are authorized to = transfer coins to each other. This is similar to how IBC [5] works. 4. Light client verification requirements on miners and full nodes.= All miners and full nodes on Chain A must run light client software fo= r Chain B, and vice versa, in order to validate (with SPV-level securit= y) that incoming coins from the other chain have valid proofs. They mus= t remember recent lock proofs so that they cannot be reused. The light = clients must be fully synced with the other chains before the miner pub= lishes a block, so that it can verify the transfer occurred in a recent= block on the other chain. These light clients must communicate with th= e full nodes of the chain they are validating so that they can catch an= y fabrications made by miners. 5. Other chains can have arbitrary consensus mechanisms, and are in= fact encouraged to use something other than Nakamoto consensus so that= a different consensus group can build the other chain. =20 ## Differences with Sidechains paper =20 The main differences involve the light client requirements. If a st= andardized light client protocol can be developed and enforced to valid= ate sidechains, then the likelihood of theft can reduced significantly.= The reason theft is more likely to occur with the original Sidechains = proposal is that mainchain miners do not connect to sidechain full node= s. This proposal "fuses" chains together to minimize the likelihood of = theft by requiring that fused chains validate each other through a ligh= t client protocol that communicates with the full nodes of the fused ch= ain. =20 It further enforces that full nodes of Chain B use the generalized = light client protocol to reject blocks mined by Chain B miners if those= blocks contain transfers from Chain A that cannot be verified by Chain= A full nodes. See "Theft attempts" below for more details. =20 Because there is a single generic light client protocol that can be= used to validate any sidechain, full nodes and miners of a chain can i= mmediately begin to validate newly "fused" sidechains. The light client= protocol is designed purposefully to support additional arbitrary cons= ensus protocols. Although at the start it may only support one consensu= s protocol, through upgrades of the full node software it can be modifi= ed to support arbitrary consensus protocols on an as-needed basis (like= PoS, etc.). =20 ## Advantages over other proposals =20 1. Users do not give up custody of their coins to miners. 2. Users do not need to wait months to get their Bitcoin transferre= d between one chain to another. The transfer can happen in minutes or h= ours, depending on various security parameter considerations (like bloc= k production rate, value transferred, etc.). 3. There is no incentivisation of miner centralization. In fact, th= is proposal increases decentralization by encouraging different mining = groups to form around other chains using different consensus algorithms. 4. There is no need for an on-chain constant transaction-per-block = overhead from fused chains. A tiny amount of off-chain storage space is= needed by full nodes to keep track of recently used SPV proofs and sid= echain headers. 5. It is possible for users to send coins from one sidechain to ano= ther without going through the main chain. Some other proposals support= this feature too, but not all, so it's worth mentioning. =20 ## Tradeoffs and security considerations =20 ### Theft attempts =20 A miner on Chain B could insert a provably invalid transfer transac= tion for coins that were were not actually locked on Chain A. =20 In this case, other miners on Chain B that detect the fraud must no= t build on this block and Chain B full nodes must also reject the block. =20 Both miners and full nodes must ensure that they are connected to a= t least 7 different full nodes per fused chain. They should use a "dive= rsity metric" to pick the IPs that they connect to, so that they are no= t connecting to 7 IPs on the same subnet (if at all possible). At least= 95% of these must respond with a valid SPV proof for a transfer to be = considered valid. The number 7 is chosen because some number must be pi= cked and 7 seems reasonable to the author (not too small, but also not = so large that it becomes burdensome on full nodes). Theory and real-wor= ld testing might suggest a different number. If the node cannot establi= sh this minimum number of connections to any particular fused chain, it= should warn the user of the increased risk of being unable to properly= validate either chain. =20 Although unlikely, it is also theoretically possible that a chain m= ay decide to vote to fuse a sidechain that is purposefully designed for= the sole purpose of stealing any coins sent to it, or a sidechain that= later falls under the full control of a malicious entity. In this situ= ation, both the miners and all full nodes on the fraudulent chain lie. = In such a situation, any coins sent to this chain can be stolen. Howeve= r, this unlikely situation would be detected, and mitigations are still= possible. Full nodes on the parent chain could decide to blacklist the= fradulent sidechain and refuse to accept blocks containing transaction= s from it (potentially causing the parent chain to grind to a halt unti= l good miners -- who also refuse to accept transactions from the sidech= ain -- take over). There could be a vote to "defuse" from the sidechain= . And finally, we note that the maximum damage in this worst-case scena= rio is still significantly less than the worst-case scenario of alterna= tive proposals like Drivechain [4] where the possibility of stolen fund= s is greater and exists equally for every drivechain for the following = reasons: =20 1. In BFP (and Sidechains), coins are locked and an SPV proof is re= quired to unlock them. In Drivechains, all coins sent to drivechains ar= e given to Bitcoin miners from the outset via the so-called "hashrate e= scrow". 2. In BFP, there is the very distinct and clear possibility that ma= ny diverse groups are responsible for the security of the overall syste= m, and the compromise of any one of these groups only affects the speci= fic sidechain. For example, if there are 10 sidechains, there are poten= tially 10 different consensus groups involved. However, in Drivechain, = there is a single group responsible for the security of all drivechains= and the mainchain. At the moment that group consists of two companies = [6]. =20 ### Lost funds =20 If Chain A locks coins and sends them to Chain B, but Chain B doesn= 't accept them for whatever reason, then it is possible for the coins t= o become forever lost. =20 The 30 day window allows for the possibility of resending the trans= action with a higher fee, but if after 30 days from the original lockin= g transaction the coins are still not transferred to the receiving chai= n, they are locked forever. This is unlikely but not impossible. =20 It might be possible to improve this proposal in some way by adding= a new "proof of non-inclusion"[7,8] to allow for the recovery of the l= ost funds. Alternatively, the 30 day window could be removed completely= , at extra storage cost to full nodes for having to remember all SPV pr= oofs. =20 ### Increased fork risk =20 This proposal increases the amount of outgoing connections traffic = that a full node must initiate in order to fully validate blocks. Traff= ic is increased with each additional fused chain. If, for some reason, = the full node is not able to communicate with the honest full nodes of = every fused chain, it might not be able to validate every block and the= refore is at increased risk of forking off and being unable to continue= validating new blocks. =20 ## Missing details =20 As stated, this proposal is not a fully specified proposal. It is a= seed intended to spark discussion and further iteration, building on t= he wonderful work of the original Sidechain proposal authors. To that e= nd, the following details must be filled in: =20 1. The precise nature of the generalized light client protocol and = how it can be designed to expand to support different consensus algorit= hms (not just PoW). 2. Just how significant of a fork risk is introduced here and mecha= nisms by which it could be reduced. 3. How much storage could be expected for having to remember all SP= V proofs (to prevent re-use). If it's insignificant, then the 30 day wi= ndow should be removed. =20 ## Conclusion =20 This proposal is given to the community to improve and expand upon = as it sees fit. =20 The author of this proposal summary will not be filling in the tech= nical details nor sending in an implementation. The point of this propo= sal is to show that there is a Bitcoin-way to do multi-chain =E2=80=94 = if the Bitcoin community wants that feature and wishes to keep the Bitc= oin spirit alive. =20 ``` . = =20 -#- ## = =20 .-=3D%%+*##=3D... ..... = =20 .=3D*#######+-=3D++::-+-+*=3D---::. = =20 :*#######%%%#*##. ::---=3D=3D++=3D---:: = =20 :+####*+::-++%%%#. .=3D-:--=3D-+=3D-+#****#+. = =20 :=3D+++*+=3D=3D*+::--+%%+ =3D+-+-=3D=3D+=3D-=3D= ++*####* =20 :++++*#-=3D-=3D*:-:+*%%- :--+--=3D=3D--**-=3D-*#= ###: =20 :-***++###+*++=3D=3D+#%%+ .=3D=3D=3D=3D=3D---=3D+= =3D-=3D-+####+ =20 -=3D++++*##*****#**###%%*#: ..-=3D-:-++##+---+#####+= : =20 :=3D+++++*#*#%#*+=3D#########=3D=3D+-..=3D-::: :=3D+*+##= #########*+ =20 :-=3D++++***#%%%%#**=3D:.*#%%%%%#-:: .--++----- :-#*######= ###*=3D: =20 -+#*++++*#+=3D#%%#++***- .::... .:. =3D**###*#####= ######=3D =20 =3D*+****#*=3D. .##******#: -*#####*#**= =3D:+#######: =20 =3D##*****- : =3D*##*=3D .=3D#####+*= ++=3D :*#####+. =20 :.+#*-::. =3D*## .****.: = .--=3D+*##=3D=20 *#*+: -=3D=3D+*-. .=3D***#+ = -+##* ``` =20 ## References =20 - [1] [https://blockstream.com/sidechains.pdf](https://blockstream.= com/sidechains.pdf) - [2] [https://zmnscpxj.github.io/sidechain/weakness/index.html](ht= tps://zmnscpxj.github.io/sidechain/weakness/index.html) - [3] [https://diyhpl.us/~bryan/papers2/bitcoin/Drivechains,%20side= chains%20and%20hybrid%202-way%20peg%20designs%20-%20Sergio%20Lerner%20-= %202016.pdf](https://diyhpl.us/~bryan/papers2/bitcoin/Drivechains,%20si= dechains%20and%20hybrid%202-way%20peg%20designs%20-%20Sergio%20Lerner%2= 0-%202016.pdf) - [4] [https://www.drivechain.info](https://www.drivechain.info) - [5] [https://ibcprotocol.org](https://ibcprotocol.org) - [6] [https://www.blockchain.com/explorer/charts/pools?timespan=3D= 24hrs](https://www.blockchain.com/explorer/charts/pools?timespan=3D24hr= s) - [7] [https://crypto.stackexchange.com/questions/53991/is-there-a-= cryptographic-solution-to-provide-a-proof-of-exclusion](https://crypto.= stackexchange.com/questions/53991/is-there-a-cryptographic-solution-to-= provide-a-proof-of-exclusion) - [8] [https://old.reddit.com/r/cryptography/comments/u3s341/proofo= fexclusion_data_structure/](https://old.reddit.com/r/cryptography/comme= nts/u3s341/proofofexclusion_data_structure/) =20 =20 =20 --===============5380483942848967400== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 
# Bitcoin Fusion Protocol (BFP)

## Motivation

This work builds upon, and slightly modifies the previous Sidechains pa=
per by Adam Back et. al [1] to address theft concerns raised by ZmnSCPx=
j [2] and other<=
span class=3D"size" style=3D"font-size: medium">s [3]. Ad=
ditionally, this work is motivated by recent discussion suggesting that=
 Bitcoin users give miners ownership over all Bitcoins sent to Drivecha=
ins [4] by "leaning in" to the challenges that all sidechain-like propo=
sals face, as opposed to mitigating the risks as best as possible at th=
e protocol level.

The proposal herein is a high-level conceptual proposal, not a low-leve=
l technical proposal. It is being sent to the list because as far as th=
e author is aware, these suggestions have not been made before. It is u=
p to those with intimate knowledge of the inner workings and limitation=
s of Bitcoin to decide how, if at all, to adapt this proposal to Bitcoi=
n's constraints.

## BFP Summary

We describe the following mechanisms (some new, some from the Sidechain=
s paper):

1. Before transferring coins from Chain A to B we lock them on Chain A =
by creating a special transaction that says, "these coins are being sen=
t to Chain B". The fact that the coins are locked is stored in a merkle=
 tree for easy verification by other chains.
2. On Chain B, a transaction is created to transfer the tokens containi=
ng an SPV proof. Once accepted as part of the chain, the SPV proof from=
 Chain A cannot be reused. We recommend, to reduce the storage costs of=
 remembering proofs, that proofs older than 30 days be rejected (see "M=
issing details"). Only transfers for which at least 95% of the connecte=
d full nodes respond with a valid SPV proof will be accepted into a blo=
ck to reduce the risk of forks.
  - Note: refer to the Sidechains paper [1] for details on the "confirm=
ation period" and "contest period" in Section 3.2.
3. Connecting approved blockchains is accomplished through a vote. If C=
hain A wishes to fuse with Chain B, it first conducts a supermajority v=
ote to do so. If the proposal passes on Chain A, this fact is sent in a=
 special proposal transaction asking the Chain B consensus group ("mine=
rs") to vote on the request to fuse together. If a supermajority on Cha=
in B votes "yes" (say, at over 70% approval), over a certain time windo=
w (say 3 weeks), then the chains are "fused" and are authorized to tran=
sfer coins to each other. This is similar to how IBC [5] works.
4. Light client verification requirements on miners and full nodes. All=
 miners and full nodes on Chain A must run light client software for Ch=
ain B, and vice versa, in order to validate (with SPV-level security) t=
hat incoming coins from the other chain have valid proofs. They must re=
member recent lock proofs so that they cannot be reused. The light clie=
nts must be fully synced with the other chains before the miner publish=
es a block, so that it can verify the transfer occurred in a recent blo=
ck on the other chain. These light clients must communicate with the fu=
ll nodes of the chain they are validating so that they can catch any fa=
brications made by miners.
5. Other chains can have arbitrary consensus mechanisms, and are in fac=
t encouraged to use something other than Nakamoto consensus so that a d=
ifferent consensus group can build the other chain.

## Differences with Sidechains paper

The main differences involve the light client requirements. If a standa=
rdized light client protocol can be developed and enforced to validate =
sidechains, then the likelihood of theft can reduced significantly. The=
 reason theft is more likely to occur with the original Sidechains prop=
osal is that mainchain miners do not connect to sidechain full nodes. T=
his proposal "fuses" chains together to minimize the likelihood of thef=
t by requiring that fused chains validate each other through a light cl=
ient protocol that communicates with the full nodes of the fused chain.

It further enforces that full nodes of Chain B use the generalized ligh=
t client protocol to reject blocks mined by Chain B miners if those blo=
cks contain transfers from Chain A that cannot be verified by Chain A f=
ull nodes. See "Theft attempts" below for more details.

Because there is a single generic light client protocol that can be use=
d to validate any sidechain, full nodes and miners of a chain can immed=
iately begin to validate newly "fused" sidechains. The light client pro=
tocol is designed purposefully to support additional arbitrary consensu=
s protocols. Although at the start it may only support one consensus pr=
otocol, through upgrades of the full node software it can be modified t=
o support arbitrary consensus protocols on an as-needed basis (like PoS=
, etc.).

## Advantages over other proposals

1. Users do not give up custody of their coins to miners.
2. Users do not need to wait months to get their Bitcoin transferred be=
tween one chain to another. The transfer can happen in minutes or hours=
, depending on various security parameter considerations (like block pr=
oduction rate, value transferred, etc.).
3. There is no incentivisation of miner centralization. In fact, this p=
roposal increases decentralization by encouraging different mining grou=
ps to form around other chains using different consensus algorithms.
4. There is no need for an on-chain constant transaction-per-block over=
head from fused chains. A tiny amount of off-chain storage space is nee=
ded by full nodes to keep track of recently used SPV proofs and sidecha=
in headers.
5. It is possible for users to send coins from one sidechain to another=
 without going through the main chain. Some other proposals support thi=
s feature too, but not all, so it's worth mentioning.

## Tradeoffs and security considerations

### Theft attempts

A miner on Chain B could insert a provably invalid transfer transaction=
 for coins that were were not actually locked on Chain A.

In this case, other miners on Chain B that detect the fraud must not bu=
ild on this block and Chain B full nodes must also reject the block.

Both miners and full nodes must ensure that they are connected to at le=
ast 7 different full nodes per fused chain. They should use a "diversit=
y metric" to pick the IPs that they connect to, so that they are not co=
nnecting to 7 IPs on the same subnet (if at all possible). At least 95%=
 of these must respond with a valid SPV proof for a transfer to be cons=
idered valid. The number 7 is chosen because some number must be picked=
 and 7 seems reasonable to the author (not too small, but also not so l=
arge that it becomes burdensome on full nodes). Theory and real-world t=
esting might suggest a different number. If the node cannot establish t=
his minimum number of connections to any particular fused chain, it sho=
uld warn the user of the increased risk of being unable to properly val=
idate either chain.

Although unlikely, it is also theoretically possible that a chain may d=
ecide to vote to fuse a sidechain that is purposefully designed for the=
 sole purpose of stealing any coins sent to it, or a sidechain that lat=
er falls under the full control of a malicious entity. In this situatio=
n, both the miners and all full nodes on the fraudulent chain lie. In s=
uch a situation, any coins sent to this chain can be stolen. However, t=
his unlikely situation would be detected, and mitigations are still pos=
sible. Full nodes on the parent chain could decide to blacklist the fra=
dulent sidechain and refuse to accept blocks containing transactions fr=
om it (potentially causing the parent chain to grind to a halt until go=
od miners -- who also refuse to accept transactions from the sidechain =
-- take over). There could be a vote to "defuse" from the sidechain. An=
d finally, we note that the maximum damage in this worst-case scenario =
is still significantly less than the worst-case scenario of alternative=
 proposals like Drivechain [4] where the possibility of stolen funds is=
 greater and exists equally for every drivechain for the following reas=
ons:

1. In BFP (and Sidechains), coins are locked and an SPV proof is requir=
ed to unlock them. In Drivechains, all coins sent to drivechains are gi=
ven to Bitcoin miners from the outset via the so-called "hashrate escro=
w".
2. In BFP, there is the very distinct and clear possibility that many d=
iverse groups are responsible for the security of the overall system, a=
nd the compromise of any one of these groups only affects the specific =
sidechain. For example, if there are 10 sidechains, there are potential=
ly 10 different consensus groups involved. However, in Drivechain, ther=
e is a single group responsible for the security of all drivechains and=
 the mainchain. At the moment that group consists of two companies [6].

### Lost funds

If Chain A locks coins and sends them to Chain B, but Chain B doesn't a=
ccept them for whatever reason, then it is possible for the coins to be=
come forever lost.

The 30 day window allows for the possibility of resending the transacti=
on with a higher fee, but if after 30 days from the original locking tr=
ansaction the coins are still not transferred to the receiving chain, t=
hey are locked forever. This is unlikely but not impossible.

It might be possible to improve this proposal in some way by adding a n=
ew "proof of non-inclusion"[7,8] to allow for the recovery of the lost =
funds. Alternatively, the 30 day window could be removed completely, at=
 extra storage cost to full nodes for having to remember all SPV proofs.

### Increased fork risk

This proposal increases the amount of outgoing connections traffic that=
 a full node must initiate in order to fully validate blocks. Traffic i=
s increased with each additional fused chain. If, for some reason, the =
full node is not able to communicate with the honest full nodes of ever=
y fused chain, it might not be able to validate every block and therefo=
re is at increased risk of forking off and being unable to continue val=
idating new blocks.

## Missing details

As stated, this proposal is not a fully specified proposal. It is a see=
d intended to spark discussion and further iteration, building on the w=
onderful work of the original Sidechain proposal authors. To that end, =
the following details must be filled in:

1. The precise nature of the generalized light client protocol and how =
it can be designed to expand to support different consensus algorithms =
(not just PoW).
2. Just how significant of a fork risk is introduced here and mechanism=
s by which it could be reduced.
3. How much storage could be expected for having to remember all SPV pr=
oofs (to prevent re-use). If it's insignificant, then the 30 day window=
 should be removed.

## Conclusion

This proposal is given to the community to improve and expand upon as i=
t sees fit.

The author of this proposal summary will not be filling in the technica=
l details nor sending in an implementation. The point of this proposal =
is to show that there is a Bitcoin-way to do multi-chain =E2=80=94 if t=
he Bitcoin community wants that feature and wishes to keep the Bitcoin =
spirit alive.

```
                                 .                                     =
   =20
                            -#-  ##                                    =
   =20
                          .-=3D%%+*##=3D...   .....                    =
       =20
                        .=3D*#######+-=3D++::-+-+*=3D---::.            =
         =20
                      :*#######%%%#*##.  ::---=3D=3D++=3D---::         =
         =20
                    :+####*+::-++%%%#. .=3D-:--=3D-+=3D-+#****#+.      =
         =20
                  :=3D+++*+=3D=3D*+::--+%%+   =3D+-+-=3D=3D+=3D-=3D++*#=
###*               =20
                 :++++*#-=3D-=3D*:-:+*%%-   :--+--=3D=3D--**-=3D-*####:=
             =20
               :-***++###+*++=3D=3D+#%%+    .=3D=3D=3D=3D=3D---=3D+=3D-=
=3D-+####+             =20
            -=3D++++*##*****#**###%%*#:    ..-=3D-:-++##+---+#####+:   =
       =20
          :=3D+++++*#*#%#*+=3D#########=3D=3D+-..=3D-:::  :=3D+*+######=
#####*+        =20
      :-=3D++++***#%%%%#**=3D:.*#%%%%%#-::   .--++-----  :-#*#########*=
=3D:     =20
     -+#*++++*#+=3D#%%#++***-  .::...            .:. =3D**###*#########=
##=3D    =20
    =3D*+****#*=3D. .##******#:                       -*#####*#**=3D:+#=
######:  =20
   =3D##*****-     :  =3D*##*=3D                        .=3D#####+*++=
=3D  :*#####+. =20
 :.+#*-::.          =3D*##                            .****.:      .--=
=3D+*##=3D=20
*#*+:               -=3D=3D+*-.                       .=3D***#+        =
     -+##*
```

## References

- [1] https://blockstream.com/sidechains.pdf
- [2] https://zmnscpxj.github.io/sid=
echain/weakness/index.html
- [3] https://diyhpl.=
us/~bryan/papers2/bitcoin/Drivechains,%20sidechains%20and%20hybrid%202-=
way%20peg%20designs%20-%20Sergio%20Lerner%20-%202016.pdf
- [4] https://www.drivechain.info
- [5] https://ibcprotocol.org
- [6] https://www.blockchai=
n.com/explorer/charts/pools?timespan=3D24hrs
- [7] https://crypto.stackexchange.com/questions/=
53991/is-there-a-cryptographic-solution-to-provide-a-proof-of-exclusion=

- [8] =
https://old.reddit.com/r/cryptography/comments/u3s341/proofofexclusion_=
data_structure/


<= /p> --===============5380483942848967400==--