Author: Antoine Riard 2022-10-19 03:01:12
Published on: 2022-10-19T03:01:12+00:00
The discussion in #25600 is centered around the impact of Full RBF and its adoption by 10% of hashrate. There are concerns about potential policy-based disruptions for current Bitcoin software and users, and a need to find a common ground on what should be a minimal bar to accept data points and how to value those data points. The communication machine behind softforks activation sounds to be far more fine-tuned than policy changes. Antoine Riard, a Bitcoin developer, has invited John Carvalho to further develop his argument against full replace-by-fee (RBF) and stated that he is available for discussion with any opponents in a calm and respectful manner. The discussion is centered around the three possible approaches to handling unconfirmed transactions: continuing to support them indefinitely, drawing a line in the sand now but giving time for businesses to update their software, or immediately encouraging mainnet miners and relay nodes to support unconditional RBF.There are concerns about the risks of implementing full RBF immediately without clear warning of changes, as there is a possibility of zero-conf apps being in immediate danger. Dario's email has shed new light on the subject, acknowledging that full RBF to align miner incentives is acknowledged in the long term, and a clear timeline based on a block height is favored over the pollination deployment. It is predicted that if core is released with full RBF support, it will be usable on mainnet within two to three months, supported by 5%-20% hashpower, but may still require special effort to find a peer that can relay full RBF transactions to that hashpower.The discussion revolves around the delay in implementing zeroconf and how it affects bitcoin businesses/users. The delay is seen as a big win for those who have been doing zeroconf, but it also poses a risk to bitcoin businesses/users who rely on the feature. The PR (#26287) to disable this for mainnet, reconsider after the release, has not gone ahead despite the delay. The tie-breaking between both options seems to favor #26323 but only post 24.0 to avoid introducing a bikeshedding precedent in terms of release process.However, this does nothing to mitigate the immediate risk to bitcoin businesses/users. If the choice is between "bikeshedding" and "merge a PR, then ignore feedback that it's harmful", the former is preferred. The negative feedback regarding the delay should not be ignored if we want to avoid putting zeroconf apps in danger. There is a need for a better communication standard when proposing significant policy changes, and a formalized approach with clear time buffers and action items. Feedback needs to be established earlier to avoid disingenuous claims and minimize risks. Engineering standards expectations need to be fulfilled rather than falling back on the pure expression of uncomfortableness. Finally, reasonable time to react and adequate risk statement is more an art than a science.
Updated on: 2023-06-16T01:00:57.474193+00:00