Expand description
BTC-Relay Pallet
Based on the specification.
This pallet implements a Bitcoin light client to store and verify block headers in accordance with SPV assumptions - i.e. longest chain.
Unless otherwise stated, the primary source of truth for code contained herein is the Bitcoin Core repository, though implementation details may vary.
Overview
The BTC-Relay pallet provides functions for:
- Initializing and updating the relay.
- Transaction inclusion verification.
- Transaction validation.
Terminology
-
Bitcoin Confirmations: The minimum number of Bitcoin confirmations a Bitcoin block header must have to be seen as included in the main chain.
-
Parachain Confirmations: The minimum number of Parachain confirmations a Bitcoin block header must have to be usable in transaction inclusion verification.
Re-exports
pub use bitcoin;
pub use types::OpReturnPaymentData;
pub use types::RichBlockHeader;
pub use pallet::*;
Modules
- The
pallet
module in each FRAME pallet hosts the most important items needed to construct this pallet.
Structs
- Compressed ECDSA (secp256k1 curve) Public Key
- We also check the coinbase proof in order to defend against the ‘leaf-node weakness’. See https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ .
Enums
- A Bitcoin address is a serialized identifier that represents the destination for a payment. Address prefixes are used to indicate the network as well as the format. Since the Parachain follows SPV assumptions we do not need to know which network a payment is included in.
Constants
- Accepted maximum number of transaction outputs for validation of redeem or replace See: https://spec.interlay.io/intro/accepted-format.html#accepted-bitcoin-transaction-format
- Difficulty Adjustment Interval
- Main chain id
- Target Spacing: 10 minutes (600 seconds)
- Unrounded Maximum Target 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Traits
- Weight functions needed for btc_relay.