Author: Miguel Matos @mmm
Introduction
This post outlines some design ideas for implementing Inter-Blockchain Communication (IBC) protocol for Bitcoin, aimed at enhancing interoperability between Bitcoin and IBC-enabled blockchains.
This proposal is centered around two goals:
- achieve a design as trustless as possible
- leverage Bitcoin’s existing features without requiring, ideally, any changes or extensions to an existing Bitcoin node
Core Concept
The fundamental idea is to use Bitcoin primarily as a secure, immutable log for IBC operations, without executing complex logic on the Bitcoin network itself.
Moving associated funds in BTC will require a mutlisig controlled by the set of validators, as detailed below.
BTC transactions can also encode, if necessary, management metadata such as the set of validators for the next epoch.
Key components include:
- An IBC to BTC component which functions as an IBC solo machine, implementing the necessary logic and state machine. Among others, it converts IBC requests into BTC transactions.
- Bitcoin Light Client
- Validators nodes
- Relayers
The message flow can follow the regular IBC message flow with a few adaptations depending on the trust model and the deployment mode further discussed below.
Signature Management:
To ensure secure and decentralized operation, we propose using Bitcoin’s native multisignatures. This will be required for transactions manipulating funds and protocol metadata (which are opaque transactions to BTC itself).
We also need a way to represent the validators stake. In an ideal scenario each validator holds a key from a multisig scheme, however this can result in a very large multisigs, depending on the number of validators and the way to encode stake heterogeneity. Therefore, we may need an external mechanism to produce multisigs according to the stake weight. We can explore a few options:
-
Simple multisig: preferable option, it allows us to encode the necessary stake information. As the number of validators grows, such that it becomes infeasible for quorum to submit signatures in a single transaction, this can become problematic.
-
Multiple Multisigs: Validators use different multisigs to represent more granular stake weight.
-
Nested Multisigs: Implement “multisig of a multisig” outside Bitcoin.
The system will also require a minimum stake threshold establishing the minimum stake amount for multisig participation. This needs to be done in a dedicated protocol.
We need to do research needed on the limits of Bitcoin multisgs in terms of costs, maximum allowed signatures, etc. This limit will influence stake representation and validator participation design as discussed above.
Discussion Point: What are the trade-offs between accurate stake representation and Bitcoin’s multisig limitations?
Address Reuse
While generally discouraged for privacy reasons, address reuse may be acceptable in this context. Avoiding address reuse means that, potentially, a different multisig and account needs to be agreed upon for every transaction, which can become too costly (financial- and performance-wise).
For an initial prototype this problem can be ignored. Future enhancements could explore privacy-preserving methods if deemed necessary.
Epochs
As usual, validators will have the responsibility to execute the protocol during pre-defined epochs. The governance policies to define who can be a validator, and who is going to be in the validator set in the next epoch needs to be discussed. In principle, we can use existing governance mechanisms. Depending on the trust model and cost, the validator can be registered (logged) either in BTC itself as an opaque transaction, or outside BTC. This is also impacted by the target deployment mode discussed below.
Safe System Shutdown
Implementing a secure shutdown mechanism is crucial for validator confidence. If the system falls into disuse, we want to make sure that validators can recover their funds.
We can explore two approaches:
a) Verifiable Delay Functions (VDFs):
-
Could allow for eventual fund unlocking.
-
Challenges include determining VDF operators and managing individual validator accounts.
b) Hashed Timelocks (HTLs):
-
Leverage Bitcoin’s existing HTL functionality.
-
Create HTLs at the beginning of each epoch for future unlocking.
-
Existing validators, if any, move funds to new addresses at epoch end, creating new HTLs.
-
If there are not enough validators, HTL expires and funds are unlocked.
Both approaches need to address equitable fund distribution among validators.
Discussion Point: What are the security and usability trade-offs between VDFs and HTLs in this context?
Validator Deployment Options
We propose two deployment strategies, depicted below.
Each with its own trade-offs:
a) Smart Contract on a Cosmos Chain:
Pros:
- Familiar to existing Cosmos validators.
- Can leverage existing Cosmos staking mechanisms.
Cons:
- Potential limitations in implementing necessary logic, particularly around mutlisig management
- Requires separate relayer and Bitcoin light client.
b) Independent Node Set:
Individual independent nodes, deployed specifically for this purpose.
Pros:
- Greater implementation flexibility.
- Direct control over the entire system.
Cons:
- May be less familiar to potential validators.
- Requires building a new validator ecosystem.
Both options require careful consideration of consensus mechanisms, incentive structures, and governance systems. The Cosmos option probably allows for most mechanisms to be reused.
Discussion Point: How can we design the deployment to maximize security, decentralization, and ease of adoption?
Conclusion:
The proposed IBTC design offers a potentially simpler approach to implementing IBC for Bitcoin compared to approaches executing computations directly on Bitcoin itself.
With a proper initial setup of the system (which will have to be trusted), both alternatives allow to build a trustless IBC ↔ BTC system.
We invite the community to discuss these ideas, identify potential flaws, and contribute to refining this proposal. Your insights are crucial in shaping a robust and efficient IBC solution for Bitcoin.
