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[\mathcal{A}(\{d_1, d_2, ..., d_{t-1}\}) \rightarrow d] \leq \epsilon$

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:

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:

$T_{Libre}(mint) = \{dest: User_{Libre}, amount: A - fee, token: LBTC\}$

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

$fee = A \times 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) \approx \left(\frac{q}{p}\right)^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 \geq \frac{\log(\sigma)}{\log(q/p)}$

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.