Skip to content

Latest commit

 

History

History
397 lines (275 loc) · 43 KB

research-intro.md

File metadata and controls

397 lines (275 loc) · 43 KB
layout title order
page
Introduction to Bitcoin Research
4

Hello, Researcher!

Thank you for your interest in Bitcoin. This page provides an overview of Bitcoin-related research. We hope it helps you choose your research direction.

The Bitcoin community looks forward to your contributions!

  1. From Research to Development
  2. Introductory Materials
  3. Research Areas in Bitcoin
  4. Research Areas in Second-Layer Protocols

From Research to Development

Bitcoin is a fascinating and multi-faceted topic that offers challenging questions across a variety of fields of study. To make sure research results are applicable, it is important to keep in mind how the Bitcoin development process is structured.

Bitcoin must operate in an adversarial environment while remaining permissionless. Its design philosophy emphasizes security and decentralization. Therefore, Bitcoin development is conservative, and the protocol is difficult to change. This is especially true for consensus-critical code in Bitcoin Core. Other aspects of the Bitcoin Core codebase, such as P2P networking, are more open to change. The same applies to complementary protocols of the Bitcoin stack, such as the Lightning Network.

Bringing a research result to implementation is a challenging task. It is recommended to share research ideas with developers, as well as to become familiar with ongoing discussions in the community. The following resources might be helpful:

  • Bitcoin Optech issues a newsletter explaining recent changes in Bitcoin-related open-source software and offers a glossary of Bitcoin technical topics.
  • Bitcoin-dev and Lightning-dev mailing lists host discussions about the development of Bitcoin and the Lightning Network, respectively.
  • Bitcoin Transcripts is an archive of transcripts from Bitcoin-related talks.
  • Bitcoin StackExchange is a Bitcoin-focused Q&A website.
  • Bitcoin Problems provides context for some of the Bitcoin- and Lightning-related research problems.
  • Bitcoin Core PR Review Club is a weekly meeting to discuss a proposed change (a pull request, or PR) into Bitcoin Core.

Many Bitcoin-related technical conferences publish videos of talks online. Examples include:

Examples of research projects (also cited below under their respective subsections) that have led to changes in Bitcoin include the Erebus attack, other P2P-related issues that have informed various improvements, and Erlay (implementation in progress as of late 2022).

Introductory Materials

The Bitcoin whitepaper (2008) defines its mission and core design principles:

Multiple systematization-of-knowledge papers provide an overview of Bitcoin:

Books on the subject include:

While it's not strictly required to fully read those books before starting Bitcoin research, they can be helpful as points of reference.

Research Areas in Bitcoin

This section lists prior work related to Bitcoin in general. The next section focuses more specifically on Bitcoin-based second-layer protocols, such as the Lightning Network.1

Cryptography

Bitcoin uses multiple cryptographic primitives. Most relevant for the current research efforts are signatures and encryption. Ongoing research efforts are as follows.

  • Schnorr-based multi-signatures and threshold signatures. Signatures are used to authorize transactions. Two signature algorithms are available: ECDSA and Schnorr signatures. ECDSA has been used throughout Bitcoin's history. Support for Schnorr signatures, which offer privacy and scalability benefits (see BIP340), has been added in 2021. In Bitcoin, funds may be controlled by multiple keys. Spending such coins requires collaborative signature construction, which is a non-trivial task. Schemes for multi-signatures (n-of-n), as well as threshold signatures (t-of-n), have been designed. The question of how to design secure Schnorr-based signature protocols remains an active area of research.
  • Encryption in the P2P network. Currently, connections in the Bitcoin P2P network are unencrypted. This allows a network adversary to analyze metadata, tamper with connections, and easily detect the fact that the Bitcoin protocol is being used. BIP-324 addresses these concerns by adding encryption support.

Prior work includes:

P2P Network

Bitcoin uses a P2P network to broadcast transactions, blocks, and related data. Inspired by earlier data sharing P2P protocols, Bitcoin operates under unique design constraints. To allow public verifiability and establish a level playing field for miners, the network should ensure efficient information propagation even in low-bandwidth settings. At the same time, it should defend against denial-of-service and privacy attacks. The paper Survey on Cryptocurrency Networking: Context, State-of-the-Art, Challenges by Dotan et al. presents the state of the art and open problems in cryptocurrency networking.

