Bitcoin Core development and transaction relay policy

We’d like to share our view on the relationship between Bitcoin Core development and transaction relaypolicy on the network. Bitcoin is a network that is defined by its users, who have ultimate freedom in choosing whatsoftware they use (fully-validating or not) and implementing whatever policies they desire. BitcoinCore contributors are not in a position to mandate what those are. One way this is reflected is byour long-running practice of avoiding auto-updating in the software. This means that no entity canunilaterally push out changes to Bitcoin Core users: changes must be made by users choosing toadopt new software releases themselves, or if they so desire, different software. Being free to runany software is the network’s primary safeguard against coercion. As Bitcoin Core developers we also consider it our responsibility to make our software work asefficiently and reliably as possible for its purpose, namely validating and relaying blocks andtransactions in the Bitcoin peer-to-peer network, so that Bitcoin succeeds as a decentralized digitalcurrency. With regards to transaction relay, this may include adding policies for denial of service (DoS)protection and fee assessment, but not blocking relay of transactions that have sustained economicdemand and reliably make it into blocks. The goals of transaction relay include: predicting what transactions will be mined (for example for fee estimation or fee bumping, but itis also the basis for many DoS protection strategies inside of node software); speeding up block propagation for the transactions we expect to be mined. Reduced latency helpsprevent large miners from gaining unfair advantages; helping miners learn about fee-paying transactions (so they do not need to rely on out-of-bandtransaction submission schemes that undermine mining decentralization). Knowingly refusing to relay transactions that miners would include in blocks anyway forces users intoalternate communication channels, undermining the above goals. It is the case that transaction acceptance rules have been used effectively in the past todiscourage the development of use cases that used block space inefficiently while doing so was verycheap. However this can only be effective while both users and miners are satisfied with whateveralternatives exist. When that is no longer the case, and an economically viable use case developsthat would conflict with policy rules, users and miners can directly collaborate to avoid anyexternal attempt to impose restrictions on their activities. In fact, the ability to do preciselythat is an important aspect of Bitcoin’s censorship resistance, and other node software withpreferential peering has also shown that circumventing filters of the vast majority of the nodesis relatively easy. Given that, we believe it is better for Bitcoin node software to aim to have arealistic idea of what will end up in the next block, rather than attempting to intervene betweenconsenting transaction creators and miners in order to discourage activity that is largely harmlessat a technical level. This is not endorsing or condoning non-financial data usage, but acceptingthat as a censorship-resistant system, Bitcoin can and will be used for use cases not everyoneagrees on. While we recognize that this view isn’t held universally by all users and developers, it is oursincere belief that it is in the best interest of Bitcoin and its users, and we hope our users agree.We will continue to apply our best judgment as developers in aligning transaction acceptance ruleswith Bitcoin’s long-term health and miners’ rational self-interest, including specifictechnical reasons such as upgrade safety, efficient block building, and node DoS attacks. Signed, (List of contributors who support this letter) Andrew Toth Antoine Poinsot Anthony Towns Ava Chow b10c Bruno Garcia David Gumberg fjahr Gloria Zhao Gregory Sanders hodlinator ismaelsadeeq Josie Baker kevkevinpal l0rinc Marco De Leon Martin Zumsande Matthew Zipkin Michael Ford Murch Niklas Gögge pablomartin4btc Pieter Wuille Pol Espinasa Sebastian Falbesoner Sergi Delgado Stephan Vuylsteke TheCharlatan Vasil Dimov Will Clark w0xlt