Published on: 2022-12-13T04:01:50+00:00
A member of the bitcoin-dev community has set up a mempoolfullrbf=1 node to monitor full-RBF transactions and is logging replacement events. They are filtering full-RBF replacements and listing the replaced and replacement transactions on their website. Another member suggests grouping related replacements together and providing information on how long ago the replaced transaction was seen compared to the full RBF event timestamp. The member also suggests including this information for bip-125 opt-in rbf txs to show the frequency of the "offer a low fee, and raise it over time" approach.Bitcoin developer Peter Todd and 0xB10C discuss monitoring full-RBF transactions in an email exchange. 0xB10C's logs suggest that Luxor may have mempoolfullrbf=1 enabled as they have mined five full-RBF replacements in two blocks. AntPool's status is uncertain based on one transaction they mined. Block explorer Blockstream.info recently enabled full-RBF, but the propagation to their nodes can be sporadic. Todd has ported Antoine's preferential peering patch to v24.0 and suggests running it to focus on replacements rather than propagation. Foundry USA mined a doublespend, potentially due to accidental propagation.Peter Todd sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and logs them. The node accepts incoming connections and has not taken any special steps for peering with other full-rbf nodes. Over the last few days, the node has mostly seen OP_RETURN transactions, particularly OpenTimestamps transactions. Luxor may have mempoolfullrbf=1 enabled based on recent observations. So far, no full-RBF replacement transactions have been mined.0xB10C sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and lists the replaced and replacement transactions. The node does not take any special steps for peering with other full-rbf nodes and relies on good peering to receive all the replacements. The node has mostly seen OP_RETURN transactions, including OpenTimestamps transactions. Replacement transactions have not been mined yet. The OpenTimestamps transactions primarily make full-RBF replacements on two calendars.Peter Todd explains in an email exchange that censoring transactions on the Bitcoin blockchain is highly unlikely due to the decentralized nature of the network. He notes that there are thousands of listening nodes connected to the network, making it difficult for censorship to be successful. Todd also mentions the percentage of the network needed to run full-RBF for a node to connect to at least one full-RBF peer. He suggests running a full-RBF node that connects to every single listening node simultaneously. Todd provides a link to a percolation simulator for full-RBF.In an email exchange, Peter Todd discusses the risks of enforcing mempool consistency on the Bitcoin network. He notes that implementing such a rule could lead to unintended chain splits and may not be feasible as he does not have commit access to the main repository. Todd also explains the probability of censoring nodes successfully blocking transactions, highlighting the difficulty of achieving such censorship. He mentions the possibility of running multiple nodes with functionality to stop the propagation of full-RBF replaced blocks but acknowledges the challenges associated with this approach.The bitcoin-dev mailing list discussion focuses on the importance of proof of work for building consensus-accepted blocks and the risks associated with enforcing mempool consistency through a consensus rule. Some contributors argue against enforcing mempool consistency, citing potential unintended chain splits. Others suggest working on a Bitcoin Core implementation that stops the propagation of full-RBF replaced blocks, but political difficulties arise due to commit access limitations. The conversation also touches on attacks on opt-in RBF and 0Conf bitcoin usage, as well as ad hominem attacks towards Daniel Lipshitz.A discussion on the bitcoin-dev mailing list addresses concerns about a proposed change to the Bitcoin network, which some believe would lead to centralization and fail to achieve its intended goal. The possibility of sending transactions directly to miners is discussed, with one participant noting the difficulty of different miners having conflicting opt-out-rbb transactions. Enforcing mempool consistency through a consensus rule is debated, with warnings about unintended chain splits. The discussion also touches on Peter Todd's attack on opt-in RBF and 0Conf bitcoin usage, suggesting a solution to stop the propagation of full-RBF replaced blocks. However, implementing this solution may be politically challenging.The bitcoin-dev mailing list conversation discusses the risks associated with enforcing mempool consistency on the Bitcoin network and the challenges of implementing such a rule. Concerns are raised about unintended chain splits and the difficulty of making a consensus rule that enforces mempool consistency. The risk of double-spending transactions is also highlighted when conflicting transactions are broadcasted with minimal fees. Peter Todd's efforts to attack opt-in RBF are mentioned, including the donations he received for his work.
Updated on: 2023-08-02T08:24:00.883108+00:00