The CEO of Synonym presented the BIP “User-Defined Transaction Flags Policy & Strategy”: the reasons and reactions.
On 15 April, John Carvalho, well-known bitcoiner and CEO of Synonym, presented a new Bitcoin Improvement Proposal entitled ‘User-Defined Transaction Flags Policy & Strategy‘.
The proposal stems from the long debate between Peter Todd and John Carvalho on the introduction of the -mempoolfullrbf=1 option in Bitcoin Core version 24.0.1. The mempoolfullrbf option allows full-node operators to ignore the RBF flag on transactions and accept replacement transactions in their mempools, regardless of whether the original transaction was flagged with that flag or not.
Currently, the majority of nodes have decided to implement the -mempoolfullrbf=1 option.
The goal of Carvalho’s proposal, according to him, is to improve user autonomy over transaction control and network efficiency through precise, user-defined transaction flags that fit perfectly with the decentralised nature of Bitcoin.
This proposal aims to introduce a new flag called DNR (Do-Not-Replace) for onchain transactions. The DNR flag would ensure that transactions are not replaced once they are transmitted to the network. The flag would be encoded using a specific bit in the transaction field, similar to what happens with the RBF flag, but with reverse logic.
In this way, 0-conf transactions would be flagged directly by the user making the transaction. However, the flags are only hints and can be ignored by miners, which means that they are not binding.
According to Carvalho, the only correct way to integrate DNR would be to implement it user-side:
“this approach involves creating and default-obeying various transaction flags like RBF and DNR to facilitate specific goals of transactors. The primary tradeoff is that these flags are suggestions and can be overridden by miners, which means they are not enforceable but serve as strong hints to improve transaction predictability and network efficiency. This approach enhances user experience and network functionality without overly complicating the Bitcoin protocol or risking centralization. By standardizing flags that indicate user preferences, we can achieve greater harmony and utility within the Bitcoin network, supporting diverse user needs while maintaining decentralization.”
Use cases of DNR
In the proposal, Carvalho refers to three use cases where the use of DNR could prove useful.
- In-store transactions: merchants or service providers accepting payments in bitcoin need transactions to be confirmed immediately to prevent fraud. By using the DNR flag, merchants can ensure that once a transaction is transmitted, it cannot be replaced;
- Payment of salaries: employers paying salaries in bitcoin require certainty that transaction amounts cannot be altered once sent. The use of DNR gives employers the security of executing transactions knowing that payments cannot be replaced or cancelled with a subsequent transaction, ensuring employees receive the exact amounts expected;
- Payment of subscriptions for services: subscription services where automatic payments are scheduled and should not be subject to change once started. The use of DNR can be applied to ensure that automated recurring payments are processed without the risk of being replaced, thus simplifying financial planning and contract enforcement.
The most common criticism of the use cases presented by Carvalho is that Lightning Network already solves all three cases. One of the uses of LN is precisely for transactions that require immediate confirmation.
Reactions to the proposal
The presentation of the proposal met with comments from the Bitcoin community on X.
The user lorenzoreybtc said:
The user BitcoinMotorist stated:
