Published on: 2022-11-07T11:46:28+00:00
Antoine Riard has proposed a solution to the denial-of-service (DoS) issue in an opt-in replace-by-fee (RBF) world for coinjoins, splicing, and dual-funded transactions. His proposal involves deploying a distributed monitoring system called "mempools watchdog" to track network mempools. However, this infrastructure is vulnerable to mempool partitioning attacks by adversaries. To address this problem, victims could outsource the monitoring to dedicated entities, but there is a lack of compensation mechanism, resulting in few public options.Another challenge discussed is assigning blame reliably among trust-minimized joint funding protocol participants. This issue arises when multiple double-spends occur from sybilling participants, aiming to halt the assignment process. One suggestion to avoid this situation is for participants to not sign conflicting transactions, indicating their desire to remain part of the group. If someone does sign it, it signifies their intention to leave the group. Additionally, if participants want to abort the coinjoin but stay in the group, at least 51% of the remaining group members must agree.In a full RBF world, any participant should be able to fee-bump the joint transaction. However, it is advised to avoid coinjoins with an excessively large number of untrusted counterparties. In such cases, it is better to exclude cheating participants and split the remainder into smaller groups until a more reasonable size is achieved. Broadcasting a double-spend with an equivalent fee rate as the honest transaction does not tighten the attack scenario because the attacker can still employ low fee rate pinning that cannot be recovered by fee bumping the alternative.Anthony Towns discusses solutions for a DoS attack in the opt-in RBF world. The attack targets joint funding protocol participants and requires distributed monitoring of network mempools. However, this mempools watchdog infrastructure is susceptible to partitioning attacks, where adversaries manipulate local node mempool views. Outsourcing mempool monitoring encounters the issue of limited public resources and single-point-of-censorship vulnerability. The economic scalability of defensive infrastructure is also a concern due to the ongoing cat-and-mouse game between victims and attackers. Assigning blame reliably among joint funding protocol participants is another challenge, and introducing a UTXO-satoshi-weight vote is suggested for efficient assignment convergence.The discussion on the bitcoin-dev mailing list delves into handling conflicts when revalidating transactions without access to the transaction itself. One approach proposed using BIP 37 mempool filters, but this compromises privacy by revealing information to attackers. Investing in hashpower was suggested as an alternative solution, particularly when working with untrusted peers. Privacy-conscious individuals can run anonymous bitcoind nodes to check their mempool content. To facilitate this, transaction broadcasts can be made more private using methods like Tor/i2p or Dandelion. Querying an explorer or centralized service is also an option if privacy is not a concern. Overall, the aim of the discussion was to find better solutions for handling transaction conflicts in Bitcoin.The bitcoin-dev discussion revolves around assigning blame in coinjoin-like protocols and proposes using Tor hidden services (HS) to ping explorers. However, privacy methods like coinswap cannot utilize Tor HS. As the size of the coinjoin increases, the risk of gossiping a duplicitous double-spend among peers also rises. DoS concerns are less pronounced in dual funding Lightning Network channels due to the relatively small number of participants. Joint funding protocols can address the problem of opt-in RBF availability for coinjoins, but participants must maintain dedicated hashpower. Alternatively, anonymous Bitcoin nodes can be set up to query their mempools and mining pools for transaction confirmation. However, outsourcing this process is challenging unless privacy is not a concern. In that case, utilizing public explorers or centralized services to identify conflicting transactions is an option. Making transaction broadcasts more private using Tor/i2p or Dandelion can facilitate running anonymous bitcoind nodes. Investing in hashpower or running anonymous nodes are viable options to ensure transaction confirmation for untrusted peers.The email thread on bitcoin-dev focuses on joint funding protocols and detecting conflicts to ensure transaction confirmation. The main goal is to confirm transactions, but identifying conflicting transactions can also expose dishonest participants. One approach discussed involves setting up anonymous bitcoin nodes with realistic mempools and broadcasting the jointly funded transaction, then querying their mempools to check if the new transaction made it there. If not, it is highly likely that the blocking transaction is present. This method requires fewer capital expenses compared to maintaining dedicated hashpower but relies on the public peer-to-peer network to relay the transaction. For those unconcerned about privacy, querying an explorer or centralized service for conflicting transactions is an option. Running "anonymous" bitcoind nodes that don't announce transactions can provide a more private solution. It was suggested that making transaction broadcasts more private could facilitate running anonymous bitcoind nodes.
Updated on: 2023-08-02T08:22:02.569157+00:00