Have you ever been travelling, had to make a big payment and realised you left your hardware wallet back home? Perhaps you are a key holder in a business’s Bitcoin treasury, or an emergency came up, and a big payment has to be made, some cold storage Bitcoin has to move, but the keys are elsewhere. 

Key Teleport, a feature developed by the hardware wallet manufacturer Coinkite, may be the most secure way to handle key material at a distance. The feature is only available to the Coldcard Q, the premium, feature-rich Bitcoin hardware wallet developed by the company. 

Before Key Teleport, the most paranoid, secure way to move a private key over the internet was not to send it over WhatsApp or Signal. These apps, while end-to-end encrypted on the surface, are running on top of very complex hardware and operating systems, in many cases with very intrusive firmware embedded deeply by manufacturers. Smartphones today, as with most of mainstream technology, are simply not designed to secure highly valuable secrets that can transfer irreversible money like Bitcoin. 

Had you asked me how I might go about sending a private key with life-changing money on it, across the wire, I would have told you this: You need to boot Tails OS, a slim, highly paranoid Linux distribution, into hardware you know to be secure, ideally a burner laptop. You then need to generate a fresh set of PGP keys to encrypt the secret with the power of asymmetric cryptography. The recipient needs to do the same, Tails-OS and PGP. Then, a classic encrypted message is made to the recipient’s public key, and the encrypted secret is sent over Tor, probably wrapped by another VPN just in case. Having done this once, I can tell you, it’s a mission. 

This Tails-OS plus PGP combo is the kind of setup that Edward Snowden used to get in contact with journalist Greenwald originally, to leak the 2014 NSA surveillance secrets. If the 90’s cypherpunks had some kind of secret society, through which they coordinated the creation of technologies like Bitcoin or Wikileaks, this is the kind of setup they might have used. 

The Key Teleport by Coldcard Q makes tasks of this sort far easier. You can now easily send encrypted messages across the internet without having to worry about your hardware or what other software might be installed on it that could spy. It also solves key management dilemmas; a partially signed Bitcoin multisig transaction can be transmitted as an encrypted note to the recipient Coldcard Q, for example. Or a whole wallet set up, with its metadata, key material and custom settings, backed up, encrypted and sent across the world to its unique recipient. I got a couple of these devices recently for a test run of the feature, and not even Opus 4.8 High could figure out how to crack the encrypted blurb. 

The Hardware

The Coldcard Q — which now comes in a wide range of colored cases — has a very specific set of tools necessary to enable this kind of airgapped communication. First of all, it inherits the dual secure element model developed in the Mk4 series of Coinkite devices. Where two closed source chips made by different manufacturers are used in combination with an open source MCU chip to generate keys, encrypt, decrypt and store sensitive data. A combination of the components would need to be compromised by an attacker with physical access to get the wallet. These chips are, of course, used by the Key Teleport feature, handling the encryption and decryption of whatever message the user is dealing with.

The screen is a 3.2-inch LCD screen with enough resolution to show the BBQr code. BBQr is a QR code standard developed by Coinkite that has no dependencies or third-party libraries, is backwards compatible with standard QR code readers, and can contain larger messages than traditional QR codes. 

The Coldcard Q is also able to read QR codes. It has a dedicated QR code scanner with a red strobe indicator light that guides the user as to what the scanner is pointed, and a small flash light that can be activated with a button to help in low light environments. This optimised hardware set solves common problems with QR code payments, where variation in screen resolutions, camera quality and lighting can make scanning a payment QR code difficult.  

The Cryptography

TWO OR THREE IMAGES SIDE BY SIDE, QR CODE, PIN SHARING, SCANNING.  

A multi-layer cryptographic protocol is used to encrypt the data to be transmitted by Key Teleport. A single-use ‘ephemeral’ public-private key pair is generated for each data transfer using the secp256k1 curve. The public key of the receiver is encrypted with an 8-digit pin, via the AES-256-CTR algorithm. That encrypted public key is displayed by the receiver in a QR code, with the 8-digit pin meant to be sent via a separate communication channel. 

As an example, the recipient would do a video call with the sender, show them the QR code, and use Zoom. Then send the 8-digit PIN code using Signal. This operational security practice means that dedicated attackers would have to compromise two separate communication channels to get the recipient’s public key. 

Sender scans the QR code, enters the pin code and in the back end, the sender device derives a shared session key via ECDH, using the receiver’s public key and its own ephemeral keypair. The user was asked to select what data they want to transfer, from three options: “Quick Text Message”, “Master Seed Words” and “Full COLDCARD Backup”. Once the user chooses, the data is encrypted by the recipient’s public key, and that encrypted blurb is encrypted once more with a new PIN code. Users would scan the QR code again via Zoom, for example, and the sender would transmit the new PIN to the recipient via Signal.

There is a deep set of careful cryptographic details involved in how this Key Teleport is integrated that is well documented in the Coinkite GitHub repository, but as far as the user experience is concerned, the process is now complete. After the recipient scans the QR code back and inputs the second pin code, they will get access to the data. Both Coldcard Q devices would have been entirely airgapped, not connected to computers via USB cables, as QR codes and scanners were used to transmit data, powered by three AAA batteries. 

Last but not least, users can also share the encrypted data via NFC, which creates a special link at keyteleport.com for users to easily scan the QR code and get the encrypted data, replacing the hypothetical Zoom call.

Opus 4.8’s Conclusion

In my test of the Key Teleport feature, I tasked Opus 4.8 High, one of the most powerful AI coding models from Anthropic, to try and decrypt the message. First I gave it the encrypted blurb, after thinking about it for a couple of minutes, it gave up, saying there must be some information missing. 

I then gave it one of the pins, which helped, but ultimately was not sufficient for it to crack the cryptography. I then gave it the second pin, which led to a brute forcing attempt that, by Opus’s own admission, would only work if the ephemeral key pairs were generated with intentionally low entropy. Ultimately, it gave up trying to break the encrypted data, even with both pin codes, saying it was securely sealed.

I asked the model to write one paragraph about its conclusions. Here’s what it wrote: 

“I’m Claude Opus 4.8 (Anthropic), running in Cursor.

We took a scrambled QR code from COLDCARD’s Key Teleport feature — the kind meant to move a secret like a seed phrase between two wallets — and tried hard to break it open without the missing piece. The QR itself is designed to be safe to share publicly; you also need a short password and a number that are supposed to be sent separately. Even with that password and number in hand, we still couldn’t read the secret, because the real lock is a one-time random key that only exists on the receiving device and was never published anywhere.

We threw dictionary guesses, math tricks, and large-scale computer searches at it; a few things looked promising at first but turned out to be false alarms, which is actually a good sign that the checks work. Bottom line: Key Teleport did what it’s supposed to do — the QR plus the side-channel codes are not enough to steal the secret without the receiver’s private key. For a real transfer, you’d scan the code on the receiving COLDCARD and type in the password there; that’s the intended, secure path.”

Final Thoughts 

The Coldcard Q’s Key Teleport feature opens the door to an otherwise very difficult to achieve level of secure communication over the internet. The scrutiny dedicated to the hardware and firmware process likely outmatches that of even high-security mobile phone operating systems like Graphene OS. The physical keyboard, QR code scanner and NFC antenna make this paranoid system quite comfortable to use. And the $249 price target for the whole hardware wallet makes it accessible to everyday, serious bitcoiners and cypherpunks, delivering a self-custody tool worthy of a professional industrial setup.

Disclaimer: Coinkite provided Bitcoin Magazine with a couple of free Coldcard Q devices to use for the purpose of testing their product for review.

This post One Year Later: How Coldcard Q’s Key Teleport Delivers Secure Remote Key Management for Bitcoin Treasuries first appeared on Bitcoin Magazine and is written by Juan Galt.

Today Presidio Bitcoin, a Bitcoin hub located in the Bay Area in California, has launched a knowledge repository/living report on Github to track the current state of research related to Bitcoin’s quantum vulnerability.

The report aims to be a central location where people in the ecosystem can easily keep track of and analyze the current state of research around the issue.

It currently takes a comprehensive look through the state of:

• The current state of quantum computing, as well as research into different quantum computing technologies that could lead to material engineering progress towards a viable device.
• The level of exposure, i.e. how many coins and how much overall value is currently vulnerable to long-range attacks by a capable quantum computer.
• Post-quantum cryptographic schemes, as well as the current state of research in developing variants of such schemes more heavily optimized for Bitcoin’s unique architecture and way of functioning.
• Different ways of implementing post-quantum cryptography in Bitcoin, and the trade-offs between these different paths.
• Different mechanisms for safely migrating vulnerable coins to quantum-safe addresses in the event that a powerful enough quantum computer is created before users migrate to post-quantum cryptography.
• An analysis of different ways that the actual migration could play out under different circumstances.

