Libre Chain Docs
WebsiteAppWalletCreate Account
  • The Libre Platform
    • Libre is a Bitcoin-native, decentralized lending marketplace
    • Borrow
    • Lend
    • Run A Libre Node
    • Validators
    • The Smart Contract Platform
      • Building Smart Contracts on Libre
      • Libre Developer Tools
      • Libre Testnet
      • API Docs
  • DeFi on Libre DEX
    • DeFi
    • libreDEX
    • Ordinals
    • Building on Libre
      • How to add a trading pair
  • BitcoinFi on Libre
    • Glossary
  • The LIBRE Reward Coin
    • A reward system for validators and stakers
    • Supply
    • Mint Rush
    • Spindrop
      • How to Claim the LIBRE Spindrop
      • Eligibility Requirements for the LIBRE Spindrop
  • ACCOUNTS AND WALLETS
    • LIBRE Account Names
      • Cryptographic Keys
    • Creating Multiple Accounts
    • Bitcoin Libre Wallet
    • Anchor Wallet
      • Creating a Libre MainNet Account in Anchor
      • Creating a Libre Testnet Account in Anchor
      • Getting Testnet LIBRE Coins
    • Ledger Hardware Wallet
  • EARN
    • Staking
    • Mining
    • Referrals
    • Become a Validator
    • DAO Tax
    • Libre Lightning Provider
  • Governance
    • Voting Power
    • Validator Election
    • Libre DAO
    • Libre Governance Docs
      • Libre Blockchain Operating Agreement (LBOA)
      • Block Producer Agreement
      • Block Producer Minimum Requirements
    • Libre Mainnet Multisig Gov
      • Oct 2024
      • July 2023
      • June 2023
      • April 2023
      • March 2023
      • February 2023
      • December 2022
  • Technical Details
    • Libre Core Constants
    • Mint Rush Details
    • Staking Details
    • Verifying Code Updates
      • Deployed Smart Contract Versions
  • Cross-Chain Interoperability
    • Cross-Chain Overview
    • Bridge Comparison
    • Libre CrossLink Bridge
      • Technical Whitepaper
      • Bitcoin to Libre (Peg-In Process)
      • Libre to Bitcoin (Peg Out)
    • Bitcoin Lightning Network
    • USDT / Ethereum
    • Legacy pNetwork
    • Bitcoin Audit
Powered by GitBook
On this page
  • Architecture Overview
  • MPC-TSS Implementation
  • Key Generation Protocol
  • Signing Protocol
  • Transaction Flows
  • Peg-in (BTC to Libre)
  • Peg-out (Libre to BTC)
  • Security Considerations
  • Threat Model
  • Protection Mechanisms
  • Advanced Security Properties

Was this helpful?

Edit on GitLab
  1. Cross-Chain Interoperability
  2. Libre CrossLink Bridge

Technical Whitepaper

Technical details of the Libre CrossLink bridge implementation using MPC-TSS

Architecture Overview

The Libre CrossLink bridge is built on a layered architecture that integrates with both the Bitcoin and Libre blockchains through a network of decentralized nodes. The system consists of three main components:

  1. Smart Contract Layer: The Libre smart contract maintains the canonical state of all bridge operations, eliminating inconsistencies that could arise from distributed state management.

  2. Node Network: A distributed network of bridge nodes that collectively manage the bridge operations through MPC.

  3. MPC Protocol Layer: Implements threshold signature schemes to collectively generate and manage cryptographic keys.

This architecture offers several key advantages:

  1. Single Source of Truth: The Libre smart contract maintains the canonical state of all bridge operations, eliminating inconsistencies that could arise from distributed state management.

  2. Decentralized Control: No single entity has control over user funds or bridge operations.

  3. Enhanced Security: MPC-TSS provides institutional-grade security without institutional intermediaries.

  4. Transparency: All operations are recorded on-chain and can be audited.

MPC-TSS Implementation

The CrossLink bridge uses threshold signature schemes for collectively managing cryptographic keys. For a system with $n$ participants, a $(t,n)$-threshold signature scheme allows any subset of at least $t$ participants to collaboratively compute a valid signature, while ensuring that:

  1. No participant learns the complete private key $d$

  2. Any subset of at least $t$ participants can collaboratively compute a valid signature

  3. Any subset of fewer than $t$ participants cannot derive the private key or generate valid signatures

The security of this approach is established in threshold cryptography, where the probability of an adversary $\mathcal{A}$ recovering the private key $d$ with fewer than $t$ shares is negligible:

Pr[A({d1,d2,...,dt−1})→d]≤ϵPr[\mathcal{A}(\{d_1, d_2, ..., d_{t-1}\}) \rightarrow d] \leq \epsilonPr[A({d1​,d2​,...,dt−1​})→d]≤ϵ

