When you store wealth in bitcoin, eventually, you’re going to have to do an on-chain transaction. This is the process where you sign over rights to bitcoin, to move it from one wallet to another. To perform a valid transaction must set the amount, provide a signature from their private key, pay a fee to the miner and broadcast this information to the bitcoin network.
Transferring funds via the bitcoin network can take, on average, ten minutes to receive the first confirmation. Depending on the wallet or service you’re using, they might accept one confirmation or require up to six confirmations before they feel that payment is secured.
While it can take roughly ten minutes to secure your transaction, it depends on if your transaction is picked up by miners to add to the next block. Space in the finite amount of block space is determined by how many transactions are submitted into the mempool at the time and the fee cost you’ve attached to your transaction.
If your fee isn’t attractive enough for miners, they’ll ignore it and pool together the ones that offer the best return should they secure the next block. Dealing with an on-chain transaction means you have to deal with a fluctuating fee market that can sometimes price out your transactions, and the only trade-off is to be patient if you’re not willing to hand over additional funds.
If you’ve committed a transaction to the mempool and time keeps ticking, and you’re not getting picked up, you need not sit on the sidelines stranded. You can broadcast a new replace-by-fee transaction to entice priority into the next block.
Paying for your own bitcoin transaction is standard practice, but the idea of paying for transactions you didn’t broadcast is being entertained through different proposals such as SIGHASH_GROUP and ephemeral anchors.
What is a SIGHASH_GROUP?
SIGHASH_GROUP is the idea that a user can provide a way for the inputs of a transaction to divide the outputs of a transaction into non-overlapping groups.
An example would be:
- Input 1 can specify, “I’m starting a group of 3 outputs”,
- Input 2 can specify, “I’m using the same group as the previous input.”
- Input 3 can specify “I’m starting a group of 2 outputs”;
Each input can use the SIGHASH_GROUP flag to specify their signature is signing for the subgroup they’ve specified, and you have the option of picking a single output or all of them.
The idea behind this is that then you can use a signature to link a set of inputs and outputs via a signature in a way that’s more general than
- SIGHASH_ANYONECANPAY (since you can have many inputs attesting to the same subset of outputs),
- SIGHASH_SINGLE (since you can attest to multiple outputs),
- and SIGHASH_ALL (since you don’t have to attest to all outputs).
These SIGHASH_GROUP would offer much more flexibility on broadcasting to the chain and even some new fee optimisation tactics, especially for those who deal with on-chain and lightning, such as exchanges or power users like apps and businesses.
Using a SIGHASH transaction, you could, for example, broadcast a transaction that closes a lightning channel and commits to a dozen outputs that specify where the channel’s funds should end up. At the same time, that transaction could add additional inputs to cover fees and additional outputs to collect the change from those fees.
While SIGHASH_GROUP provides significant advantages, it will require pushing into production a soft fork consensus change.
What are ephemeral anchors?
Ephemeral anchors are another proposal to allow some transactions to be relayed even if they don’t pay any transaction fee, provided they’re relayed as part of a package containing a child transaction which pays a fee sufficient for the entire package.
The proposal is built on top of the v3 transaction relay proposal. A v3 transaction containing as little as zero-fee that has a zero-value output paying OP_2 as the entire script would be accepted when included in a relay package with a fee-paying child.
The OP_2 would function as OP_TRUE, allowing anyone on the network to use that output as the input to a child transaction. This allows anyone to create the fee-paying child, even if they don’t receive any of the other outputs from the parent transaction. This allows ephemeral anchors to function as fee sponsorship but without requiring any consensus changes.
Ephemeral anchors are similar to fee sponsorship but let anyone fee bump a transaction. The transaction being fee-bumped is allowed to contain zero fees when created. Because anyone can fee bump a transaction using ephemeral anchors, this mechanism can also be used to pay fees for the multi-input pre-signed transactions.
Ephemeral anchors are envisioned to be used with contract protocols such as the Lightning Network, where transactions are signed by the contract participants a long time before they are broadcast, preventing the participants from determining an appropriate fee rate to use before the on-chain update is required.
Any participant (or several acting together) can use the ephemeral anchor output as the input to a child transaction which adds fees when the transaction is broadcast. This is similar to the anchor outputs added to LN in 2021-22, based on the CPFP carve-out relay rule.
Comparing ephemeral anchors to SIGHASH_GROUP
Ephemeral anchors, by contrast, are just a relay policy level rule that a transaction may create a single 0-value output with sPK of OP_TRUE (the “ephemeral anchor”), and that that transaction won’t be rejected as being dust, provided that the tx that introduces the anchor pays 0 fees (so it is not profitable to mine on its own) and that it’s relayed as a package with another transaction that spends that anchor.
Ephemeral anchors aren’t a complete replacement for SIGHASH_GROUP, but an alternative, and there are cases where Ephemeral anchors cannot be used. As is the case, if one had two signatures, one signing with SIGHASH_GROUP, but the other signing with SIGHASH_ALL, it’s difficult to duplicate that behaviour exactly with ephemeral anchors.
However, it’s likely the only benefit of using SIGHASH_ALL is to reduce malleability risk.
SIGHASH_GROUP, would also have the advantage of allowing batching multiple unrelated pre-signed transactions, which could reduce transaction size overhead, reducing user costs and increasing network capacity. Second, it doesn’t require a child transaction, which would further reduce costs and increase capacity.
Why would you use ephemeral anchors?
So why would someone wish to replace the fee on transactions they may or may not have broadcast to the chain?
Speeding up transactions
Let’s say a user has paid you for a service you’ve rendered or a product you’ve sold them, and to that user; the transaction clearing is not time-sensitive, so they do not wish to pay the extra fees for space in the next block. However, if you, as the business or seller, would like a faster clearing time, you could use the ephemeral anchor to substitute that fee and have your transaction prioritised.
You might be happy to pay the additional fee to clear sooner and sacrifice some of the margin you made on the sale to secure the transaction sooner rather than later.
Subsidising transactions
Perhaps you’re an exchange or a business that is looking to remain competitive with others in your space; you could set aside a budget to use ephemeral anchors to cover users who wish to pay you or users who you need to pay and provide them with more value by lowering fees when transacting with you.
Exchanges or businesses that need to pay out several addresses at once could also batch transactions and optimise the fee to ensure they get the most value in satisfying users for the fee they are paying.
By offering a lower fee experience for certain users, you might, at a cost, secure a larger audience that, through scale or frequency of purchase, allows you to cover those costs.
Activating delayed transactions
Users could prepare a transaction or several transactions that are not time-sensitive and track the fee rate on-chain and only commit the ephemeral anchor to set the fee to clear those transactions when the fee rate is within a range they’re willing to pay to commit all these transactions into the next block.
Optimising the lightning experience
A user with a Lightning node that would like to open a channel with another user or users could sponsor those users’ fees to establish lightning channels and source liquidity from smaller Lightning channels.
Do your own research.
If you want to learn more about ephemeral anchors on bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research other sources, and you can start by checking out the resources below.