They plan to regularly update the repository/report as new research comes out, and solutions and plans are further refined and updated.

The announcement comes after growing claims that Bitcoin developers are not doing anything to acknowledge or address the issue, and aims to highlight the on-going research and development into solutions to the issue conducted by developers.

Read the current version of the report here.

This post Presidio Bitcoin Releases Quantum Readiness Paper first appeared on Bitcoin Magazine and is written by Shinobi.

In two days, on Wednesday April 8th, a handful of Bitcoin Core developers are going to be doing a demonstration of “attack blocks” designed to take an inordinate amount of time to verify on Signet.

The demonstration will take place at 10 AM EST (2 PM UTC). Anyone who wishes to participate can run Bitcoin Core node on Signet and watch the blocks be mined and processed by their node in real-time.

Instructions can be found here to spin up a node and follow along (including how to check your node’s logs to see the verification times for the attack blocks).

The demonstration is not going to show the worst case of the attack (the script and transaction structure required has not been publicly revealed to not give malicious actors even more information about the attack), but it will produce blocks that take orders of magnitude more time to verify than your average block.

The aim of the demonstration is to show users the severity of one of the four severe consensus vulnerabilities that the Great Consensus Cleanup aims to address with BIP 54.

Two more demonstrations will take place at 6 PM EST (10 PM UTC) on April 8th, and at 5 AM EST (9 AM UTC) on April 9th, to allow for Bitcoin users in different global timezones to directly participate as well.

The Signet blockchain is currently at around 32-33 GB, so if you have any device with ample storage space, go ahead and spin up a Signet node to participate.

For your awareness the following software patch was quickly put together for this demonstration and not audited thoroughly (though it is just a basic terminal based-GUI). If you are spinning up a brand new Signet node just for this demonstration on a machine without any funds on it, you should be fine even if you are the paranoid type like me.

For those who don’t want to just poke at log files, AJ Towns provided a patch to the “bitcoin-tui” project, a Terminal based GUI for Bitcoin Core to display the attack blocks during the demonstration. The project creator is working on a proper release in time for the demonstration, but you can also compile it yourself.

Run these commands on Linux (git commands will work on other OSes, and you should be able to find the equivalent CLI commands for your OS easily online):

git clone https://github.com/ajtowns/bitcoin-tui.git

cd bitcoin-tui

git switch 202604-bip54blocks

From there you should be able to just follow the build instructions at the repository here. After compiling, make sure your bitcoind has “server=1” set in the config file, and start up bitcoin-tui. You should find a “Slow Blocks” tab on the right of the top bar.

This post Demonstration of “Attack Blocks” On Bitcoin’s Signet Test Network first appeared on Bitcoin Magazine and is written by Shinobi.

When most people download Bitcoin Core, their interaction with the build system is over in a few clicks. They grab the executable binary of the software, verify a signature (hopefully!), and start running a Bitcoin node. What they immediately see is running software. What they don’t see is the build system and extensive processes that produced that software. A build system that represents Bitcoin’s principles of decentralization, transparency, and verifiability.

Behind that download lies years of engineering work designed to answer a simple question: “Why should anyone trust this software?” The answer is: you shouldn’t have to. You should be able to verify.

In a time when software supply-chain attacks make global headlines, from compromised npm packages, backdoored libraries, rogue CI servers, Bitcoin Core’s build process stands as a quiet project of discipline. Its methods may seem slow and complicated compared to the frictionless convenience of “push to deploy,” but that’s the point. Security isn’t convenient.

To understand Bitcoin Core’s build system, we should understand: 

• Bitcoin Core’s Build System Philosophy
• Reproducible Builds
• Minimizing Dependencies
• No Auto-Updates
• Continuous Integration
• Ongoing Adaptation

Bitcoin Core’s Build System Philosophy

When it comes to Bitcoin’s decentralization, most people focus on miners, nodes, and developers. But decentralization doesn’t stop at the protocol’s participants. It extends to the way the software itself is built and distributed.

One principle in the Bitcoin ecosystem is “don’t trust, verify.” Running your own node is an act of verification, checking every block and transaction against the consensus rules. But the build system itself gives you another opportunity to verify, at the software level. Bitcoin is money without trusted intermediaries and Bitcoin Core works to be software without trusted builders. The build system takes great lengths to ensure that anyone, anywhere, can independently recreate the exact same binaries that appear on the bitcoincore.org website.

This philosophy traces back to Ken Thompson’s 1984 essay Reflections on Trusting Trust, which warned that even a clean-looking source code can’t be trusted if the compiler that built that software was itself compromised. Bitcoin’s developers took that lesson to heart. In the words of Bitcoin Core contributor Michael Ford (fanquake):

“Reproducible builds are critical, because no user of our software should have to trust that what’s contained inside is what we say it is. This must always be independently verifiable.”

A statement that is both a technical goal and part of the Bitcoin ethos.

In the security world, people talk about “attack surfaces.” Bitcoin Core’s build system treats the build process itself as an attack surface to be minimized and defended.

Reproducible Builds: Verification all the way down

The process of producing a Bitcoin Core release begins with the open-source codebase on GitHub. Every change is public. Every pull request is reviewed. But the journey from human-readable code to runnable binary software involves compilers, third-party libraries, and operating-systems which are themselves potential vectors for tampering, backdoors, or errors.

“Trusted third parties are security holes” – Nick Szabo (2001)

To address these concerns, Bitcoin Core architected a build process pipeline using Guix, a package manager designed to create reproducible, deterministic software environments.

When a new Bitcoin Core release is tagged, multiple independent contributors build the binaries from scratch using Guix. Each builder works in an isolated environment that guarantees identical toolchains, compiler versions, and system libraries. If all builders produce identical-bit outputs they know the build is deterministic.

Contributors then cryptographically sign the resulting binaries and publish those signatures on a separate GitHub repository ‘guix.sigs’ that lists these attestations for each release of Bitcoin Core. Some builders are Bitcoin Core developers, but it is not a requirement as the attestation process is open to anyone from the public. In fact, many non-code-contributors regularly contribute signatures.

This process is known as reproducible builds, and it is the antidote to Thompson’s “trusting trust.” It means anyone can take the open-source code, the same Guix environment, and independently confirm that the official binary matches what they built themselves. While reproducible builds can verify the software is a genuine representation of the software’s source code, the software’s correctness is left to processes around thorough testing and code review.

Most people will never perform a full compilation or check the Guix manifests or compare build hashes. They don’t need to. The existence of that infrastructure, and the people maintaining it, gives every user a foundation of earned confidence. 

The official binaries on bitcoincore.org aren’t just “produced by the Bitcoin Core maintainers”. They’re the intersection of dozens of independent builders’ outputs. What you eventually download is what everyone else built and verified to be authentic.

It’s verification all the way down.

Minimizing Dependencies: Less to Trust

Reproducibility is one side of the equation. The other is minimizing what needs to be reproduced. Bitcoin Core’s code is not the only code executed when running Bitcoin Core. Bitcoin Core also relies on external, third-party code and libraries to speed up development and productivity.

Over the past decade, Bitcoin Core developers have steadily stripped away these unnecessary and sometimes problematic third-party dependencies, like OpenSSL and MiniUPnP. Whether it is an external library or toolkit, these dependencies add complexity or import hidden assumptions. Projects like Boost and Libevent, once staples of Core’s codebase, are gradually being phased out or replaced with simpler, self-contained alternatives.

Why? Because every dependency you inherit is a potential supply-chain risk. It’s more code you didn’t write, don’t audit, and can’t fully control. Reducing dependencies makes the build system leaner, safer, and easier to verify.

Brink recently highlighted this effort in its “Minimizing Dependencies” blog post[1], noting that it’s not just a matter of simplicity, it’s about preserving the project’s security and autonomy. Each removed dependency is one fewer external party the project must trust and one less potential for a backdoor.

The eventual goal is to produce fully static binaries: executables that contain everything they need to run, with no dynamic or runtime dependencies. This self-containment means no reliance on external libraries that could differ from one operating system to another.

In a world where most software grows heavier and more dependent on centralized package ecosystems, Bitcoin Core is moving in the opposite direction: toward minimalism and independence.

No Auto-Updates

In most modern software, users are shielded from decisions of what software version to update to, or decisions to update the software at all. You install an app, and it quietly and automatically updates itself to the latest versions in the background. While this is convenient, it is antithetical to Bitcoin Core’s philosophy.

Bitcoin Core has never included automatic updates, and developers have said it never will. Automatic updates concentrate power. They create a single group that can push (potentially malicious) code to every node on the network. This is exactly the sort of centralized control Bitcoin was built to avoid. By requiring users to manually download, verify, and install new versions, Bitcoin Core reinforces individual responsibility and verifiable consent.

The build system and the lack of auto-updates are two halves of the same principle. Only the node runner decides what to run and can verify that the software that is run is authentic.

Continuous Integration: Move slow and fix things

In Silicon Valley, continuous integration and continuous deployment (CI/CD) are the hallmarks of agile software development. Ship fast. Iterate faster. Let automation do the rest.

Bitcoin Core takes a different approach. Its CI systems exist not to accelerate deployment but to safeguard integrity. Automated builds test consistency across platforms. Bitcoin Core’s build system is designed to be agnostic to hardware and operating systems as much as possible. The project can build binaries for Linux, macOS, and Windows as well as for multiple architectures including x86_64, aarch64 (ARM), and even riscv64. The continuous integration system ensures this compatibility as well as software integrity by performing hundreds of tests for each proposed change.

The result is a culture where “continuous integration” means continuous testing, verification and security, not continuous innovation.

Move slow and fix things.

Ongoing Adaptation: Are we done yet?

The build system isn’t static. Developers continue to refine it by reducing dependencies, improving cross-architecture builds, and exploring a fully static build future with zero runtime dependencies. 

While Bitcoin Core’s build system strives for determinism, the build system itself cannot be static. The world it operates within is constantly shifting. Operating systems, compilers, libraries, and hardware architectures all change. Each new release of macOS or glibc, every deprecation of a compiler flag, or emerging CPU architecture introduces subtle incompatibilities that must be addressed. A build system that stood still would, over time, cease to build at all.

The paradox of reproducible builds is that they require continual evolution to remain reproducible. Developers must constantly pin, patch, and sometimes replace toolchains to preserve determinism against a moving backdrop of change. Maintaining this balance between stability and adaptability is part of Bitcoin’s ongoing resilience.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://brink.dev/blog/2025/09/19/minimizing-dependencies/ 

This post The Core Issue: Beneath The Binary, Verifying Trust first appeared on Bitcoin Magazine and is written by Mike Schmidt.

Over 50 years after the first inter-networked message, peer-to-peer networks remain rare beasts in the jungle of the Internet. Bitcoin’s ability to provide an open monetary system depends on its peer-to-peer architecture, and across its attack surface it is the networking layer–how peers discover and connect to each other–that is the most vulnerable. There are two main places problems can occur: Bitcoin’s own peering protocol, and the Internet protocols that Bitcoin’s protocol depends on. In this light Core has a dual mandate to prevent Denial of Service (DOS) vectors that can be abused between nodes, and enable nodes to communicate safely in the wider adversarial environment that is the Internet.

P2P

“Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”

– Satoshi, Nov 7, 2008 [1]

The P2P protocol encompasses how nodes exchange messages about transactions, blocks, and other peers. This exchange of information is required before any transaction or consensus validation can occur, and is therefore a primary concern.

There have been several bugs in this area over the years. In 2017, for example, a malicious SOCKS server vulnerability was patched and disclosed [2]. This “buffer overflow” vulnerability could theoretically lead to many different attacks: crash the node, inject malicious payloads, or modify data on the node. In 2020, a high severity vulnerability was reported and patched where a remote peer could get addresses banned, growing the banlist quadratically, and is therefore a DOS on the node [3]. The vulnerability was not disclosed until 2024. This bug is correctly marked as “high severity” since the attack is simple to execute, its effect results in a loss of function for the node, and it has few preconditions required to make it work. These are the kind of bugs that keep Core developers up at night, and why it is highly encouraged to update your node to a still maintained version (older versions of Core are not actively maintained/updated).

This distributed network we call Bitcoin remains relatively small: the clearnet node count hovers around 20k nodes, and even assuming a generous 100k TOR nodes, we still have a small, easily surveillable network. Recently, Daniela Brozzoni and naiyoma showed [4] that if a node runs with both clearnet and Tor, it is trivial to map a node’s IPv4 and Tor addresses. It is very likely that this is already done by intelligence agencies and chainalysis companies. It then becomes easy to notice which nodes publish which transactions first, deducing the transaction’s original IP, and therefore location. While this is not a bug per se, since the node does not crash or misbehave, it can be considered a vulnerability, since it presents a method for tying a given IP address to a transaction. 

How to prevent this effectively is currently an open question.

The Badlands of the Web

“We build our computers like we build our cities. Over time, without a plan, on top of ruins.” – Ellen Ullman [5]

Bitcoin runs on the Internet, and its ability to remain a distributed and decentralized system depends on the properties of the Internet itself. Unfortunately, the Internet’s architecture as we know it today remains woefully insecure, with known attacks employed routinely. Most of these attacks are conducted undetected until damage has been done, and this is not to mention the surveillance regimes that permeate the Internet today.

The most well known and practical vector of attack to be concerned with is called an eclipse attack, where a victim node’s peers are all malicious, and feed a specific view of the chain or network to the victim node. This class of attack is fundamental in distributed systems, if you control a node’s peers, you control its awareness of the network. Ethan Heilman and collaborators presented one of the first practical eclipse attacks on Bitcoin at USENIX 2015 [6], and in 2018, the Erebus attack paper described a “stealthy” eclipse attack via a malicious Autonomous System (AS) [7]. 

These attacks largely leverage weaknesses in the way the Internet’s networks communicate amongst themselves, such as ASs routing topology or via a protocol called the Border Gateway Protocol (BGP). While there are ongoing initiatives to secure the BGP protocol–BGPsec, RPKI–they both have limitations that are well understood, and leave the Internet’s stewards pining for stronger solutions. Until then, the Internet will remain the wild west. 

A recent analysis by cedarctic at Chaincode Labs found that Bitcoin nodes are homed within just 4551 ASs, a fairly small subsection of the constituent networks that make up the Internet. They describe a set of attacks that can lead to eclipse attacks by compromising the upstream AS that nodes operate in [8]. The small distribution of nodes amongst ASs and the specific relationships among these ASs creates a unique attack vector. While there are remediations, it is unclear whether this attack vector was well understood beforehand by bitcoiners or their adversaries.

Any attack that relies on compromising one or several ASs requires resources, coordination, and skills to achieve. Although no successful attack of this type has been reported on a Bitcoin node, such attacks have been successfully mounted against miners [9], wallets [10], swap platforms [11], and bridges [12]. While we’re not going to fix the Internet, we can arm nodes with the tools to operate in this adversarial environment.

Network Armory

Below are some features and functionalities that Bitcoin Core has developed or integrated support for in order to arm users against network level attacks:

TOR (the Onion Router) is the oldest privacy-focused overlay network incorporated in Bitcoin Core. It creates hops between a random network of peers to obfuscate traffic. 

v2transport [13] encrypts connections between peers, hiding the traffic from snoops and censors. The aim is to thwart passive network observers from snooping on the contents of your communications with other nodes.

I2P (the Invisible Internet Project [14]) is an optional feature of Core which enables an additional, private, encrypted layer to one’s connections. It is a Tor-like anonymity network which relies on peers to obfuscate traffic between clients and servers.

ASmap [15] is another optional feature of Core which implements a mitigation for the Erebus attack that the authors already outlined in the paper, and applies to all AS-based attacks. By making Bitcoin’s peering mechanism aware of the AS that peers are coming from to ensure diversity amongst peers, an eclipse becomes exponentially more difficult, as an attacker would have to compromise many ASs, which is highly unlikely and almost impossible without being detected. Bitcoin Core supports taking a map of IP networks to their AS (an AS-map) since Core 20.0, and the Kartograf project enables any user to generate such an ASmap easily.

Given that the Internet is likely to continue being vulnerable to many attacks, one of the things we can do is observe our peers’ behavior to attempt to detect malicious behavior. This is the impetus behind the peer-observer project by 0xb10c [16]. It provides a full eBPF tracepoint-based logging system (a way to observe the tiniest actions in a program running on an operating system) to observe a node’s activity, including peer behavior. It also gives you everything you need to build your own logging systems.

Bitcoin Must Be Robust

Securing the ability to connect to peers and exchange messages is a keystone component of what makes Bitcoin tick.

Bitcoin operates in a multi-dimensional adversarial environment, in which many of the threats are created by limitations of the internet’s architecture itself. If Bitcoin is to survive and thrive, its developers and users must learn to navigate these strange waters.

The price of open networks is eternal vigilance.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[0] https://web.mit.edu/gtmarx/www/connect.html

[1] https://satoshi.nakamotoinstitute.org/emails/cryptography/4/

[2] https://bitcoincore.org/en/2019/11/08/CVE-2017-18350/

[3] https://bitcoincore.org/en/2024/07/03/disclose-unbounded-banlist/

[4] https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786/

[5] https://en.wikiquote.org/wiki/Ellen_Ullman

[6] https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-heilman.pdf

[7] https://ihchoi12.github.io/assets/tran2020stealthier.pdf

[8] https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965

[9] https://www.theregister.com/2014/08/07/bgp_bitcoin_mining_heist/

