Bitcoin Core released a major update to bitcoin’s relay policy in v28, introducing the first iteration of a new feature called package relay. Package relay enables multiple transactions to be packaged, broadcast, and relayed together, and is a huge improvement for layer twos like Lightning and Ark, making the protocols more reliable in emergency situations and less expensive to use. 

It’s an underreported update that’s great for bitcoin users, so in this article I’m hoping to give it the attention it deserves and describe how it’s made our work at Second a lot easier.

Transaction relay and relay policy?

Transaction relay is the peer-to-peer mechanism through which bitcoin nodes share bitcoin transaction data with each other, ultimately passing the data to miners to commit to the blockchain.

This process is governed by a relay policy, a filter which prevents spam transactions from entering a node’s mempool and crowding out legitimate transactions. Most nodes rely on the default relay policy settings, though operators can adjust these based on their needs.

You might think that this system already works great—your bitcoin transactions have all made it into a block and been confirmed without an issue. But unfortunately, the relay policy was not designed to support the exotic off-chain payment schemes that are emerging on bitcoin, for example, those used by the Lightning Network and the Ark protocol. 

How is the relay policy relevant to Ark?

Similar to Lightning, Ark users rely on pre-constructed transactions to protect their balance and retain self-custody. These transactions—VTXOs—are normally held and transacted off-chain, but at any time, a user can broadcast their VTXOs to the network to complete a unilateral exit and retrieve their bitcoin on-chain. 

A transaction fee must be baked into a VTXO when it’s created, so under the old relay policy, users (and wallet developers) would struggle to decide on what fee rate to use. They basically had two options: 

• Underpay: Assign an acceptable fee for the fee environment at time of creation and hope the user doesn’t need to broadcast them during times of on-chain congestion.
• Overpay: Assign an excessively high fee to “future-proof” the transaction for possible on-chain congestion.

But either way, there was no way to guarantee a transaction would make it past the relay policy filters when the time comes, never mind into a block.

Unilateral exits are always performed in an emergency scenario, and have strict deadlines, so it’d be a big problem if a user couldn’t get their transaction relayed because all nodes think it’s spam!

Does CPFP not fix this?

Some readers may be thinking that the obvious solution, to overspending at least, would be to always set a low fee rate on VTXOs and rely on child-pays-for-parent (CPFP) to accelerate any unilateral exit transactions that are not getting confirmed. 

CPFP is a widely used method to unstick a low-fee transaction by creating a second child transaction that spends from it but includes a higher fee rate. Miners, incentivized by the higher fee on the child transaction, must first mine the parent transaction to validate the child, effectively unblocking both transactions together.

But it’s not that simple. Using CPFP you can only bump transactions that can make it into the mempool. If the parent (unilateral exit) can't enter the mempool because it pays insufficient fees, the child transaction will be refused because the parent doesn't exist. CPFP only works if both the parent and child transactions are in a miner’s mempool at the same time.

Arkoor chains and disappearing sats

Ark’s out-of-round (arkoor) payments were particularly problematic. 

Arkoor payments are the primary way to send VTXOs between users on Ark because they can be completed without the time-consuming interactive process of rounds (as required by in-round transactions). 

Although the vast majority of arkoor VTXOs will never see the bitcoin blockchain (this would only happen in a unilateral exit), we still had to hard-code a 1 sat/vbyte base fee rate to ensure they could get through the relay filters and into mempools if required. Of course, this wouldn’t guarantee they’d get confirmed, but the assumption was that wallets would use CPFP to pay the actual fee required.

This hard-coded fee meant that even the smallest payments on Ark would always lose a few hundred sats—very annoying. And because the transactions would typically not be mined, the fees would seemingly go nowhere (actually picked up by the ASP after VTXO expiry).

Core have cracked it with package relay

The smart trick the Core team have come up with to solve these issues (and more, see below!) is called package relay. Included in the Bitcoin Core v28 release in October 2024 is an early iteration of package relay, which enables nodes to bundle and relay two dependent transactions together as a single package, allowing mempools to evaluate their combined fee rate rather than assessing each transaction separately.

While the functionality is currently limited to two transactions in a single parent-child relationship (a structure referred to as “one-parent one-child” or “1p1c”), it’s already a powerful improvement for protocols like Ark that depend on CPFP constructions.

Ark users can now reliably set their unilateral exit fees at the time they make their exit, without worrying about whether the parent transaction will be relayed. And wallet developers no longer need to hard-code wasteful fees of 1+ sat/vbyte into every transaction. By bundling a unilateral exit transaction with a child transaction that pays an appropriate fee, Ark users can be confident that both transactions will reach miners’ mempools as a package.

Zero-fee transactions are now viable

Another consequence is that the bitcoin network now reliably supports zero-fee transactions. A child payment can get any parent payment through the relay policy spam filters, no matter how low its fee is, even zero! 

This solves arkoor’s “disappearing sats” problem, we can now simply set the on-chain fee rate for all arkoor VTXOs to zero, and a user can pay the appropriate fees in a bundled child transaction if they ever need to use their VTXOs to make a unilateral exit.

Benefits beyond Ark

We’ve focused package relay’s impact on Ark, because Ark’s what we do, but there are a number of other great benefits from package relay for the broader bitcoin ecosystem that’re worth mentioning here:

• Mitigating transaction relay attacks: DoS attacks enabled by the nature of bitcoin’s relay policy, such as pinning and transaction cycling, can now be overcome by “forcing through” targeted transactions with 1p1c packages. This is possible because the 1p1c package relay also enforces some restrictions on the children that prevent many of the attacks (TRUC).
• Improved transaction conflict handling: Off-chain protocols rely on UTXOs that can be spent by multiple users. The relay policy can sometimes cause the “wrong” transaction to be prioritized in the mempool, but now wallet devs can overcome this with higher fee 1p1c packages.
• More reliable Lightning channel closures: Like Ark, Lightning relies on pre-constructed off-chain transactions (commitment transactions) that are broadcast later. Package relay ensures these can be relayed and confirmed more reliably with optimized fees.

Final words

Package relay might seem like a simple improvement, but it is only a small part in a larger project that is still very much in development. We will only get the full benefits of generalized package relay once we improve the internal structure of the mempool. This is being worked on in a project called cluster mempool. We’re grateful to the Core team for putting in the hard work to make this happen. These are some of those thankless, seemingly obvious features that miss the spotlight but will have a big impact on Ark, Lightning, and more.