[bitcoin-dev] Bitcoin Fusion Protocol (BFP)

[bitcoin-dev] Bitcoin Fusion Protocol (BFP)

[celeris]

[-- Attachment #1: Type: text/plain, Size: 13966 bytes --]


    # Bitcoin Fusion Protocol (BFP)
    
    ## Motivation
    
    This work builds upon, and slightly modifies the previous Sidechains paper by Adam Back et. al [1] to address theft concerns raised by ZmnSCPxj [2] and others [3]. Additionally, this work is motivated by recent discussion suggesting that Bitcoin users give miners ownership over all Bitcoins sent to Drivechains [4] by "leaning in" to the challenges that all sidechain-like proposals face, as opposed to mitigating the risks as best as possible at the protocol level.
    
    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 as the author is aware, these suggestions have not been made before. It is up to those with intimate knowledge of the inner workings and limitations of Bitcoin to decide how, if at all, to adapt this proposal to Bitcoin's constraints.
    
    ## BFP Summary
    
    We describe the following mechanisms (some new, some from the Sidechains 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 sent 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 containing 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 "Missing details"). Only transfers for which at least 95% of the connected 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 "confirmation 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 supermajority 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 window (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 for Chain B, and vice versa, in order to validate (with SPV-level security) that incoming coins from the other chain have valid proofs. They must remember recent lock proofs so that they cannot be reused. The light clients must be fully synced with the other chains before the miner publishes a block, so that it can verify the transfer occurred in a recent block on the other chain. These light clients must communicate with the full nodes of the chain they are validating so that they can catch any 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.
    
    ## Differences with Sidechains paper
    
    The main differences involve the light client requirements. If a standardized 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 proposal is that mainchain miners do not connect to sidechain full nodes. This proposal "fuses" chains together to minimize the likelihood of theft by requiring that fused chains validate each other through a light client protocol that communicates with the full nodes of the fused chain.
    
    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.
    
    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 immediately begin to validate newly "fused" sidechains. The light client protocol is designed purposefully to support additional arbitrary consensus protocols. Although at the start it may only support one consensus protocol, through upgrades of the full node software it can be modified to 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 between one chain to another. The transfer can happen in minutes or hours, depending on various security parameter considerations (like block production rate, value transferred, etc.).
    3. There is no incentivisation of miner centralization. In fact, this 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 sidechain 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 this 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 build 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 least 7 different full nodes per fused chain. They should use a "diversity metric" to pick the IPs that they connect to, so that they are not 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 picked 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-world testing might suggest a different number. If the node cannot establish 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.
    
    Although unlikely, it is also theoretically possible that a chain may 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 situation, 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. However, 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 transactions from it (potentially causing the parent chain to grind to a halt until good miners -- who also refuse to accept transactions from the sidechain -- take over). There could be a vote to "defuse" from the sidechain. And 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 reasons:
    
    1. In BFP (and Sidechains), coins are locked and an SPV proof is required to unlock them. In Drivechains, all coins sent to drivechains are given to Bitcoin miners from the outset via the so-called "hashrate escrow".
    2. In BFP, there is the very distinct and clear possibility that many diverse groups are responsible for the security of the overall system, and the compromise of any one of these groups only affects the specific sidechain. For example, if there are 10 sidechains, there are potentially 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].
    
    ### Lost funds
    
    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 to become forever lost.
    
    The 30 day window allows for the possibility of resending the transaction with a higher fee, but if after 30 days from the original locking transaction the coins are still not transferred to the receiving chain, they are locked forever. This is unlikely but not impossible.
    
    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 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 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 therefore is at increased risk of forking off and being unable to continue validating new blocks.
    
    ## Missing details
    
    As stated, this proposal is not a fully specified proposal. It is a seed intended to spark discussion and further iteration, building on the wonderful 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 mechanisms by which it could be reduced.
    3. How much storage could be expected for having to remember all SPV proofs (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 it sees fit.
    
    The author of this proposal summary will not be filling in the technical details nor sending in an implementation. The point of this proposal is to show that there is a Bitcoin-way to do multi-chain — if the Bitcoin community wants that feature and wishes to keep the Bitcoin spirit alive.
    
    ```
                                     .                                         
                                -#-  ##                                        
                              .-=%%+*##=...   .....                            
                            .=*#######+-=++::-+-+*=---::.                      
                          :*#######%%%#*##.  ::---==++=---::                   
                        :+####*+::-++%%%#. .=-:--=-+=-+#****#+.                
                      :=+++*+==*+::--+%%+   =+-+-==+=-=++*####*                
                     :++++*#-=-=*:-:+*%%-   :--+--==--**-=-*####:              
                   :-***++###+*++==+#%%+    .=====---=+=-=-+####+              
                -=++++*##*****#**###%%*#:    ..-=-:-++##+---+#####+:           
              :=+++++*#*#%#*+=#########==+-..=-:::  :=+*+###########*+         
          :-=++++***#%%%%#**=:.*#%%%%%#-::   .--++-----  :-#*#########*=:      
         -+#*++++*#+=#%%#++***-  .::...            .:. =**###*###########=     
        =*+****#*=. .##******#:                       -*#####*#**=:+#######:   
       =##*****-     :  =*##*=                        .=#####+*++=  :*#####+.  
     :.+#*-::.          =*##                            .****.:      .--=+*##= 
    *#*+:               -==+*-.                       .=***#+             -+##*
    ```
    
    ## References
    
    - [1] [https://blockstream.com/sidechains.pdf](https://blockstream.com/sidechains.pdf)
    - [2] [https://zmnscpxj.github.io/sidechain/weakness/index.html](https://zmnscpxj.github.io/sidechain/weakness/index.html)
    - [3] [https://diyhpl.us/~bryan/papers2/bitcoin/Drivechains,%20sidechains%20and%20hybrid%202-way%20peg%20designs%20-%20Sergio%20Lerner%20-%202016.pdf](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](https://www.drivechain.info)
    - [5] [https://ibcprotocol.org](https://ibcprotocol.org)
    - [6] [https://www.blockchain.com/explorer/charts/pools?timespan=24hrs](https://www.blockchain.com/explorer/charts/pools?timespan=24hrs)
    - [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/proofofexclusion_data_structure/](https://old.reddit.com/r/cryptography/comments/u3s341/proofofexclusion_data_structure/)
      
    

  


[-- Attachment #2: Type: text/html, Size: 15733 bytes --]