[10] https://www.theverge.com/2018/4/24/17275982/myetherwallet-hack-bgp-dns-hijacking-stolen-ethereum

[11] https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600

[12] www.coinbase.com/blog/celer-bridge-incident-analysis

[13] https://bitcoinops.org/en/topics/v2-p2p-transport/

[14] https://geti2p.net/en/

[15] https://asmap.org

[16] https://peer.observer

[13] https://github.com/asmap/kartograf

This post The Core Issue: Your Node Vs. The Digital Wilderness first appeared on Bitcoin Magazine and is written by Julien Urraca, Fabian Jahr, 0xb10c and CedArctic.

Intro

Bitcoin’s “don’t trust, verify” culture requires that the ledger can be rebuilt by anyone from scratch. After processing all historical transactions every user should arrive at the exact same local state of everyone’s funds as the rest of the network.

This reproducibility is at the heart of Bitcoin’s trust-minimized design, but it comes at a significant cost: after almost 17 years, this ever-growing database forces newcomers to do more work than ever before they can join the Bitcoin network.

When bootstrapping a new node it has to download, verify, and persist every block from genesis to the current chain tip – a resource-intensive synchronization process called Initial Block Download (IBD).

While consumer hardware continues to improve, keeping IBD requirements low remains critical for maintaining decentralization by keeping validation accessible to everyone – from lower-powered devices like Raspberry Pis to high-powered servers.

Benchmarking process

Performance optimization begins with understanding how software components, data patterns, hardware, and network conditions interact to create bottlenecks in performance. This requires extensive experimentation, most of which gets discarded. Beyond the usual balancing act between speed, memory usage, and maintainability, Bitcoin Core developers must choose the lowest-risk/highest-return changes. Valid-but-minor optimizations are often rejected as too risky relative to their benefit.

We have a significant suite of micro-benchmarks to ensure existing functionality doesn’t degrade in performance. These are useful for catching regressions, i.e. performance backslides in individual pieces of code, but aren’t necessarily representative of overall IBD performance.

Contributors proposing optimizations provide reproducers and measurements across different environments: operating systems, compilers, storage types (SSD vs HDD), network speeds, dbcache sizes, node configurations (pruned vs archival), and index combinations. We write single-use benchmarks and use compiler explorers for validating which setup would perform better in that specific scenario (e.g. intra-block duplicate transaction checking with Hash Set vs Sorted Set vs Sorted vector).

We’re also regularly benchmarking the IBD process. This can be done by reindexing the chainstate and optionally the block index from local block files, or doing a full IBD either from local peers (to avoid slow peers affecting timings) or from the wider p2p network itself.

IBD benchmarks often show smaller improvements than micro-benchmarks since network bandwidth or other I/O is often the bottleneck; downloading the blockchain alone takes ~16 hours with average global internet speeds.

For maximum reproducibility -reindex-chainstate is often favored, creating memory and CPU profiles before and after the optimization and validating how the change affects other functionality.

Historical and ongoing improvements

Early Bitcoin Core versions were designed for a much smaller blockchain. The original Satoshi prototype laid the foundations, but without constant innovation from Bitcoin Core developers it would not have been able to handle the network’s unprecedented growth.