Where $\epsilon$ is a negligibly small value and ${d_1, d_2, ..., d_{t-1}}$ represents the compromised key shares.

Key Generation Protocol

The key generation protocol (Keygen) allows participants to jointly generate a public/private key pair without any single party having access to the complete private key. The protocol consists of three main stages:

  1. Initialization: Each party generates their own random secret and commits to it.

  2. Secret Sharing: Parties exchange encrypted shares of their secrets using Verifiable Secret Sharing (VSS).

  3. Key Derivation: Parties collectively compute the public key and their respective shares of the private key.

Signing Protocol

For ECDSA signatures, the system uses a more complex MPC protocol to calculate:

r = g^k \mod p$$$$s = k^{-1}(z + rd) \mod q

Where:

  • $g$ is the generator point

  • $k$ is a random nonce

  • $z$ is the message hash

  • $d$ is the private key

  • $p$ and $q$ are prime numbers specific to the ECDSA parameters

Transaction Flows

Peg-in (BTC to Libre)

  1. User initiates a peg-in by sending BTC to a bridge address on the Bitcoin blockchain.

  2. Bridge nodes detect the transaction and verify its validity.

  3. Once the transaction receives sufficient confirmations, nodes sign a transaction to mint equivalent tokens on Libre.

  4. The transaction $T_{BTC}(deposit)$ on Bitcoin with amount $A$ results in a transaction $T_{Libre}(mint)$ on Libre:

TLibre(mint)={dest:UserLibre,amount:A−fee,token:LBTC}T_{Libre}(mint) = \{dest: User_{Libre}, amount: A - fee, token: LBTC\}TLibre​(mint)={dest:UserLibre​,amount:A−fee,token:LBTC}

Where $fee$ is calculated based on the current fee rate:

fee=A×feeRatefee = A \times feeRatefee=A×feeRate

Peg-out (Libre to BTC)

  1. User initiates a peg-out by sending LBTC tokens to the bridge contract on Libre with the destination Bitcoin address in the memo field.

  2. Bridge contract locks the tokens and creates a pending peg-out record.

  3. Nodes detect the peg-out request and initiate the signing process.

  4. Once sufficient nodes have participated in the signing, the signed Bitcoin transaction is broadcast to the Bitcoin network.

  5. After sufficient confirmations, the peg-out is marked as complete on the Libre contract.

Security Considerations

Threat Model

The security design of Libre CrossLink considers several threat vectors:

  1. Node Compromise: The system remains secure as long as fewer than $t$ nodes are compromised.

  2. Network Partitioning: The bridge can withstand temporary network partitioning.

  3. Blockchain Reorganizations: The bridge handles potential chain reorganizations on both networks.

  4. Front-running Attacks: Transaction ordering is protected through the Libre contract.

  5. Denial of Service: The bridge implements rate limiting and other protections.

Protection Mechanisms

  1. Threshold Security: Requires $t$ out of $n$ nodes to cooperate for any action.

  2. Validation Checks: Multiple validation steps for transactions on both blockchains.

  3. Confirmation Requirements: Enforces minimum confirmation requirements for Bitcoin transactions.

  4. Rate Limiting: Prevents excessive transaction volume that could strain the system.

  5. Transaction Batching: Optimizes cost efficiency by batching multiple transactions.

  6. Segregated Key Management: Maintains separate key shares for each user vault, ensuring that compromise of one vault doesn't affect others.

The probability that a transaction is irreversible after $k$ confirmations on the Bitcoin blockchain can be approximated by:

P(reversal)≈(qp)kP(reversal) \approx \left(\frac{q}{p}\right)^kP(reversal)≈(pq​)k

Where:

  • $q$ is the attacker's hash power

  • $p$ is the honest network's hash power

  • $p + q = 1$ (total network hash power)

For a security parameter $\sigma$ and an attacker controlling fraction $q$ of the hash power, the required confirmations $k$ to achieve security is:

k≥log⁡(σ)log⁡(q/p)k \geq \frac{\log(\sigma)}{\log(q/p)}k≥log(q/p)log(σ)​

Advanced Security Properties

The CrossLink bridge implements several advanced security measures:

  1. Proactive Security: Periodic key resharing to mitigate the risk of gradual key share leakage

  2. Verifiable Computation: All nodes can verify the correctness of partial signatures

  3. Accountability: All actions are recorded on-chain, providing accountability

  4. Asynchronous Operation: The system can progress even when some nodes are temporarily unavailable

These measures ensure that the bridge maintains its security properties even in adversarial conditions.

PreviousLibre CrossLink BridgeNextBitcoin to Libre (Peg-In Process)

Last updated 1 month ago

Was this helpful?