Bitcoin's P2P protocol should have the following properties:

  • Efficiency. Data should propagate quickly to facilitate consensus and avoid providing an unfair advantage to better-connected nodes. The requirements differ for different message types. Blocks should propagate as quickly as possible; transactions should reach miners quickly, while there isn't that much urgency in propagating the IP addresses of peers.
  • Security. Bitcoin peers should minimize trust towards their peers and independently verify the data they receive. At the same time, the protocol should discourage denial-of-service attacks. This is challenging in an open network with no fixed identities. Preventing eclipse attacks, where an adversary sets up multiple nodes to fully control the flow of data between a victim node and the rest of the network, is especially important. For a review of eclipse attacks and countermeasures against them, see this document by Adam Jonas et al.
  • Privacy. Bitcoin nodes should avoid leaking private information in their P2P communication patterns. In particular, an adversary shouldn't be able to determine which node a given transaction originates from. Similarly, network topology should also remain hidden: it must be difficult to figure out whether two nodes are connected. Ideally, even the fact that someone is communicating via the Bitcoin P2P protocol should remain hidden from a network observer.

Bitcoin miners normally work in pools to receive a consistent income stream. Communication between miners and pool operators is performed using the Stratum protocol. An improved protocol called Stratum V2 is under development. Its advantages include encryption (to prevent man-in-the-middle attacks), lower bandwidth consumption, and the ability for miners to construct their own block templates (to foster decentralization).

Open questions for Bitcoin P2P include:

  • What should be the desired properties of the P2P protocol? How to formalize them?
  • What node policies ensure the quality and diversity of peers? How often should nodes rotate peers?
  • What principles should underpin the gossip protocol? How often and to whom should nodes advertise their IP addresses?

Prior work includes:

Privacy

Privacy is a critical aspect of Bitcoin. First, privacy is required to protect users from discrimination based on their behavior. Second, privacy is necessary to ensure fungibility (making any two currency units indistinguishable). Ensuring privacy in Bitcoin, while preserving its permissionless nature, is a challenging and important research task. The fundamental challenge is to ensure privacy while preserving public verifiability of all transactions. The Bitcoin Wiki Privacy page provides an overview of privacy issues.

Privacy-related attacks may be divided into P2P network analysis and transaction graph analysis.

Prior work related to analyzing P2P network traffic:

See also: Bitcoin Monitoring page (KASTEL Institute / Karlsruhe Institute of Technology) that provides longitudinal data on Bitcoin P2P network behavior and links to related research papers.

Analyzing the transaction graph is another approach to privacy attacks. One possible countermeasure is mixing, that is, creating collaborative transactions that make it difficult to track coin history. Implementing secure and user-friendly mixing protocol without a trusted third party remains a challenge (see e.g. Ghesmati et al. Usability of Cryptocurrency Wallets Providing CoinJoin Transactions). Apart from sender-receiver topology, transactions may be fingerprinted based on wallet-specific properties, such as the order of inputs and amount patterns. Graph-based deanonymization methods and countermeasures have been described in:

Open research questions include:

  • How to develop secure privacy tools for Bitcoin? How to make them appealing to regular users?
  • How to coordinate coin mixing without a designated coordinator? If the coordinator is present, how to limit its influence? How to make the coordinator accountable for misbehavior?
  • How can we use Taproot and Schnorr signatures to improve Bitcoin base-layer privacy?

Game Theory

No central authority coordinates the behavior of Bitcoin nodes. This makes game theory an important aspect of protocol design. In particular, miners must be incentivized to produce blocks and, ideally, should be rewarded proportionally for their contribution to Bitcoin's total hashpower. Moreover, miners usually form pools to share the block rewards and ensure a predictable revenue stream. The relationships between miners and pools can also be thought of as a game. Research challenges in this area include formalizing the actions of the network participants, identifying undesired deviation strategies, and coming up with ways to mitigate them.

