From e52c1ff5d9202ad7f44fc2ea2842996c1db82d03 Mon Sep 17 00:00:00 2001 From: owen <158327443+owenzimmew06@users.noreply.github.com> Date: Mon, 10 Mar 2025 10:31:24 +0300 Subject: [PATCH] Update sidechain_bridges.md Hi, I noticed 3 issues in this text and suggest changes: 1. "create way for Bitcoin full nodes": "create way" is missing an article. Suggested revision: "create a way for Bitcoin full nodes", 2. "inlcuding a sidechain light client": Typo: "inlcuding" should be "including" Corrected phrase: "including a sidechain light client", 3. "create a such program": "create a such program" is grammatically incorrect. Suggested revision: "create such a program". Thanks. --- docs/sidechain_bridges.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/sidechain_bridges.md b/docs/sidechain_bridges.md index 3ee1852..bf34378 100644 --- a/docs/sidechain_bridges.md +++ b/docs/sidechain_bridges.md @@ -11,8 +11,8 @@ Write-up is WIP. ### Outline: Optimistic, trust-minimized, BTC bridge with BitVM -The main idea behind a BitVM BTC bridge is to create way for Bitcoin full nodes to operate a sidechain bridge program, inlcuding a sidechain light client, using only Bitcoin script. -While it is known to be impossible to create a such program as an on-chain Bitcoin contract, we make use of BitVM's fraud-proof mechanism to optimistically execute the sidechain light client (and the rest of the bridge program) off-chain, using on-chain transactions only to perform challenges-response games that allow honest actors to prevent dishonest actions by offline or malicious participants. The sidechain implements the equivalent bridge program and Bitcoin light client either as a smart contract. (Note: We need to assume sufficient functionality is available. Alternatively, the sidechain could also implement the bridge program via a BitVM-like mechanism.) +The main idea behind a BitVM BTC bridge is to create a way for Bitcoin full nodes to operate a sidechain bridge program, including a sidechain light client, using only Bitcoin script. +While it is known to be impossible to create such a program as an on-chain Bitcoin contract, we make use of BitVM's fraud-proof mechanism to optimistically execute the sidechain light client (and the rest of the bridge program) off-chain, using on-chain transactions only to perform challenges-response games that allow honest actors to prevent dishonest actions by offline or malicious participants. The sidechain implements the equivalent bridge program and Bitcoin light client either as a smart contract. (Note: We need to assume sufficient functionality is available. Alternatively, the sidechain could also implement the bridge program via a BitVM-like mechanism.) To transfer BTC from Bitcoin to a sidechain, a "Depositor" sends BTC to a multisig controlled by a committee of N members (one Prover="Operator" and N-1 Verifiers="Watchtowers") that commits to the bridge program as part of a BitVM setup. And as long as one of these participants is honest, the deposits remain secure because malicious committee members will be challenged and their access to BTC deposits removed. Whenever a Depositor requests to redeem wrapped xBTC for BTC the currently active Operator verifies the state of the sidechain off-chain and, if everything is correct, sends BTC to the user from her own balance, i.e., fronts the BTC payment to the user. The Operator then requests a reimbursement of the redeemed BTC amount from the deposit multisig. Watchtowers observe this process and verify correctness. Once the Operator requests a reimbursement, Watchtowers can issue an on-chain challenge during a pre-defined challenge period if their off-chain program execution yields a different result, e.g. the Operator sent the wrong BTC amount or paid to a wrong address. If the Operator does not make a BTC payment within a pre-defined timeout period, Watchtowers challenge inactivity. In both cases, Watchtowers trigger an on-chain challenge-response protocol via BitVM. This process requires multiple on-chain Bitcoin transactions in the worst case and results in the Operator being removed from the committee and losing access to the BTC deposited into the bridge. One of the Watchtowers is then selected as Operator and resumes operation of the bridge. To ensure Watchtowers have sufficient incentive to perform challenges (and to cover eventual on-chain Bitcoin transaction fees) the Operator is collateralized on Bitcoin. Similarly, to dis-incentivize false challenges, Watchtowers must also deposit collateral.