Breaking Through Congestion

As Bitcoin’s blocks begin to fill, there will be more transactions waiting to be confirmed than space allows. This will cause congestion and a poor user experience. Transactions will sit unconfirmed and never clear. People will get their money stuck and be unable to access it or have the receiver receive it. However, a few changes to Bitcoin can drastically reduce the negative effects and effectively break through congestion.

Transaction Basics

If you already understand the basics of transactions, skip this section. However, it provides an overview for understanding the basics needed to fully understand current and proposed behavior.

Unconfirmed vs. Confirmed Transactions

Bitcoin exists by allowing users to send a transaction to other nodes. The act of sending a transaction does not guarantee that it will be accepted by the network, even when it is valid. Bitcoin determines consensus through Proof-of-Work, which forces miners to spend some amount to decide what transactions should be included in the next block. Miners choose through the set of transactions they have received (mempool) and determine based on their own criteria, such as if it has enough fees or if it is not considered spam, which transactions should be included. There is no requirement to include any set of transactions.

Inputs and Outputs

Each transaction consists of a set of inputs and a set of outputs. Inputs are sources of funds with outputs being the destinations. Each output can then be spent as an output into the future.

Controlling the Mempool

The mempool is the set of transactions that nodes recognize as it’s preference for including in the next block. Miners will use the mempool to determine what is mined. Since miners cannot include two transactions with the same inputs into a block, they must filter transactions that contain the same input repeatedly.

First Seen

This is the default behavior of Bitcoin. A node will keep track of every transaction it sees. If the inputs have never been used before, it keeps the transaction in the mempool and relays it to other nodes. If the inputs have been seen before, the transaction is rejected and not passed to other nodes. This behavior makes unconfirmed transactions appear to be safe. This isn’t always the case. Transactions could be sent in parallel to different parts of the network, and nodes would disagree what was seen first. This is why mining is so critical — it resolves the conflict of which transaction was actually seen first. This means that each node could have a different opinion on what it saw first, even when they are truthful. If unconfirmed transactions could be agreed upon for which came first, we wouldn’t need mining. Unconfirmed transactions are also safe because nodes and miners may not follow this convention. Furthermore, since these nodes aren’t being truthful, there is no way to punish dishonest nodes, as they are indistinguishable from nodes that were simply attacked.

With first-seen, a transaction without proper fees will sit in the mempool, at the back of the line, unconfirmed, with users unable to confirm, and unable for a user to access the funds, since any updated transaction gets rejected for re-using an input.

Child Pays for Parent

https://github.com/bitcoin/bitcoin/pull/1647

Child pays for parent is a patch introduced by Luke Dashjr that allows miners to re-prioritize the transactions to include in a block by considering the sum of fees of chained transactions. For example, transaction X takes funds from A and sends to B, but it has no fee. A merchant wants to receive the funds and is willing to pay a fee, so he creates transaction Y, which sends from B to C (both addresses he controls) with a fee high enough to cover both transaction X and transaction Y. A miner will see this child transaction, determine that the fees are sufficiently high, and move the transaction up in the queue.

This patch is useful because it does not require relay nodes to change their rules for what transactions should be included. However, since you now must pay the fees for an entirely new transaction in addition to the original, this method will be more expensive. It also does not alter security of zero-confirmation transactions.

Replace-by-fee

https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2

Replace-by-fee is a patch introduced by Peter Todd that allows miners to choose transactions that provide the most fees, regardless of order seen. This patch has generated some controversy, especially when adopted temporarily by F2Pool due to the way zero-confirmation transactions are now treated by the network. In the example of congestion, if a user puts too low of a fee on a transaction, he could decide to re-broadcast a transaction with a higher fee. Nodes that use replace-by-fee would prefer the second transaction, and prioritize it based on the new fees. However, this behavior could also be used to exploit those who accept unconfirmed transactions. Rather than sending to the same outputs, this patch allows for sending to completely different inputs. A malicious user could send a transaction with a small fee to a merchant, receive his goods, then rebroadcast an additional transaction with a larger fee that instead pays himself. Miners that have implemented this patch would choose the “self-payment”, leaving the merchant empty-handed

This patch has the advantage of being the lowest fee for users, as users could rebroadcast a transaction only altering the fee without increasing the size of the transaction.

Replace-by-fee Scorched Earth

Combining Replace-by-Fee and Child Pays for Parent, a defense exists for merchants who are attacked by a double-spend attack. Consider the case where a customer pays with Transaction X to the merchant, but then double-spends with a higher fee using Transaction Y back to himself. In this case, the merchant can make Transaction Z, which spends the output of Transaction X with higher fees. The thief could retaliate with even higher fees, but the end-game of this scenario is the neither the thief nor the merchant end up with the funds. By being able to discourage such an attack, even by not recovering money, it makes it unwise for an attacker to use this attack. However, an attacker who wishes just to harm the merchant without regard to cost would not be deterred.

First Seen Safe Replace by Fee

This patch, also introduced by Peter Todd, provides a more restricted set of rules for replacing transactions. This applies the replace-by-fee rules, but only in the cases where every output is at least as big as it previously was. This behavior will not impact zero-confirmation security, while giving an option for those who want to increase fees to force a transaction through congestion. Users cannot double-spend to benefit themselves, but only to increase fees. This limitation is not without cost, as it requires an additional input to be added to the transaction. This will increase the cost of the transaction fees needed to push it through compared to a strict replace-by-fee patch, which typically would not need to add inputs. F2Pool settled on using this patch to avoid upsetting users.

Miner Game Theory

Miners will choose how they handle including transactions. While they do have an incentive to increase the value of the Bitcoin network with time, they also are at a disadvantage to any miners who implement policies that increase revenue, even if it harms the Bitcoin ecosystem as a whole. This is the prisoner’s dilemma — where each actor wants the others to co-operate and everyone is better off under co-operation, but defection is the rational action of any individual participant. Prisoner’s dilemma is solved through binding agreements, but if defection cannot be detected, it is impossible to enforce. Since it is impossible to detect a miner that is being attacked from a malicious miner, such agreements and punishments will only benefit futher attacks.

Instead, we must assume every actor in Bitcoin is trying to lie or exploit us. By doing so, we increase our own security and the security of the network. We must weigh this against short-term problems like the transition period to remove any dangerous assumptions, such as safe unconfirmed transactions. The FSS-RBF patch is a great example of a responsible way to transition through this period, although we cannot guarantee that miners will follow this nor can we detect when they use other methods that would maximize revenue. Bitcoin can and will thrive despite bad actors, so we must be vigilant in what assumptions are being made so that we don’t require trust.