Research questions might include:

  • Bitcoin's long-term sustainability. Will Bitcoin be economically sustainable in light of the reduction of block subsidies (that is, if miners are primarily incentivized by transaction fees)?
  • Deviant miner strategies. Can miners gain more than their fair share of block rewards by deviating from the protocol in some way?
  • Mining pools. What are the power dynamics between miners and pools? How to ensure that rewards are fairly shared among miners? Is it possible to design a decentralized mining pool?

Notable papers that consider the game-theoretic properties of Bitcoin include:

Economics

Bitcoin can also be viewed from an economic perspective. Bitcoins are exchanged for fiat currencies and other cryptocurrencies. The properties of those markets might be analyzed (see e.g. Hale et al. How Futures Trading Changed Bitcoin Prices). Moreover, actors in the Bitcoin protocol itself are part of a market for block space.

Bitcoin transactions must be included in a block to be confirmed. A block can only include a limited number of transactions, hence, block space is a scarce resource. Transaction senders bid for block space by attaching fees to transactions they broadcast. This mechanism establishes the block space market, which presents an active area of research.

Open questions include:

  • Fee strategies. When constructing transactions, wallets face a trade-off between getting a transaction promptly confirmed vs overpaying in fees. An unconfirmed transaction may be replaced (replace-by-fee, or RBF). Miners are interested in including the highest-paying transaction in their blocks. What is the optimal replacement strategy for a wallet, and how does it affect the overall dynamics of the block space market?
  • Coin selection and UTXO management. A Bitcoin transaction spends one or multiple unspent transaction outputs (UTXOs) and creates new UTXOs. How should wallets select UTXOs for a new transaction? (This problem is known as Coin selection; see also An Evaluation of Coin Selection Strategies by Mark Erhardt.) Under what conditions is it worth it to consolidate small UTXOs? (This is especially relevant for high-volume wallets.) What are the privacy implications of coin selection and consolidation strategies?
  • Block building. On the other side of the block space market are the miners who collect unconfirmed transactions into blocks in exchange for block subsidies and fees. Generally speaking, block building is an instance of the knapsack problem with dependencies (a transaction may spend an output of another unconfirmed transaction, therefore, it will only be included in a block if its parent is included). For Bitcoin miners, time is of the essence: every second spent on block template construction leads to lost revenue. There are many Bitcoin-specific considerations to this process (see e.g. Improvement on the current block building algorithm by Mark Erhardt and Clara Shikhelman). The question is therefore: how to construct a block building algorithm that reliably produces good enough solutions quickly?
  • Mining economics. Mining is a complex economic phenomenon. What factors influence miners' behavior? Under what conditions is mining profitable? (See The Economics of Bitcoin Mining, or Bitcoin in the Presence of Adversaries by Kroll et al.)
  • Bitcoin's wider economic impact. How does Bitcoin adoption influence the global economy? What role does it play in the remittance market? What are the effects of adopting Bitcoin as legal tender (as done in El Salvador)? How does Bitcoin mining impact the energy markets? (See e.g. Badea and Mungiu-Pupӑzan. The Economic and Environmental Impact of Bitcoin.)

Papers on economic analysis of Bitcoin include:

User Experience (UX)

Bitcoin aims to become universally accepted money, yet it introduces a number of novel concepts that may be hard for the general public to grasp. An important task for developers is to make Bitcoin approachable. Which aspects of the protocol should be hidden from the user, and how to present those that are not?

Prior work includes:

See also: Wallet Scrutiny, a project to check Bitcoin wallets for code reproducibility.

Research Areas in Second-Layer Protocols

This section focuses on protocols built on top of Bitcoin. Such protocols are often referred to as off-chain or second-layer (L2) protocols. They provide additional functionality and use the base layer (Bitcoin) for dispute resolution. The most prominent Bitcoin-based L2 protocol is the Lightning Network (LN). It is a payment channel network (PCN) that achieves low payment latency and high transactional throughput while accepting additional security assumptions. Other second-layer (L2) protocols are also being developed.

For a general introduction, see:

See also LN Research Community for LN datasets and inspection tools.

L2 Protocol Design

Developing and analyzing L2 protocols remains a research challenge. The general question is: how to design a high-throughput Bitcoin-based second-layer protocol that requires minimal or no modification to the base layer, imposes low resource requirements, preserves user privacy, and does not rely on a trusted third party?

