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