The Chaincode Labs Bitcoin Open Source Software (BOSS) challenge is considering to have participants revisit, re-implement, and validate existing research papers (using LLMs) as part of their exercises. If you know about a paper or written one yourself that you want people to consider, feel free to post it below.
The Bitcoin network relies on peer-to-peer broadcast to distribute pending transactions and confirmed blocks. The topology over which this broadcast is distributed affects which nodes have advantages and whether some attacks are feasible. As such, it is particularly important to understand not just which nodes participate in the Bitcoin network, but how they are connected. In this paper, we introduce AddressProbe, a technique that discovers peer-to-peer links in Bitcoin, and apply this to the live topology. To support AddressProbe and other tools, we develop CoinScope, an infrastructure to manage short, but large-scale experiments in Bitcoin. We analyze the measured topology to discover both high-degree nodes and a well connected giant component. Yet, efficient propagation over the Bitcoin backbone does not necessarily result in a transaction being accepted into the block chain. We introduce a “decloaking” method to find influential nodes in the topology that are well connected to a mining pool. Our results find that in contrast to Bitcoin’s idealized vision of spreading mining responsibility to each node, mining pools are prevalent and hidden: roughly 2% of the (influential) nodes represent three quarters of the mining power.
Bitcoin relies on a peer-to-peer overlay network to broadcast transactions and blocks. From the viewpoint of network measurement, we would like to observe this topology so we can characterize its performance, fairness and robustness. However, this is difficult because Bitcoin is deliberately designed to hide its topology from onlookers. Knowledge of the topology is not in itself a vulnerability, although it could conceivably help an attacker performing targeted eclipse attacks or to deanonymize transaction senders.
In this paper we present TxProbe, a novel technique for reconstructing the Bitcoin network topology. TxProbe makes use of peculiarities in how Bitcoin processes out of order, or “orphaned” transactions. We conducted experiments on Bitcoin testnet that suggest our technique reconstructs topology with precision and recall surpassing 90%. We also used TxProbe to take a snapshot of the Bitcoin testnet in just a few hours. TxProbe may be useful for future measurement campaigns of Bitcoin or other cryptocurrency networks.
Recent work has demonstrated significant anonymity vulnerabilities in Bitcoin’s networking stack. In particular, the current mechanism for broadcasting Bitcoin transactions allows third-party observers to link transactions to the IP addresses that originated them. This lays the groundwork for low-cost, large-scale deanonymization attacks. In this work, we present Dandelion++, a first-principles defense against large-scale deanonymization attacks with near-optimal information-theoretic guarantees. Dandelion++ builds upon a recent proposal called Dandelion that exhibited similar goals. However, in this paper, we highlight simplifying assumptions made in Dandelion, and show how they can lead to serious deanonymization attacks when violated. In contrast, Dandelion++ defends against stronger adversaries that are allowed to disobey protocol. Dandelion++ is lightweight, scalable, and completely interoperable with the existing Bitcoin network. We evaluate it through experiments on Bitcoin’s mainnet (i.e., the live Bitcoin network) to demonstrate its interoperability and low broadcast latency overhead.
PR #13947 failed mainly because no one found a safe way to handle the hard cases. MarcoFalke opened it in August 2018 as a three-step implementation of BIP 156 (Dandelion transaction relay), and early on he noted it was completely untested and still needed tests and wallet integration. The core design problem surfaced right away. sipa pointed out there was no “stempool,” so Dandelion transactions that depend on other Dandelion transactions would fail mempool acceptance. sdaftuar added that the right behavior for transaction chains and replacement transactions was still unresolved, along with how to prevent DoS attacks during stem routing. He also argued that one shared stempool could leak routing information to an attacker, while a separate stempool per inbound peer would be costly. Reviewers also flagged smaller issues: sending transactions directly instead of queuing them could fill send buffers and delay block relay, and the commits lacked documentation that tied the code to the BIP, which made a privacy-critical change hard to verify. The PR was dropped from the 0.18.0 milestone in December 2018 and closed in July 2019. In closing it, MarcoFalke explained that supporting all wallet behavior (such as CPFP and RBF) without opening DoS vectors was non-trivial, and suggested a simpler “Dandelion one-hop” approach as a better first step. Years later, ajtowns also found that the code roughly doubled the chance of the next node “fluffing” a transaction (about 19% instead of 10%).
I did some design work on what I think is an implementable approach for this: basically put transactions from inbounds into a stempool, and transactions from outbounds into the mempool; for mempool relay immediately to everyone as now; for stempool have a delay queue: at random intervals, relay to each outbound, then once you’ve relayed to each outbound, add to mempool and relay to any/all inbounds (triggering the global fluff step, more or less).
Would be good to have a theoretical analysis / simulation of that approach (the delay intervals vs number of outbounds changes the effectiveness, eg) before going further on implementation stuff, which is still tricky.
Temporary blockchain forks are part of the regular consensus process in permissionless blockchains such as Bitcoin. As forks can be caused by numerous factors such as latency and miner behavior, their analysis provides insights into these factors, which are otherwise unknown. In this paper we provide an empirical analysis of the announcement and propagation of blocks that led to forks of the Bitcoin blockchain. By analyzing the time differences in the publication of competing blocks, we show that the block propagation delay between miners can be of similar order as the block propagation delay of the average Bitcoin peer. Furthermore, we show that the probability of a block to become part of the main chain increases roughly linearly in the time the block has been published before the competing block. Additionally, we show that the observed frequency of short block intervals between two consecutive blocks mined by the same miner after a fork is conspicuously large. While selfish mining can be a cause for this observation, other causes are also possible. Finally, we show that not only the time difference of the publication of competing blocks but also their propagation speeds vary greatly.
b10c · 
Anthony Towns · 
Matthias Grundmann ·