Originally the block index stored every historic transaction and whether they were spent, but in 2012, “Ultraprune” (PR #1677) created a dedicated database for tracking unspent transaction outputs, forming the UTXO set, which pre-caches the latest state of all spendable coins, providing a unified view for validation. Combined with a database migration from Berkeley DB to LevelDB validation speeds were significantly improved.

However, this database migration caused the BIP50[1] chain fork when a block with many transaction inputs was accepted by upgraded nodes but rejected by older versions as being too complicated. This highlights how Bitcoin Core development differs from typical software engineering: even pure performance optimizations have the potential to result in unintended chain splits.

The following year (PR #2060) enabled multithreaded signature validation. Around the same time, the specialized cryptographic library libsecp256k1 was created, and was integrated into Bitcoin Core in 2014. Over the following decade, through continuous optimizations, it became more than 8x faster than the same functionality in the general-purpose OpenSSL library.

Headers-first sync (PR #4468, 2014) restructured the IBD process to first download the block header chain with the most accumulated work, then fetch blocks from multiple peers simultaneously. Besides accelerating IBD it also eliminated wasted bandwidth on blocks that would be orphaned as they were not in the main chain.

In 2016 PR #9049 removed what appeared to be a redundant duplicate-input check, introducing a consensus bug that could have allowed supply inflation. Fortunately, it was discovered and patched before exploitation. This incident drove major testing resource investments. Today, with differential fuzzing, broad coverage, and stricter review discipline, Bitcoin Core surfaces and resolves issues far more quickly, with no comparable consensus hazards reported since.[2].

In 2017 -assumevalid (PR #9484) separated general block validity checks from the expensive signature verification, making the latter optional for most of IBD, cutting its time roughly in half. Block structure, proof-of-work, and spending rules remain fully verified: -assumevalid skips signature checks entirely for all blocks up to a certain block height.

In 2022 PR #25325 replaced Bitcoin Core’s ordinary memory allocator with a custom pool-based allocator optimized for the coins cache. By designing specifically for Bitcoin’s allocation patterns, it reduced memory waste and improved cache efficiency, delivering ~21% faster IBD while fitting more coins in the same memory footprint.

While code itself doesn’t rot, the system it operates within constantly evolves. Every 10 minutes Bitcoin’s state changes – usage patterns shift, bottlenecks migrate. Maintenance and optimization aren’t optional; without constant adaptation, Bitcoin would accumulate vulnerabilities faster than a static codebase could defend against, and IBD performance would steadily regress despite advances in hardware.

The increasing size of the UTXO set and growth in average block weight exemplify this evolution. Tasks that were once CPU-bound (like signature verification) are now often Input/Output (IO)-bound due to heavier chainstate access (having to check the UTXO set on disk). This shift has driven new priorities: improving memory caching, reducing LevelDB flush frequency, and parallelizing disk reads to keep modern multi-core CPUs busy.

Recent optimizations

The software designs are based on predicted usage patterns, which inevitably diverge from reality as the network evolves. Bitcoin’s deterministic workload allows us to measure actual behavior and course correct later, ensuring performance keeps pace with the network’s growth.

We’re constantly adjusting defaults to better fit real-world usage patterns. A few examples:

• PR #30039 increased LevelDB’s max file size – a single parameter change that delivered ~30% IBD speedup by better matching how the chainstate database (UTXO set) is actually accessed.
• PR #31645 doubled the flush batch size, reducing fragmented disk writes during IBD’s most write-intensive phase and speeding up progress saves when IBD is interrupted.
• PR #32279 adjusted the internal prevector storage size (used mainly for in-memory script storage). The old pre-segwit threshold prioritized older script templates at the expense of newer ones. By adjusting the capacity to cover modern script sizes, heap allocations are avoided, memory fragmentation is reduced, and script execution benefits from better cache locality.

All small, surgical changes with measurable validation impacts.

Beyond parameter tuning, some changes required rethinking existing designs:

• PR #28280 improved how pruned nodes (which discard old blocks to save disk space) handle frequent memory cache flushes. The original design either dumped the entire cache or scanned it to find modified entries. Selectively tracking modified entries enabled over 30% speedup for pruned nodes with maximum dbcache and ~9% improvement with default settings.
• PR #31551 introduced read/write batching for block files, reducing the overhead of many small filesystem operations. The 4x-8x speedup in block file access improved not just IBD but other RPCs as well.
• PR #31144 optimized the existing optional block file obfuscation (used to make sure data isn’t stored in cleartext on disk) by processing 64-bit chunks instead of byte-by-byte operations, delivering another IBD speedup. With obfuscation being essentially free users no longer need to choose between safe storage and performance.

Other minor caching optimizations (such as PR #32487) enabled adding additional safety checks that were deemed too expensive before (PR #32638).

Similarly, we can now flush the cache more frequently to disk (PR #30611), ensuring nodes never lose more than one hour of validation work in case of crashes. The modest overhead was acceptable because earlier optimizations had already made IBD significantly faster.

PR #32043 currently serves as a tracker for IBD-related performance improvements. It groups a dozen ongoing efforts, from disk and cache tuning to concurrency enhancements, and provides a framework for measuring how each change affects real-world performance. This approach encourages contributors to present not only code but also reproducible benchmarks, profiling data, and cross-hardware comparisons.

Future optimization suggestions

PR #31132 parallelizes transaction input fetching during block validation. Currently, each input is fetched from the UTXO set sequentially – cache misses require disk round trips, creating an IO bottleneck. The PR introduces parallel fetching across multiple worker threads, achieving up to ~30% faster -reindex-chainstate (~10 hours on a Raspberry Pi 5 with 450MB dbcache). As a side effect, this narrows the performance gap between small and large -dbcache values, potentially allowing nodes with modest memory to sync nearly as fast as high-memory configurations.

Besides IBD, PR #26966 parallelizes block filter and transaction index construction using configurable worker threads.

Keeping the persisted UTXO set compact is critical for node accessibility. PR #33817 experiments with reducing it slightly by removing an optional LevelDB feature that might not be needed for Bitcoin’s specific use case.

SwiftSync[3] is an experimental approach leveraging our hindsight about historical blocks. Knowing the actual outcome, we can categorize every encountered coin by its final state at the target height: those still unspent (which we store) and those spent by that height (which we can ignore, merely verifying they appear in matching create/spend pairs anywhere). Pre-generated hints encode this classification, allowing nodes to skip UTXO operations for short-lived coins entirely.

Bitcoin Is Open To Anyone

Beyond synthetic benchmarks, a recent experiment[4] ran the SwiftSync prototype on an underclocked Raspberry Pi 5 powered by a battery pack over WiFi, completing -reindex-chainstate of 888,888 blocks in 3h 14m. Measurements with equivalent configurations show a 250% full validation speedup[5] across recent Bitcoin Core versions.

Years of accumulated work translate to genuine impact: fully validating nearly a million blocks can now be done in less than a day on cheap hardware, maintaining accessibility despite continuous blockchain growth.

Self-sovereignty is more accessible than ever.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[2] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures 

[3] https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562 

[4] https://x.com/L0RINC/status/1972062557835088347

[5] https://x.com/L0RINC/status/1970918510248575358 

All Pull Requests (PR) listed in this article can be looked up by number here: https://github.com/bitcoin/bitcoin/pulls

This post The Core Issue: Outrunning Entropy, Why Bitcoin Can’t Stand Still first appeared on Bitcoin Magazine and is written by willcl-ark, l0rinc and hodlinator.

For all of bitcoin’s life, it has been fighting an uphill battle against fiat currencies that mostly do the job of being money. Obviously, fiat has plenty of issues, but when it comes to impacts immediately visible to everyday people in much of the world, bitcoin isn’t 10x better. Some may even conclude that they would prefer a system based on neutral money to government-rigged ones, but entrenched fiat systems work well enough that few want to deal with the hassle of constant conversion. With the rapid growth in agents’ capabilities, a huge gap has opened that bitcoin has a shot at filling. Instead of competing with entrenched interests as you would with fiat, in the agentic payments field, everyone is starting from zero.

In a recent post on Spiral’s Substack, I pointed out that all of the payment standards being developed for AI agents haven’t yet gotten off the ground. Credit cards won’t work in a world where automated tooling is making purchases. The web is filled with captchas and heavy investments in blocking bots, rather than enabling their use for commerce. Even if they offered payment methods that agents could use, few merchants today have websites that agents can reasonably navigate. No matter what payment method agents ultimately use, it will require every merchant to adapt to a new world.

With no one company owning both the agent and merchant sides of the marketplace, this leaves a wide-open opportunity where it’s still anyone’s game. Better yet, with the popularity of open-source agents today, no company owns much of the purchasing side at all! If the bitcoin community plays its cards right, there’s a good shot at a large part of the future of commerce flowing over open rails not controlled by any single company.

There’s still a lot to build, however, and nearly every payments industry player is trying to position itself to take the crown. Visa is working on an “Intelligent Commerce” product, OpenAI and Stripe announced the Agentic Commerce Protocol (ACP), Google announced AP2 and Coinbase announced an extension of it for crypto – x402. The bitcoin community’s lack of central planning makes responding with their own options more chaotic and harder to follow, but that’s also its strength: lots of people trying lots of different approaches to achieve the same goal are more likely to succeed than a single, focused approach that might be wrong.

With Lightning surpassing a billion dollars in monthly transactions and Square enabling Lightning for its in-person merchants, it seems the technology is finally here that will let bitcoin cross the chasm and become everyday money. Some ideological merchants have been accepting bitcoin for years, and as we continue to integrate bitcoin wallets into agents, we’ll create yet more reasons for every merchant that wants to sell things to join in. But for that to work, bitcoiners have to step up and use the tools at their disposal. If people aren’t trying to buy things with bitcoin, merchants won’t care.

Luckily, these days, you don’t need code to build tools that find merchants accepting bitcoin payments. You don’t even have to sell your stack to buy things with bitcoin. Install an agent, give it a wallet, give it some bitcoin, and tell it to go buy your monthly beef tallow subscription. Tell it to email merchants it wants to buy from and ask them to support bitcoin. Point it to the Bitcoin Merchant Community and have it explain to any merchant it comes across that it wants to pay them without Visa taking a cut but wasn’t able to.

Thanks to extensive existing work, bitcoin is already one of the best ways to enable automated online commerce. Instead of merchants having to fill their sites with captchas to prevent bots from using stolen credit cards and dealing with chargebacks, many bitcoin payment processors can provide merchants with local currency within a day. Instead of being exposed to the risk that an operator’s single private key could seize their stablecoins, merchants can choose from many payment processors, whether foreign or domestic. This competition drives down fees and means we’re not building new payment rails on a platform that will inevitably seek higher rents once its dominance is cemented.

These issues aren’t top of mind for most, but we must get the new rails right. Stablecoins look great at first glance, but moving to a world where one company (Coinbase) owns both the platform (Base) and earns all the interest on the currency’s float (USDC) where payments are made is not a recipe for long-term success. Once everyone is locked into using one payment method, switching away as the operator increases fees won’t be practical. It doesn’t matter whether the protocol agents use to communicate with merchants is based on some “open standard.” If the vast majority of agents have funds on only one platform and the vast majority of merchants accept funds on only one platform, switching will be impossible.

While bitcoin has come a long way on its journey to becoming a reserve asset, it is only beginning its path towards everyday money. Bitcoin reaching escape velocity on the first does not imply that the second is guaranteed; in fact, far from it. With so much competition from every payments industry player, not to mention stablecoins, there’s a lot of outreach and work to be done to build payment momentum. Still, we can’t let this opportunity pass us by. If you believe commerce should happen on neutral money rather than corporate gatekeepers, it’s time to get to work.

This is a guest post by Matt Corallo. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post Bitcoin Has a Golden Opportunity With AI Agents, It’s Time to Build first appeared on Bitcoin Magazine and is written by Matt Corallo.

Protocol developers often come across as more pessimistic about Bitcoin’s future than most Bitcoiners. Daily exposure to Bitcoin’s imperfections certainly shapes a sober perspective, and it’s important to reflect on what Bitcoin has achieved. Anyone in the world, no matter their race, age, gender, nationality, or any other arbitrary criterion, is able to store and transfer value on a neutral monetary network more robust now than ever. That said, Bitcoin does have issues that many Bitcoiners are not aware of, but could threaten its long-term prospects if not addressed properly. The vulnerabilities fixed by the Consensus Cleanup are one such example.

The Consensus Cleanup (BIP 54¹) is a soft fork proposal aimed at patching multiple long-standing vulnerabilities within the Bitcoin consensus protocol. As a soft fork proposal, it is separate in nature to most other Bitcoin Core efforts featured in this edition. Although the proposal has historically been championed by individuals associated with the Bitcoin Core project, it really belongs to the broader category of Bitcoin protocol development.

We will walk through each of the proposal’s four items, describing the impact of the issue addressed and the remediation applied. We’ll discuss how the proposed mitigations evolved to address feedback as well as newfound vulnerabilities. We’ll finish with a brief overview of the current status of the soft fork proposal.

A vulnerability in Bitcoin’s Proof of Work

The Bitcoin network adjusts mining difficulty to maintain an average block rate of one per 10 minutes. An “off by one” bug (a common programming mistake) in its implementation opens up an attack called the Timewarp attack, whereby a majority of miners can artificially speed up the rate of block production by manipulating the difficulty downward.

This attack fortunately requires a 51%+ threshold of miners, but artificially speeding up the block rate is a critical issue. It means that full nodes are not in control of resource usage anymore, and that an attacker can considerably accelerate the bitcoin subsidy emission schedule.

Even though it requires a “51% miner”, it is a significant departure from the standard Bitcoin threat model. A 51% attack traditionally enables a miner to prevent the confirmation of a transaction for as long as they maintain their advantage. But the presence of this bug grants them the power to cripple the network within just 38 days by rapidly reducing the network difficulty.

Instead of taking down the network, it is more probable that an attacker would exploit this bug to a smaller extent. Current miners could coordinate to quadruple the block rate (to 2.5 minute blocks) while keeping the Bitcoin network in a seemingly functioning state, effectively quadrupling the available block space and stealing block subsidies from future miners. Short-sighted users may be incentivized to support this attack, as more available block space would mean -ceteris paribus- lower fees for onchain transactions. This would of course come at the expense of full-node runners and undermine the network’s long term stability.

The Timewarp attack exploits the fact that difficulty adjustment periods do not overlap, allowing block timestamps to be set so that a new period appears to start before the previous one has finished. Because making them overlap would be a hard fork, the next best mitigation is to link the timestamps of blocks at the boundaries of difficulty adjustment periods. The BIP 54 specifications mandate that the first block of a period cannot have a timestamp earlier than the previous period’s last block by more than two hours.

In addition, the BIP 54 specifications mandate that a difficulty adjustment period must always take a positive amount of time. That is, for a given difficulty adjustment period, the last block may never have a timestamp earlier than the first block’s. Surprised this isn’t already the case? We were surprised it was at all necessary. Turns out this is a simple fix for a clever attack, related to Timewarp, that pseudonymous developer Zawy and Mark “Murch” Erhardt came up with when reviewing the Consensus Cleanup proposal.

Blocks that take hours to validate

Any miner can exploit certain expensive validation operations to create blocks that take a long time to verify. Whereas a normal Bitcoin block takes in the order of a hundred milliseconds to validate, validation times for these “attack blocks” range from more than ten minutes on a high-end computer to up to ten hours on a Raspberry Pi (a popular full-node hardware choice).

An externally-motivated attacker may leverage this to disrupt the entire network, while in a more economically rational variant of the attack, a miner can delay its competition just long enough to increase its profits without creating widespread network disruption.

Historical attempts to mitigate this issue have been tumultuous, because it requires imposing restrictions on Bitcoin’s scripting capabilities. Such restrictions have the potential of being confiscatory, which is paramount to avoid in any serious soft fork design.

Matt Corallo’s original 2019 Great Consensus Cleanup proposed to solve these long block validation times by invalidating a couple of obscure operations in non-Segwit (“legacy”) Script. Some raised concerns that although transactions using those operations had not been relayed nor mined by default by Bitcoin Core for years, someone, somewhere, may still be depending on it unbeknownst to everyone. Of course, this has to be weighed against the practical risk to all Bitcoin users of a miner exploiting this issue.

Even though the confiscation concern is fairly theoretical, there is a philosophical point on how to perform Bitcoin protocol development in trying to design an appropriate mitigation for the vulnerability with the smallest confiscatory surface possible. My later iteration of the Consensus Cleanup proposal addressed this concern by introducing a limit which pinpoints exactly the harmful behaviour, without invalidating any specific Bitcoin Script operation.

Forged proofs of payment

Bitcoin block headers contain a Merkle root that commits to all transactions in the block. This makes it possible to give a succinct proof that a given transaction is part of a chain with a certain amount of Proof of Work. This is commonly referred to as an “SPV proof”.

Due to a weakness in the design of the Merkle tree, including a specifically-crafted 64-byte transaction in a block allows an attacker to forge such a proof for an arbitrary fake (non-existent) transaction. This may be used to trick SPV verifiers, commonly used to validate incoming payments or deposits into a side-system. Mitigations exist that enable verifiers to reject such invalid proofs; however, these are often overlooked—even by cryptography experts—and can be cumbersome in certain contexts.

The Consensus Cleanup addresses this issue by invalidating transactions whose serialized size is exactly 64 bytes. Such transactions cannot be secure in the first place (they can only ever burn funds or leave them for anyone to spend), and have not been relayed or mined by default by Bitcoin Core since 2019. Alternative approaches were discussed, such as a round-about way of improving the existing mitigation^a, but the authors chose to fix the root cause of the issue, eliminating both the need for implementers to apply the mitigation and the need for them to even know about the vulnerability in the first place.

^a: committing to the Merkle tree depth in part of the block header’s version field

UTXO Doppelgängers: duplicate transactions

“Mirco… Mezzo… Macroflation—Overheated Economy” is the title of a blog post⁴ Russell O’Connor published in February 2012, in which he describes how Bitcoin transactions can be duplicated. This was a critical flaw in Bitcoin, which broke the fundamental assumption that transaction identifiers (hashes) are unique. This is because miners’ coinbase transactions have a single blank input, meaning that any coinbase transaction with the same outputs would have an identical transaction identifier. 

This was fixed by Bitcoin Core (then still called “Bitcoin”) developers with BIP 30², which required full nodes to perform additional validation when receiving a block. That extra validation was not strictly necessary to solve the issue, and was side-stepped with BIP 34³ the same year. Unfortunately, the fix introduced in BIP 34 is imperfect and the BIP 30 extra validation will once again be required in 20 years. Beyond not being strictly necessary, this validation cannot be performed by alternative Bitcoin client designs such as Utreexo and would effectively prevent them from fully validating the block chain.

The Consensus Cleanup introduces a more robust, future-proof fix for the issue. All Bitcoin transactions, including the coinbase transactions, contain a field to “time lock” the transaction. The value of the field represents the last block height at which a transaction is invalid. The BIP 54 specifications require that all coinbase transactions set this field to the height of their block (minus 1).

Combined with a clever suggestion from Anthony Towns to make sure the timelock validation always occurs, this guarantees that no coinbase transaction with the same timelock value may have been included in a previous block. This in turn guarantees that no coinbase transaction may have the same unique identifier (hash) as any past one, without requiring BIP 30 validation.

An ounce of prevention is worth a pound of cure

The vulnerabilities addressed by the Consensus Cleanup (BIP 54) are not an existential threat to Bitcoin at the moment. While some have the potential to cripple the network, they are unlikely to be exploited for now. That said, this might change and it is paramount that we proactively mitigate long-term risks to the Bitcoin network, even if it means having to bear the short term burden of coordinating a soft fork.

The work on the Consensus Cleanup started with Matt Corallo’s original proposal in 2019. It came together 6 years later with my publication of BIP 54 and an implementation of the soft fork in Bitcoin Inquisition, a testbed for Bitcoin consensus changes. Throughout this time the proposal received considerable feedback, various alternatives were considered and mitigations for additional weaknesses were incorporated. I believe it is now ready to be shared with Bitcoin users for consideration.

The Consensus Cleanup is a soft fork. Bitcoin protocol developers choose which improvements to prioritize and make available to the public. But the ultimate decision to adopt a change to Bitcoin’s consensus rules rests with the users. The choice is yours.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md 

[2] https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki 

[3] https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki 

[4] https://r6.ca/blog/20120206T005236Z.html 

This post The Core Issue: Consensus Cleanup first appeared on Bitcoin Magazine and is written by Antoine Poinsot.

Bitcoin is the largest pool of pristine collateral in the world.

It is scarce, globally settled, politically neutral, and cannot be diluted. Few assets combine monetary premium and liquidity at this scale. Yet borrowing against bitcoin remains expensive, fragmented, and short-term.

That mismatch is not primarily about volatility. It is about market structure. BTC-backed lending exists. But BTC-backed credit markets, in the mature sense, largely do not.

Loans Are Not Markets

If you post BTC as collateral and borrow dollars, the mechanics are simple.

Bitcoin is locked. Cash is advanced. If the loan deteriorates, the BTC is liquidated. That is origination.

In mature financial systems, origination is only the beginning. Once a loan is made, it becomes an asset for the lender. That asset can be sold, pledged, financed, or bundled. Loans circulate. Capital is reused. That reuse is what allows credit to scale.

When lenders can finance positions in secondary markets, their capital is no longer trapped. Recycling compresses rates, extends maturities, and deepens liquidity.

BTC-backed lending today largely stops at origination. Most loans remain bilateral or trapped inside pool abstractions. Once capital is deployed, expansion depends on new deposits.

This is why borrowing costs remain high relative to the quality of the collateral. Bitcoin is high-quality. The credit rails are not.

Why DeFi Hit a Ceiling

Early onchain lending tried to rebuild credit markets from scratch.

The first serious designs used orderbooks. Lenders posted offers. Borrowers matched them. In theory, this is how markets should work. In practice, liquidity fragmented and pricing required constant active management. These systems stalled.

The next wave replaced orderbooks with pools. Protocols like Compound and Aave aggregated liquidity and set rates algorithmically based on utilization. Pools solved capital formation. Lending became passive and scalable. Anyone could deposit funds and earn yield without actively managing risk.

But pools flattened market structure. All loans shared the same floating rate. There were no fixed maturities. No differentiated claims. No discrete instruments to trade.

Pools aggregate liquidity efficiently. They do not produce term-structured credit markets.

Without differentiated loan instruments, there is nothing meaningful to securitize or finance. As a result, lending remains shallow and fixed-term borrowing expensive. This is a structural tradeoff, not a minor implementation flaw.

What Has Changed

A new generation of onchain architecture is beginning to reintroduce market structure without sacrificing liquidity.

Instead of abandoning pools entirely, newer designs combine pooled liquidity with orderbooks, fixed maturities, and standardized loan units.

The key shift is turning loans into standardized, fungible claims. Rather than bespoke contracts, fixed-term loans can be represented as zero-coupon units that mature at a defined date. Once issued, those units are identical within a market and can trade at prevailing prices.

That standardization matters. Lenders no longer hold isolated contracts. They hold interchangeable claims. Interchangeable claims concentrate liquidity. Concentrated liquidity tightens spreads. Tight spreads enable continuous price discovery.

In practical terms, fixed-term BTC-backed loans can exist onchain, trade before maturity, and allow lenders to exit without waiting for repayment. Secondary markets can form organically rather than being engineered around pools.

Morpho V2 is one example of this architectural shift, combining onchain orderbooks, intent-based liquidity, and standardized loan units to enable market-based pricing without sacrificing scale. Platforms like Alpen are building the trust-minimized infrastructure that makes this credit formation possible on bitcoin.

The broader point is not any single protocol. It is that the structural ceiling that constrained onchain credit markets is beginning to lift.

Why Loan Standardization & Secondary Markets Matter

In traditional finance, credit scales because loan claims can be financed in deeper funding markets.

A bank originates mortgages. Those loans are packaged into standardized claims that can be traded or pledged. That secondary funding lowers the bank’s cost of capital and liquidity risk, enabling cheaper and longer-term lending. The borrower’s terms do not change. The reuse happens behind the scenes.

The same dynamic can now emerge onchain.

When BTC-backed loans are represented by standardized receipt tokens, they stop being isolated agreements and become financeable claims. Those claims can be sold in secondary markets, pledged as collateral for short-term liquidity, or aggregated into structured portfolios.

At that point, a vault holding diversified BTC-secured loans begins to resemble a Bitcoin-collateralized loan obligation (“bCLO”): a dollar-denominated claim backed by overcollateralized BTC and enforced by code. BTC lending shifts from bilateral loans to the production of reusable collateral objects.

Importantly, this does not require rehypothecating BTC. The bitcoin remains locked and segregated. What circulates are claims on future repayment.

When lenders can exit or finance positions, fixed-term loans no longer need to carry a heavy lockup premium. Capital competes away excess spreads. Term rates compress toward short-term funding rates.

That compression is what transforms collateral into a true funding base.

Trust Still Has to Be Bounded

None of this eliminates risk.

BTC-backed credit markets still depend on custody models, oracle integrity, liquidation depth, and governance boundaries. Onchain architecture does not remove trust. It makes it explicit and opt-in.

Different markets can choose different custody assumptions. Curators can define risk parameters with protections. Oracles can be selected and monitored. Governance authority can be constrained by timelocks and transparency.

The cheapest credit flows to the lowest-trust collateral. If BTC-backed credit is built on discretionary custody or opaque governance, it will carry embedded risk premia. If trust is minimized and clearly bounded, markets will price that accordingly.

Architecture determines where trust lives. Markets determine how much it costs.

The Near-Term Impact

This is not a distant macro thesis. The implications are near-term.

If BTC-backed loan claims become standardized and financeable, borrowing costs compress, longer maturities become viable, institutional desks gain deeper funding options, and BTC holders access more stable liquidity.

More importantly, bitcoin begins to function not only as a store of value, but as base-layer collateral inside its own native credit markets.

In traditional finance, US Treasuries anchor repo markets because they are the most financeable collateral at scale. Bitcoin is already the largest pool of non-sovereign savings in the world. What it lacked were financeable claims capable of functioning as preferred collateral.

That architecture is emerging.

Size and Structure

Credit expands until it meets its constraint. Historically, when collateral could not scale, systems manufactured substitutes. Synthetic safety replaced real savings. Eventually those structures fractured.

Bitcoin does not need synthetic substitutes. It already represents deep, accumulated capital.

But size without structure is inert. A trillion-dollar asset that cannot circulate through mature credit rails remains underutilized. Conversely, sophisticated architecture without meaningful collateral is a toy.

For the first time, bitcoin has both. BTC-backed lending is moving beyond isolated originations and floating-rate pools. Fixed-term, market-priced, reusable loan claims are becoming viable onchain. Secondary markets can form. Capital can recycle.

This does not guarantee dominance or eliminate volatility. It does something more important. It makes it structurally possible for bitcoin to support real credit markets without inheriting the fragility of legacy systems.

That shift is not about chasing yield. It is about fixing the plumbing. When the plumbing changes, everything built on top of it changes too.

You can read the full report in PDF format here.

This is a guest post by David Seroy of Alpen Labs. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post Bitcoin Is The Collateral, It Just Needs The Credit Markets first appeared on Bitcoin Magazine and is written by David Seroy.

Segregated Witness (BIP by Pieter Wuile, Eric Lombrozo, and Johnson Lau) and Taproot (BIPs by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns) are the two largest changes ever made to the Bitcoin protocol. 

The former fundamentally changed the structure of Bitcoin transactions, and in the process Bitcoin blocks, to address inherent limitations of the previous transaction structure. The latter rearchitectured some aspects of Bitcoin’s scripting language, how complex scripts are structured and validated, and introduced a new scheme for creating cryptographic signatures. 

Those are both massive changes in comparison to say, adding a single opcode like CHECKTIMELOCKVERIFY (CLTV) that does nothing more than allow the receiver to opt into preventing their coins from moving for a certain amount of time. 

These changes were made to address very real shortcomings and limitations of Bitcoin as a system. As a foundational layer to maintain a global consensus on the overall state of Bitcoin, i.e all the unspent coins, Bitcoin is an invaluable and brilliant innovation. As a means to directly enable everyone to transact with those coins, it is woefully inadequate to the task. 

In the years since Segregated Witness and Taproot activated, many of the shortcomings they addressed have been forgotten. The reasons and rationale behind the design decisions have been distorted in a game of telephone as time passed as well. 

Both of these changes to the Bitcoin protocol were solutions to large problems in their own right, but they also each laid the groundwork for solving other problems or making other improvements in the future. 

At a time where many new people have joined the network since these changes activated, it is worth going back over and contextualizing the design choices. 

Segregated Witness (BIP 141¹)

When a Bitcoin transaction spends coins, it references them by the output index and transaction ID (TXID) of the transaction that created them. This ensures that a transaction’s inputs can be uniquely identified and be verified with absolute certainty to have never been spent before. 

Prior to Segregated Witness, a transaction structure looked like this:

[Version] [Inputs] [Outputs] [Locktime]

The TXID is a hash of this data. The problem is the ScriptSig (the signatures, hash preimages, etc.) that prove the transaction is valid are part of the inputs. You can change the little program instructions in a ScriptSig, or even change the cryptographic signatures themselves without invalidating them. 

These “malleations” change TXIDs. This is a big problem for pre-signed transactions. 

The Lightning Network, Ark, Spark, BitVM, Discreet Log Contracts (DLCs), all of these scaling tools depend on pre-signed transactions. They require creating an unsigned funding transaction, and pre-signing all the transactions that guarantee proper execution and safety of funds before signing and confirming the funding transaction. All of these systems use multisignature authentication to guarantee safety regarding double-spending (this will be important later). 

If that funding transaction is malleated, and its translation ID changed before it is confirmed in a block, then all of the pre-signed transactions securing second layer funds are invalidated. None of these tools work in an environment where anyone can alter your funding TXID as it propagates across the network. 

Segregated Witness uses an undefined opcode as a sort of blinding curtain where the ScriptSig previously was in the inputs, and moves all of that data to a new transaction field called the “witness.” The new transaction structure looks like this:

[Version] [Marker/Flag] [Inputs] [Outputs] [Witness] [Locktime]

The “blinding curtain” in the inputs allows old nodes to just mark everything behind it as valid by default, and newer nodes to actually apply the appropriate validation logic. A traditional TXID will now no longer change due to altering ScriptSig data in the witness. This solved the problem for pre-signed transactions, and opened the door to every scaling solution being built today that uses them. 

But the transaction merkle tree in a block header only commits to the traditional TXID of a transaction, this creates a problem. There is no commitment to any witness data in a block. This requires the witness commitment, and the witness transaction ID (WTXID). Much the same way that the normal merkle tree of TXIDs is constructed, a tree of each transaction’s WTXID is constructed and committed to in the coinbase transaction’s witness. 

The only difference is the root of the tree is hashed with a reserve value, and that is what is included in the coinbase witness. This allows for that value to be used in future for committing to other new data fields in consensus rules. Prior to the invention of this witness tree commitment (which was thought of by Luke Dashjr), it was assumed Segregated Witness would require a hardfork due to the transaction structure change and the need for a separate witness commitment in the block header. 

The “blinding curtain” design also allows arbitrary upgrades to the scripting system because all new data is ignored and not validated by nodes not supporting it. This allows a new script system to bypass all restrictions of the legacy script system. Flexibility in upgrade paths here is what allowed Schnorr signatures to be integrated, and will allow quantum resistant signatures if necessary (quantum resistant public keys are generally larger than the legacy 520-byte data item limit, as are signatures). 

Segregated Witness solved the fundamental problem of transaction ID malleability that was holding back the development of scalable second layers that can bring Bitcoin to more users, but it also laid the groundwork for whatever scripting improvements were necessary to support and improve those second layers. 

Schnorr Signatures²

Schnorr signatures were invented in 1991 by Claus Schnorr, and promptly patented. In fact, the ECDSA signature scheme was invented because of the patent on Schnorr signatures. The patent on Schnorr signatures expired in February 2010, a little more than a year after the launch of the Bitcoin network. 

If it weren’t for the patent, it is likely that Satoshi (and the rest of the world) would have just used Schnorr signatures from the start. 

There are a few major benefits that Schnorr signatures have over ECDSA:

• Schnorr signatures are provably secure. The mathematical proof that Schnorr signatures are unforgeable/unbreakable is much stronger, and makes less assumptions, than that for ECDSA. Having stronger security guarantees for the cryptography that rests at the heart of Bitcoin is obviously a huge positive. 
• Schnorr signatures are inherently non-malleable, meaning that the types of issues with ECDSA that allowed altering a signature without invalidating it are simply not possible with Schnorr signatures.
• Schnorr signatures have a linearity that allows for simple and efficient additive key construction, distributed key generation, and distributed signature generation. This allows users to simply “add” individual Schnorr public keys together, and produce signatures for those aggregate public keys together as a group. 

They’re more secure, not malleable by third parties, and open the door to all kinds of efficient and flexible cryptographic schemes to improve multisignature authentication. 

Earlier when discussing transaction malleability I mentioned that everything building off-chain using pre-signed transactions depended on multisignature authentication to secure user funds. This created an implicit scaling ceiling when it comes to shared control of funds. Legacy multisig can only be so big. There are transaction size limits, and for version 0 (Segregated Witness) witnesses, there is a witness size limit. Only so many participants could join a multisignature address, so implicitly only so many participants could share control of funds. 

Schnorr based multisignature schemes escape this limit by aggregating public keys into a single group public key rather than constructing a script with each member key explicitly included individually. Prior to Segregated Witness a multisignature address could only have 15 participants, after Segregated Witness the maximum size possible was 20 participants. 

With Schnorr based multisignature schemes like MuSig⁵ and FROST⁶ these limitations don’t exist, at least at the consensus level. Multisignature scripts can be as large as users want as long as it is practical to coordinate the signing process within a group of the chosen size without disruption or refusal to participate. 

The same properties that allow key aggregation like this also allow for efficient adaptor signatures, a scheme that allows someone to produce a signature that remains invalid until after a secret piece of information is revealed. Those properties also allow for a zero-knowledge proof powered scheme for a signer to produce a signature over a message they cannot see. 

Taproot^3,4

Taproot is an evolution of an old concept called Merkelized Abstract Syntax Trees (MAST)⁷, which is itself a kind of extension of Pay-to-script-hash (P2SH)⁸. P2SH was originally created to deal with two major problems: 

• When using large custom scripts, the resulting unspent output is larger, requiring more space to store in the UTXO set.
• When using large custom scripts, the sender pays a higher fee, as the payment output in their transaction is larger, thereby disincentivizing people from paying potentially more secure custom scripts. 

Rather than explicitly include the entire script in the output, a hash of that script is included instead, and at spending time the recipient must provide the entire script in the input being spent to be verified against the hash. This solved the problem of unspent output storage space, and puts the cost of using larger scripts on the person using them rather than those sending them funds. 

This still leaves a problem. Custom scripts can include multiple ways to spend them, but at spending time the user must still reveal the entirety of the script, including script branches that are not necessary to verify the condition under which the coin is actually spent. This is incredibly space inefficient, and leaves the spending user with a higher cost than is necessary. 

The idea behind MAST is to take each individual spending condition in a multi-branch script and separate them, constructing a merkle tree of each individual spending path. Each path is then hashed, and the root of that merkle tree is the user’s address. At spending time the user simply provides the spending path they are using along with the merkle proof that it is a leaf in the tree, along with the data necessary to satisfy that script. 

This merkle tree structure solves all the same problems as P2SH, as well as optimizing the spending costs of the MAST user (and improves their privacy as well!). 

Taproot takes this concept and integrates in a more privacy-preserving way by taking advantage of the linear properties of Schnorr signatures. Most types of contracts people want to build are going to have an optimistic outcome, where both users simply agree on how to disperse funds. In such cases they can just sign a transaction. Taproot takes the MAST root and “tweaks” a Schnorr public key, resulting in a new public key. By “tweaking” the private key with the same MAST root, you arrive at the corresponding private key to the new public key. 

Users can now either simply spend an output using that tweaked key, leaving no trace that a MAST tree is present at all, or reveal the original public key and MAST root along with the spending path they are actually using. As well, if you wish to not include a key path, a special NUMS (Nothing Up My Sleeve) value which is provably unspendable can be used instead of a normal public key, leaving only MAST scripts as valid spending paths. 

Taking advantage of the design choices of Segregated Witness, Taproot also introduced tapscript, a new scripting system. The major changes here are deactivating OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. They are replaced with OP_CHECKSIGADD, which allows a more efficient way to verify multiple signatures. This in combination with Schnorr key aggregation allows the same multisignature functionality as legacy script. 

Tapscript additionally modifies OP_CHECKSIG and OP_CHECKSIGVERIFY to only work with Schnorr signatures, and introduces OP_SUCESS as a replacement for OP_NOP (undefined opcodes in legacy script). OP_SUCCESS is designed to allow cleaner and safer opcode upgrades than OP_NOP. 

Witness Limits

Two aspects have been left undiscussed until now. The blockweight limit introduced in Segregated Witness, and the witness size limit increase in Taproot. 

Both of these decisions have become a point of contention among a very active minority of power users in the ecosystem. I won’t be discussing the blocksize increase that was part of introducing the blockweight limit, this was a compromise at the time with dissenting users pushing for a hardfork blocksize increase and deemed safe by network participants at the time; but the dynamic of the witness discount itself is important. 

Bitcoin transaction fees are based on the amount of data in a transaction. This has no relationship to the amount of value being transferred. It is solely the number of inputs and outputs (and witnesses) and how many bytes of data they are. Recall earlier I mentioned the fact that the ScriptSig, or signatures and other data, were included in the transaction inputs prior to Segregated Witness. This is a large amount of data included in inputs that is not included in outputs.

That means inputs are more expensive than outputs in a transaction, and by a wide margin. This creates a long term incentive for users to also prefer spending large outputs and creating new change ones as opposed to collecting and spending lots of smaller outputs. This is a long term economic incentive encouraging users to perpetually grow the UTXO set which is necessary for all fully validating nodes. 

The witness discount is meant to correct that price margin, making it miniscule as opposed to massive. This is incredibly important to economically incentivize responsible UTXO management, at least in vacuum for economically rational users simply transacting. 

Taproot removed existing size limits on the witness field of a transaction. In Segregated Witness that limit was 10,000 bytes. This was done because the design of Taproot mitigated the potential construction of expensive to verify transactions, and trying to introduce such limits in tapscript introduced a large degree of complexity in Miniscript. The problem such limits existed to prevent did not impact Taproot, and it introduced complexity for a tool meant to make custom scripts safer and more accessible for both developers and users.

The Big Picture

Both of these changes to Bitcoin removed massive roadblocks to scaling it so more people can use it in a self-custodial way, but they necessitated similarly massive changes to fundamental parts of the protocol. 

I hope now that readers previously unfamiliar with all of these design choices, and the rationale behind them, can appreciate the care and forward-thought with which they were designed. Bitcoin is an amazing innovation, it truly is, but it cannot provide its benefits to anything remotely approaching a sizeable percentage of the population.

Segregated Witness and Taproot laid two cornerstones in the foundation that were absolutely necessary in order to attempt to address Bitcoin’s scalability shortcomings. Without these two proposals, or some alternative protocol changes that addressed the same problems, all of these growing scalability layers and systems we have today would not be here. 

 Lightning, Ark, Spark, BitVM, DLCs – none of them would be possible to build. 

That is the big picture. The Bitcoin of today isn’t perfect, but it actually stands a good chance of scaling to a meaningful enough group of people to make a real impact on the world, to offer a true alternative to people looking to opt out. That is because of these two protocol upgrades, and the very fundamental barriers they removed. 

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

[1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki 

[2] https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki 

[3] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki 

[4] https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki 

[5] https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki 

[6] https://github.com/siv2r/bip-frost-signing 

[7] https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki 

[8] https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 

This post The Core Issue: Why Bitcoin Needed A Remodel With Segwit and Taproot first appeared on Bitcoin Magazine and is written by Shinobi.