path: root/a9/d3b073124925bd4c376ee3adb08e8e9b1fbc08

Return-Path: <celeris@use.startmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D3869C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<pre xmlns=3D"http://www.w3.org/1999/xhtml"><span class=3D"font" style=
=3D"font-family: &quot;courier new&quot;, courier, monospace, sans-seri=
f;"># 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"colour" style=3D"color:rgb(59, 67, 92)"><=
span class=3D"size" style=3D"font-size: medium"></span></span>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] </span><a href=3D"https://blockstream.com/sidechains.pdf"><span c=
lass=3D"font" style=3D"font-family: &quot;courier new&quot;, courier, m=
onospace, sans-serif;">https://blockstream.com/sidechains.pdf</span></a=
><span class=3D"font" style=3D"font-family: &quot;courier new&quot;, co=
urier, monospace, sans-serif;">
- [2] </span><a href=3D"https://zmnscpxj.github.io/sidechain/weakness/i=
ndex.html"><span class=3D"font" style=3D"font-family: &quot;courier new=
&quot;, courier, monospace, sans-serif;">https://zmnscpxj.github.io/sid=
echain/weakness/index.html</span></a><span class=3D"font" style=3D"font=
-family: &quot;courier new&quot;, courier, monospace, sans-serif;">
- [3] </span><a href=3D"https://diyhpl.us/~bryan/papers2/bitcoin/Drivec=
hains,%20sidechains%20and%20hybrid%202-way%20peg%20designs%20-%20Sergio=
%20Lerner%20-%202016.pdf"><span class=3D"font" style=3D"font-family: &q=
uot;courier new&quot;, courier, monospace, sans-serif;">https://diyhpl.=
us/~bryan/papers2/bitcoin/Drivechains,%20sidechains%20and%20hybrid%202-=
way%20peg%20designs%20-%20Sergio%20Lerner%20-%202016.pdf</span></a><spa=
n class=3D"font" style=3D"font-family: &quot;courier new&quot;, courier=
, monospace, sans-serif;">
- [4] </span><a href=3D"https://www.drivechain.info"><span class=3D"fon=
t" style=3D"font-family: &quot;courier new&quot;, courier, monospace, s=
ans-serif;">https://www.drivechain.info</span></a><span class=3D"font" =
style=3D"font-family: &quot;courier new&quot;, courier, monospace, sans=
-serif;">
- [5] </span><a href=3D"https://ibcprotocol.org"><span class=3D"font" s=
tyle=3D"font-family: &quot;courier new&quot;, courier, monospace, sans-=
serif;">https://ibcprotocol.org</span></a><span class=3D"font" style=3D=
"font-family: &quot;courier new&quot;, courier, monospace, sans-serif;">
- [6] </span><a href=3D"https://www.blockchain.com/explorer/charts/pool=
s?timespan=3D24hrs"><span class=3D"font" style=3D"font-family: &quot;co=
urier new&quot;, courier, monospace, sans-serif;">https://www.blockchai=
n.com/explorer/charts/pools?timespan=3D24hrs</span></a><span class=3D"f=
ont" style=3D"font-family: &quot;courier new&quot;, courier, monospace,=
 sans-serif;">
- [7] </span><a href=3D"https://crypto.stackexchange.com/questions/5399=
1/is-there-a-cryptographic-solution-to-provide-a-proof-of-exclusion"><s=
pan class=3D"font" style=3D"font-family: &quot;courier new&quot;, couri=
er, monospace, sans-serif;">https://crypto.stackexchange.com/questions/=
53991/is-there-a-cryptographic-solution-to-provide-a-proof-of-exclusion=
</span></a><span class=3D"font" style=3D"font-family: &quot;courier new=
&quot;, courier, monospace, sans-serif;">
- [8] </span><a href=3D"https://old.reddit.com/r/cryptography/comments/=
u3s341/proofofexclusion_data_structure/"><span class=3D"font" style=3D"=
font-family: &quot;courier new&quot;, courier, monospace, sans-serif;">=
https://old.reddit.com/r/cryptography/comments/u3s341/proofofexclusion_=
data_structure/</span></a><span class=3D"font" style=3D"font-family: &q=
uot;courier new&quot;, courier, monospace, sans-serif;">
<br /></span></pre><p xmlns=3D"http://www.w3.org/1999/xhtml" style=3D"w=
ord-wrap: break-word; overflow-wrap: break-word; margin: 0; color: rgb(=
59, 67, 92); font-family: arial, helvetica; font-size: medium;"><br /><=
/p>

--===============5380483942848967400==--