Published on: 2017-12-23T18:33:21+00:00
A recent discussion has arisen regarding the removal of the "no-RBF" flag in Bitcoin transactions. The flag is believed to confuse new users about the security of 0-conf transactions. It is assumed that miners are profit maximizers and will replace low fee transactions with higher fee ones, making full RBF a de facto policy in Bitcoin. Therefore, it is recommended to remove the flag and adopt full RBF as the "de jure" policy. However, there are legitimate reasons why people use non-RBF transactions despite their poor usability. If people want to overpay on fees for these transactions, there is no reason not to let them. A recent pull request has been submitted to turn on Replace-by-Fee (RBF) by default. This has sparked some discussion, and a no125=1 flag was suggested to accommodate merchants who don't want their customers to use RBF. When this flag is set, wallets should not use RBF unless the user explicitly overrides the merchant's preference. However, objections have been raised against this suggestion, stating that there is no reason to avoid the RBF flag and it doesn't reduce the risk of double-spending. Some miners also allow RBF regardless of the flag, making it less effective in preventing malicious double spending.In a separate discussion, the possibility of reusing sections of Bitcoin Improvement Proposals (BIPs) for other purposes was explored. It was agreed that not all BIPs would be suitable for this, but it is worth considering for some. One suggestion was to reuse a section of the payment request URI for multiple purposes, such as Confidential Transactions (CT). However, it was noted that any ignored flags would need to be clearly defined in the BIP to ensure proper behavior.Another alternative solution was proposed in a discussion about using flags to disable specific operations. This involved having an "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP. However, it was acknowledged that not all BIPs would work with this pattern and each ignored flag would require carefully defined behavior. It was also mentioned that this BIP may soon be superseded entirely due to discussions of variations on BIP-71.There was also a discussion about the use of bech32 addresses, with questions raised about the need for a param when bech32 addresses are just normal addresses. The idea of using a backwards compatible P2SH address with a param to allow modern wallets to use bech32 was introduced. This is encouraged as it is cheaper for the recipient to spend these funds, but merchants can eventually drop support for old wallets once the new format has sufficient adoption.In summary, there is ongoing debate about the removal of the "no-RBF" flag in Bitcoin transactions. While some argue for its removal and the adoption of full RBF as the default policy, others believe there are legitimate reasons to continue using non-RBF transactions. A pull request to turn on RBF by default has been submitted, but concerns have been raised about how this will affect merchants. Suggestions have been made to accommodate merchant preferences through the use of flags in the URI. Additionally, discussions have taken place regarding the reuse of BIP sections for other purposes and the use of bech32 addresses.
Updated on: 2023-08-01T22:16:34.514348+00:00