L2 protocol design involves addressing trade-offs. The protocol should provide additional functionality besides what is available on the base layer without giving up too much security. Game theory plays an important role here too, as L2 networks are generally maintained by independent actors whose behavior should be properly incentivized. Another key consideration is decentralization. Even though L2 nodes may rationally prefer connecting to already well-connecting nodes ("hubs"), causing topological3 centralization, the network must remain permissionless, censorship-resistant, and privacy-preserving.

Current research and development efforts include:

  • eltoo is a new payment channel construction with a more efficient state replacement mechanism. In eltoo, nodes only store the latest channel state (whereas LN nodes store all prior states to ensure a fair dispute resolution). Eltoo relies on a yet-to-be-implemented upgrade to Bitcoin (SIGHASH_ANYPREVOUT). See: Decker et al. eltoo: A Simple Layer2 Protocol for Bitcoin.
  • Generic oracle-powered contracts allow parties to sign a contract whose resolution depends on the outcome of a real-world event as reported by a trusted oracle. See: Le Guilly et al. Bitcoin Oracle Contracts: Discreet Log Contracts in Practice.
  • Chaumian e-cash in the Bitcoin context. Another approach to scaling Bitcoin is to implement Chaumian e-cash within federations, which are communicating via the LN (see Fedimint).
  • Rollups. A rollup is a family of L2 protocols for blockchain scaling that execute transactions off-chain and verify their correctness on-chain. Research has been published on the feasibility of both major categories of rollups in Bitcoin: validity rollups and zk-rollups.

Prior work on L2 designs also includes:

  • Aumayr et al. Bitcoin-Compatible Virtual Channels adapts a payment channel construction called virtual channels to Bitcoin. A virtual channel allows two PCN nodes, under certain security assumptions, to exchange payments as if they had a direct channel, without the involvement of intermediary nodes.
  • Aumayr et al. Blitz: Secure Multi-Hop Payments Without Two-Phase Commits proposes an improved payment channel protocol that only requires one round of communication between the sender and the receiver, which is an improvement over the LN that requires two.
  • Kiayias and Thyfronitis Litos. Elmo: Recursive Virtual Payment Channels for Bitcoin introduces a Bitcoin-suitable virtual channel constructor that is recursive and supports channels with an indefinite lifetime.

Security

Second-layer protocols rely on base layer availability. In the LN, for instance, a fraudulent channel closure can be disputed within a given time window. Dispute resolution depends on whether the justice transaction is timely broadcast and confirmed.

Modern research directions include:

  • Interaction with the base layer. L2 protocols rely on the base layer for rule enforcement. How can we make such enforcement reliable? The fundamental challenge is that congestion levels cannot be reliably predicted, which enables attack vectors like transaction pinning and flood-and-loot (see below).
  • Trustless watchtowers. An LN user must monitor the Bitcoin blockchain to dispute fraud attempts. This task can be delegated to a third-party service called a watchtower. How to develop an incentive-compatible and privacy-preserving watchtower protocol? A watchtower should be accountable (get paid only if it does its job and get punished if it doesn't) while knowing as little as possible about its client. A related challenge is to enforce fair completion of in-flight payments after channel closure. See a watchtower implementation: The Eye of Satoshi (rust-teos).
  • Addressing DoS vectors, such as jamming. Jamming is a denial-of-service attack that involves initiating payments and delaying their finalization. Multiple approaches to jamming countermeasures have been discussed, including new fee and reputation schemes. How to protect the LN and other L2 protocols from DoS attacks?

Prior work includes:

Proposed watchtower schemes include:

Privacy

L2 protocols present a novel set of privacy challenges. The LN, in particular, should not reveal a user's balance, their position in the payment path, or even the existence of their channels (if they don't announce it).

Privacy-related research areas include:

  • Cross-layer privacy. Currently, LN channels are linked to their respective opening on-chain transactions. This allows for enriching existing on-chain address clustering data with LN information. With Schnorr signatures, it is possible to make LN-related transactions indistinguishable from other transactions on the base layer through signature aggregation. However, channel announcements must still commit to a scarce resource to avoid denial-of-service attacks. How can we ensure that L2 activity remains opaque from the base-layer viewpoint?
  • Multi-hop payment de-correlation with PTLCs. Point Time Locked Contracts (PTLCs) are a new type of multi-hop Schnorr-based channel locks. Currently, the LN relies on hashed time-locked contracts (HTLCs) to ensure atomicity in multi-hop payments. HTLCs along a path have the same hash. PTLC is an alternative of HTLC that avoids hop correlation. See: Malavolta et al. Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability. For a recent write-up, see: Multi-Hop Locks from Scriptless Scripts.
  • Privacy-preserving routing. Receivers in the LN currently reveal their node identity to the sender. Techniques like blinded paths aim to lift this requirement to ensure sender privacy. See also: trampoline payments. An adversary can also make educated guesses about routes by running the path-finding algorithm locally on a graph snapshot. Privacy leaks also occur through response timings (see: Rohrer and Tschorsch. Counting Down Thunder: Timing Attacks on Privacy in Payment Channel Networks). Privacy-preserving routing remains an open problem.
  • Preventing balance probing. Channel balances are not announced, but they can be easily probed, that is, estimated based on error messages. Nodes perform probing to increase the success rates of their own payments, as the uncertainty of channel balances is the leading cause of payment failures. Constant probing (sending payments that immediately fail) burdens the network. How do we reconcile payment reliability with privacy? See e.g.: Herrera-Joancomartí et al. On the Difficulty of Hiding the Balance of Lightning Network Channels.

The following papers analyze privacy challenges for the LN:

See an overview of privacy challenges and solutions in the LN by benthecarman et al.

Economics and Network topology

LN nodes open channels and deploy liquidity into the network to send or receive payments, or to earn routing fees. An open question is: how to optimally deploy liquidity in the LN to maximize fee revenue and payment reliability (or other chosen metrics)?

  • Increasing payment success rate. Many LN payment require multiple attempts to succeed, which takes time. Moreover, re-trying a payment may not be possible in certain scenarios. How to make LN payments reliable without introducing central points of failure?
  • Liquidity management. LN payments often fail because of lack of liquidity somewhere along the path. Routing nodes use liquidity management techniques such as channel rebalancing to increase payment success rates. What is the optimal liquidity management algorithm?
  • Channel partner selection. What is the optimal way for a node to choose a channel partner? Preferential attachment is a concern from a centralization standpoint: nodes have an incentive to connect to already well-connected nodes. How to find a trade-off between each node's individual motivations and the sustainability of the network as a whole?

Prior work includes:

Routing

Each payment in the LN is forwarded along a route chosen by the sender. The sender considers multiple factors, such as the network topology, channel capacities, advertised fees, and outcomes of prior payment attempts. Classical path-finding algorithms, such as the Dijkstra algorithm, are not directly applicable, as the sender can't assign edge weights (remote channels balances are generally unknown).

An open research question is developing a path selection algorithm for the LN with the following properties:

  • Efficiency. Payments should succeed after a low number of attempts (ideally, after just one attempt), while avoiding overpaying in fees. The key obstacles are the uncertainty of channel balances and the fact that some nodes along the route may be offline.
  • Being trustless. The sender should not have to delegate path-finding to a trusted third party.
  • Security. A routing mechanism should not facilitate attacks. For instance, an adversarial node should not be able to predict other nodes' routing decisions based on public data. Neither should it be possible to reliably influence route selection through strategically chosen announcements (for instance, attract payments by advertising very low fees).
  • Privacy. Route selection must not compromise users' privacy.
  • Moderate resource usage. Route selection should be feasible on resource-constrained devices in terms of memory and processing power. Currently, sending nodes store the entire public LN graph. As the network grows, path-finding on a partial or compressed graph snapshot may become necessary.

Prior work on PCN routing includes:

Footnotes

  1. There are multiple ways to classify research questions and prior work in this multi-dimensional space. One may consider the desirable properties of Bitcoin (reliability, privacy, censorship resistance), the scientific discipline under which to study it (cryptography, networking, economics), or a particular aspect or layer of the technological stack (key management, P2P networking, second-layer protocols). ↩

  2. Also, see the LN specifications (BOLTs) for a formal protocol description. ↩

  3. There are multiple metrics of centralization; evaluating their applicability in the context of the LN and similar networks is a separate research question. ↩