This article comes fromMediumThis article comes from
We focused on building a non-custodial relayer—Infura Transaction Service (ITX), which takes a pre-signed message (such as a meta transaction) and packages it into an Ethereum transaction, and then gradually increases the transaction fee until it be billed.
secondary title
Why should we care about repeaters?
We want businesses to be able to provide reliable transaction delivery as a service. Relayers help alleviate the fundamental problem of competition in the global block space fee market, they are good at selecting relay strategies based on the priority of transactions. For example, a relayer might be optimized for fast delivery if users are exchanging tokens on an automated market maker model, or for lower transaction fees if users are voting in a DAO.Can we build relay services in Bitcoin? What kind of problems can arise?
secondary title
What properties should a repeater have?
When building ITX, we focused on the following four properties:
There is no custody. ITX never has access to or control over users primary funds.
non-interactive. ITX participates in the global block space fee market without constant user interaction.
No initial setup is required. Users do not need an initial setup phase to use the relay service.
Repeater payments. It is the relayers who pay for the network, not the users.
Three of these properties are simple. Relayers should never have access to users primary funds, users should be able to go offline while relayers are sending their transactions, which is ideal if not using the relayers initial setup.
This leads to the next question:
secondary title
Should the relayer or the clients on-chain funds be used to pay for this transaction?
This is easy for Ethereum, but not so easy for Bitcoin. The common claim that relayers pay network fees is to solve protocol (or escrow) problems for users. The key example is ERC20 transfers that support reduced gas, as users may not have enough ETH to pay network fees, but they can be refunded to relayers via ERC20 tokens. However, the same use case exists for Tether on Bitcoin, although an ecosystem has not yet evolved for it. We guess that repeaters will pay network fees for users as long as they can get revenue from the service.
Next, lets take a moment to review some background information on Bitcoin transactions.
Bitcoin transaction (UTXO) background
image description
Figure 1: A Bitcoin transaction has a list of inputs and outputs
A Bitcoin transaction has a list of inputs and a list of outputs:
Outputs (UTXOs) are associated with some tokens and a claim script that establishes a set of conditions that must be met in order to spend those tokens.
An input references an unspent output and provides a redeem script, which is proof that the conditions for using the token have been met.
As we can see in Figure 1, the first input of transaction 2 references the first output of transaction 1. The other two inputs to transaction 2 are not shown in the picture because they are from different transactions. When transaction 2 is processed by the network; it effectively executes each input-output pair to verify that 0.5 BTC, 0.8 BTC, and 0.3 BTC are available for that transaction.
There are three aspects of Bitcoin transactions that are important to fee replacement protocols:
Script flexibility. Transaction inputs and outputs create a script. Most scripts require a single signature to authorize a transaction, but it can use other conditions, including multisig, valid after time T, and if the hashs preimage is compromised.
Enter redemption. Each input of a transaction can be redeemed by a different party, and the inputs are only valid if all parties agree on the transaction template (e.g. if a transaction has 3 inputs, each input script).
The SIGHASH rule. A user signature authorizing a transaction can cover one or more inputs, and one or more outputs.
What is a transaction fee? What is its definition? There is no explicit UTXO or field for a transaction fee. Its definition is:
tx_fee = total_inputs - total_outputs, where tx_fee ≥ 0.
For example, if the inputs represent 1 bitcoin in total and the output sends 0.9 bitcoins, then the transaction has a fee of 0.1 bitcoins. To adjust the network fee - the signer must redefine the transaction output to subtract the total number of tokens sent, and then re-sign the transaction.Finally, Bitcoin has no account system. Instead, there is a global set of UTXOs that define the list of transaction outputs that can be spent.
Each UTXO is associated with a claim script and some bitcoins. Each block removes spent transaction outputs from the set, and then appends new spendable outputs to the set.If a user sends 5 bitcoins to a counterparty to the same address, but in a different transaction, then the counterparty will need to manage 5 unspent transaction outputs. This is a problem for Coinbase as they have 265 BTC out of 1.5 million UTXO.
Repeater fee output
image description
Figure 2: Relayers include an additional output in transactions to pay fees
In order to satisfy the relayer payment property, the relayer must include a UTXO in the clients transaction. As shown in Figure 2, the relayer inputs 0.3 BTC and the relayer receives 0.1 BTC, so they have allocated 0.2 BTC for transaction network fees. For simplicity, we will refer to this as the forwarder fee output.
However, there are some subtle pitfalls to consider:UTXO management.
Forwarders must ensure that each fee output has enough funds to cover the transactions maximum cost. If a set of fee outputs becomes insufficient, they may need to be periodically batched; if the fee output contains too many tokens, the fee output needs to be split. All management requires on-chain transactions, thus imposing an economic cost on relayers.Concurrent relay transactions.
If we assume that a user uses only one fee output per pending transaction, then the number of concurrent transactions that the relay layer can manage at any time depends on the number of fee outputs available. For example, if a relayer has 10 UTXOs with 1 BTC per UTXO, then they can support sending 10 relay transactions at any one time. Unlike account-based systems, it does not necessarily depend on the total amount of funds held by relayers. Therefore, the UTXO management method of the relay directly affects its service quality.It is not safe to chain pending transactions.
Of course, if the client is paying network fees, then the relayer does not include the input of the transaction. According to the agreement, customers can use their own funds to create additional forwarder fee outputs. This way, clients can allocate funds to relayers and add transaction fees. Any funds left over from mining transactions can be rewarded to relayers.
secondary title
Native Replacement by Fee Flag in Bitcoin Transactions?
BIP125 implements an optional fee replacement flag for transactions so that fees can be increased at any time while the transaction is still unconfirmed in the mempool.
The protocol is fairly straightforward.
Optional: Repeaters provide users with an input that can be used to pay network fees.
The user signs several transactions, each with a higher fee than the previous transaction.
Users send all transactions to the relayer.
A relayer broadcasts the first (lowest fee) transaction, and then steadily publishes subsequent transactions with progressively higher fees.
I suspect that if there were a relay as a service, it would be the first and easiest to implement for most cases.
If a transaction is marked with RBF, it is recommended that you not easily believe that it is 0-confirmation. BIP indicates that if the RBF=on of the first transaction and the RBF=off of the replaced transaction, then the transaction is still replaceable. So if you just validate the transaction you received to check that RBF=off, then you can still be fooled!!
Son pays for father transaction
image description
Figure 3: The relayer broadcasts a second transaction, the child transaction pays the parent transaction, which overrides the fees of both transactions
Figure 3 highlights that child elements pay for parent elements. It allows the second transaction to provide a network fee that covers the cost of two pending transactions (e.g., itself and its parent transaction). Assuming miners evaluate the chain of pending transactions, it should induce miners to include both transactions in the same block.
We can take advantage of child pays for father by including a relay fee output in the first pending transaction. As mentioned earlier, the tokens used to fund this output may come from relayers or clients, but relayers will have full custody of the fee output. If the first pending transaction gets stuck on the network, then the relayer can use the anchor output to create a second transaction to cover the network fees for both transactions.
The protocol is simple:
Optional: Repeaters provide users with an input that can be used to pay network fees.
Clients create, sign and send transactions to relayers. It includes additional relay fee output.
The relayer broadcasts the transaction to the network, monitors the transaction, and only sends the second transaction if the fee needs to be challenged.
If there is no fee increase, and the users transaction is mined, then the relayers fee output can be used for the next customer.
The downside is that transactions are larger (dedicated relayer outputs) and fees may need to cover two transactions instead of a single one.
secondary title
The magic of SIGHASH
In some cases, users only want to sign a combination of inputs and outputs of a transaction, and do not care about signing the entire transaction. Users can declare a SIGHASH rule that dictates which information in transactions the user will sign.
image description
Figure 4: Fields in yellow are signed by the user with SIGHASH_SINGLE
SIGHASH_SINGLE: The user signs all inputs, but only one output.
The incomplete transaction template is sent to the relayer responsible for including the second output and authorizing the transaction. Without the signature of the relayer, the transaction is invalid; therefore, there is no risk of miners mining the transaction and stealing the funds invested by the relayer. Also, the SIGHASH flag can be different for each input. Therefore, when the user uses SIGHASH_SINGLE, the relay layer can simply use SIGHASH_ALL (the default option).
image description
Figure 5: The bug in SIGHASH_SINGLE implies that the user needs a dummy input to return change
The SIGHASH_SINGLE implementation has a bug (Bitcoin is indeed an incomplete Frankenstein system), so even if there are no corresponding outputs signed by the inputs (e.g. the number of inputs exceeds the number of outputs), the transaction is still valid. Check the bug report to find out why.
Therefore, if we wish to support changing output for the user, the user must include a second dummy input that also uses SIGHASH_SINGLE.
Other than that, the protocol is straightforward:
The relayer must provide an input for the user to include in the transaction for the relayer to re-sign the transaction for RBF.
The user creates a transaction template with 3 inputs and 2 outputs. The first output sends the tokens to the destination, and the second output refunds the remaining changes. The third input is the relayers anchor UTXO.
The user provides a signature for each input using the declared flag SIGHASH_SINGLE (Figure 5).
Users send partially signed transactions to relayers.
The relayer creates a third output, which returns to the relayer and pays the transaction network fee. Their inputs are signed with SIGHASH_ALL and the transaction is broadcast to the network.
To add fees, relayers can simply adjust the third output, re-sign the transaction, and broadcast it.
secondary title
Summarize
Summarize
Weve covered three approaches to supporting third-party relays in Bitcoin, and we can make a simple comparison of them based on initial properties:
There is no custody. In all solutions, relayers never have access to users funds. However, if a user funds a forwarders fee output, trust the forwarder to choose an appropriate fee.
non-interactive. From the users point of view, all solutions are non-interactive, as they only need to provide enough information before going offline and letting the repeater take over. The replace-by-fee method does require a lot of setup by users though, as they need to pre-sign the list of transactions and send them to the relayer.
No initial setup is required. All methods do not require users to do initial setup before interacting with the relay layer, we define users as on-chain transactions.
secondary title
What can go wrong?
Alternative method by fee versus SIGHASH. I think the sighash_single method is an optimization over the per-fee alternative. Instead of requiring users to pre-sign a list of transactions, it lets relayers accept a single transaction signed by a user and then append the transaction fee to that list of transactions. It might be wise to look into a new sighash rule called SIGHASH_MULTIPLE that allows users to sign a set of inputs/outputs and gives relayers more flexibility in attaching network fees to pre-existing transactions.
secondary title
Can we mix these approaches?
