Hi Dario, Sorry for the latency in reply to the reaction about the full-rbf setting I've initially pushed in 0.24, TABConf week has been a busy one.
>From my understanding, there is no disagreement from Muun wallet about the gradual deployment of full-rbf by Bitcoin Core nodes, this is more a question of timeline to allow the zero-conf apps ecosystem to do the overhaul required. To recall, my initial motivation to deprecate opt-in RBF over the whole network is to mitigate a low-cost and easy DoS vector affecting the funding phase of multi-party contracting protocols: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html As of current, upcoming Bitcoin Core 0.24 release, a `mempoolfullrbf` setting is introduced defaulting to false. This option allows a node to accept transaction replace-by-fee without requiring replaceability signaling. If we assume a reasonable social inertia among Bitcoin Core node operators, full-rbf transaction-relay paths should be rare. To palliate to this concern, the introduction of a temporary `NODE_FULL_RBF` service bit and automated preferential peering is proposed with: https://github.com/bitcoin/bitcoin/pull/25600 This PR doesn't make the assumption that full-rbf is wished by the majority of the network of node operators and rather favors an opt-in full-rbf deployment. The existence of few full-rbf transaction-relay paths and mining hashrate is sufficient to achieve mitigation of the DoS vector. As #25600 boosts the deployment of full-rbf transaction-relay paths, and induces a side-effect of a weakening of zero-conf apps, I can understand this is not the approach offering the more visibility and predictability to zero-conf operators. Since then two more approaches have been proposed, a 1st one turning on by default `mempoolsetting`, at best to land in 25.0, i.e ~6 months now following the usual Core release schedule: https://github.com/bitcoin/bitcoin/pull/26305 A 2nd one making full-rbf by default at a flag day target, 1st May 2023, aimed to land in 0.24, and as such giving a clear time point to zero-conf node operators now. A third option proposed has been to withdraw `mempoolfullrbf` setting for 0.24, now withdrawn by its author: https://github.com/bitcoin/bitcoin/pull/26287 While in theory, the release process about new policy changes should stay flexible to correct the unforeseen impacts of policy changes, in the present case the implications on zero-conf services have been raised early on when the changes were brought in Bitcoin Core, i.e 4 months ago. Communication has been posted on this venue to invite zero-conf node operators to express concerns at that time: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html On a procedural point, I think this is a reasonable standard, navigating in an area where there are not that many precedents about the deprecation of a Core policy rule. Asking to the wider community of zero-conf node operators, among all the approaches, what has the most likes and what other decision-making factors should be considered. It is especially interesting if a 6 month time buffer from now is sufficient for the zero-conf applications to upgrade, and if not what are the concrete engineering or operational bottlenecks. Best, Antoine Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Hello list, > > I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For > the past > few days we've been reviewing the latest bitcoin core release candidate, > and we > found some troubling facts related to the opt-in full-RBF deployment. > > We first learned about the opt-in full-RBF proposal last June when it was > announced on the mailing list. Closing the gap between the protocol's relay > policies and the miner incentives is inevitable, so it was a welcomed > addition. > Furthermore, allowing transaction replacements that remove the opt-in RBF > flag > was deeply problematic. > > At the time, we understood we had at least a year from the initial opt-in > deployment until opt-out was deployed, giving us enough time to adapt Muun > to > the new policies. However, when reviewing the 24.0 release candidate just > a few > days ago, we realized that zero-conf apps (like Muun) must *immediately > turn > off* their zero-conf features. > > I understand this wasn't the intention when designing the opt-in deployment > mechanism. Given this new information, do you see a path where we can > delay the > opt-in deployment and find a safer way to deploy full-RBF? > > It'd be great for this deployment to be a success so that we can continue > fixing > the remaining relay policy problems, such as package relay and the RBF > rules. > Maybe we could go straight to an opt-out deployment locked by code at a > certain > height in the future to give time to everyone and, at the same time, avoid > a > huge mempool divergence event? > > Below is our analysis of how zero-conf apps break with opt-in full-RBF. I > hope > it helps. > > Cheers, > Dario > > > # How do zero-conf apps work > > While the workings and trade-offs of zero-conf applications might be known > by > many in this list, it's useful to define precisely how they work to > understand > how they break. > > We call zero-conf applications to entities that accept on-chain payments > from > *untrusted parties* and will sometimes deliver the paid-for product or > service > without waiting for the transaction to be included in a block. > > Some examples of zero-conf apps: > > - Muun's submarine swaps for outgoing lightning payments > - Bitrefill's on-chain payments for gift cards and phone top-ups > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at > least > the two biggest bitcoin ATM manufacturers support this: Genesis Coin and > General Byte) > > All of these applications are receiving incoming on-chain transactions for > which > they don't control the inputs, and performing a risk analysis to decide > whether > they are ok with accepting the payment without confirmation. > > In practice, this works because once the bitcoin P2P network has fully > propagated a non-RBF transaction, you need the collaboration of a miner to > replace it, which isn't easy to get today. Even though many of the biggest > miners offer off-band transaction broadcasting services, they currently > won't > process conflicting transactions. > > Roughly, the risk analysis goes like this: > > 1. if an incoming transaction is RBF (direct or inherited) > --> too risky, wait for 1 conf (or more) since it can be replaced at > any time > 2. if the payment is for an amount greater than X > --> too risky, wait for 1 conf (or more), since the amount is worthy of > a > sophisticated attacker > 3. wait for full(ish) propagation of the incoming transaction > 4. if there's no double-spend attempt > --> accept 0-conf > > As with any other risk analysis, there's always a false-negative detection > rate, > leading to an expected loss, which the zero-conf app should be willing to > bear. > Notice that the expected loss is tunable via the amount X in the above > analysis. > > > # Why are zero-conf apps not protected with an opt-in deployment > > Full-RBF adoption works on three different layers: > > - The transaction application layer > - The transaction relaying layer > - The transaction mining layer > > If an application wants to replace with full-RBF an *outgoing* > transaction, it > will need: > > - An upgraded node that opted into full-RBF, from which it can broadcast > the > replacement transaction > - A connected component of upgraded nodes that opted into full-RBF, that > can > relay the replacement transaction > - A miner in that connected component with an upgraded node that opted into > full-RBF, that can mine the replacement transaction > > However, an application cannot control whether a replacement to an > *incoming* > transaction is relayed via full-RBF. As soon as a single application can > generate replacements easily via full-RBF, all other applications have to > assume > that any incoming transaction from an untrusted party might be replaced via > full-RBF. That is, for the application layer this is a forced upgrade. > > As soon as an unsophisticated attacker can use opt-in full-RBF, the risk > analysis performed by zero-conf applications stops working because the > transactions to analyze are all incoming transactions from untrusted > parties. > Since some wallets already implement cancel functionality for opt-in RBF > transactions, enabling the same functionality for every transaction > wouldn't > require much work, making canceling any unconfirmed transaction a one-click > experience. After this, the security model of zero-conf applications goes > from > "susceptible to attacks from miners" to "anyone can perform an attack, > with an > easy-to-use interface". > > That is, the opt-in deployment of full-RBF doesn't protect zero-conf > applications from having to turn off their zero-conf features very soon > after > the initial deployment. All mitigations are mostly ineffective against > untrusted parties. > > > # Other things we have to fix > > While it's clear how full-RBF breaks zero-conf applications, other more > subtle > things break in *many* wallets (Muun included). If given the opportunity, > we > would like to fix them before deployment. One could argue that these things > were already broken, but they get considerably worse as the network adopts > full-RBF (even with an opt-in deployment), so we should fix them. > > ## Mental model for unconfirmed incoming transactions > > Many wallets with support for on-chain payments (Muun included) show > incoming > external transactions in some way to their users before they confirm. This > is a > common practice because not showing them leads users to worry that their > money > disappeared (exchanges doing this is the #1 issue we have to deal with in > our > customer support channels). > > With full-RBF, wallets should make it extremely clear to users that > unconfirmed > funds are not theirs (yet). Otherwise, protocol-unaware users that are > transacting on-chain with untrusted parties can be easily scammed if they > don't > know they have to wait for a confirmation. Eg. in Argentina, it's pretty > common > to meet someone in person to buy bitcoin P2P for cash, even for newcomers. > > ## Block explorers as payment receipts > > Most wallets with support for on-chain payments (Muun included) use the > transaction view of a block explorer as a shareable payment receipt. The > sender > of an on-chain transaction usually shares this link with the receiver to > let > them know they made a payment. Protocol-unaware receivers sometimes take > this > link as proof of payment. > > Most explorers currently don't track payment replacements and, more > importantly, > don't warn users that unconfirmed funds are not theirs (yet). With > full-RBF, > wallets should either stop relying on explorers for this functionality or > wait > for them to support it explicitly. > > > # Impact at Muun > > Work to transition Muun from using zero-conf submarine swaps to using > payment > channels is ongoing, but we are still several months away from being > production > ready. This means we would have to turn off outgoing lightning payments for > +100k monthly active users, which is a good chunk of all users making > non-custodial lightning payments today. > > Furthermore, the more subtle fixes imply non-trivial amounts of product > work > that we cannot reasonably deploy before they start affecting users. > > While I cannot talk for other applications, there are many impacted in one > way > or another, and none of the ones I checked with were aware of this change, > or > its implications. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
