From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Jun 2026 00:35:03 -0700 Received: from mail-oi1-f192.google.com ([209.85.167.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wXwPu-0001C7-KF for bitcoindev@gnusha.org; Fri, 12 Jun 2026 00:35:03 -0700 Received: by mail-oi1-f192.google.com with SMTP id 5614622812f47-4863abb79b0sf2615002b6e.1 for ; Fri, 12 Jun 2026 00:35:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781249696; cv=pass; d=google.com; s=arc-20240605; b=lyWHSqGTsOrSa0DCsSbZKNxNKbj4iiNTgFElQWaiHkErMw1dV64VfD2x9h3J6E+otx OjJy4ns4LS+0vsCRLFLjSF1krU9LMwK0BdeMRQnhVOFGTsrGJd5osDAhGyMXLe141vXx J7qh+PhMzRdf2kvuTBTFaBxL7ec2ucbU7YFaxe4VFlDPDXRNAggwtTy0BE4IcHAal8c+ 8bQ74PBzFtkEAbrDzQss6aW7FS63HUVd6+liGEGTC8JgLCel/GwHJ60jKoJ948iMIbYG 8+ZOw2PI9gIUdCZFFbgo6gxrOBRfggQRk0L14TPOqgFXr6gvCICuratUnn4P7e+Gmncu 9SEg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=0xGyDNl5ogOQbdawWazKlNM531Ep7GOTwGMofOmo3ME=; fh=9hCAvu6006OvSj9Vskm8r5O3SaSQ8MaqrGSmylKDO3g=; b=Em0T0YO+SkOknIgXI08L4qzana3ARZb25R+C6WLZrsT7xpWR+jVofiNwAcWC6Ti7BC yfbIA+VtKcfLPSUxrXAPKtr/85bEUG8VvRFFYebaYImG8zHpDCoY/kXMMgt/oVa09x1y hJy4ifhhCuNBVtz47YeUinnxc1TrdCILEJ5bja80qsoERCQfIrdWp5hrGmMlVFd1RoJb JeiDAHILorVckTeITGCFHaM0zxGlBmJHjtwhjZW7c9vOWS+53Ut9j6T0W9iLdZbZAP3l 20KHTbOxr2+wXN1JOdZv0GkqzW1Z4wfv8DLicZpPaOEszYrviPlKHkNRQt0qFCHEV9ok fG9Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=V+9EW2cA; spf=pass (google.com: domain of somber.night@protonmail.com designates 79.135.106.96 as permitted sender) smtp.mailfrom=somber.night@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781249696; x=1781854496; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=0xGyDNl5ogOQbdawWazKlNM531Ep7GOTwGMofOmo3ME=; b=QLsy4ezT76BCcACAWHH+ZOgmWYEm8nAV/tERpE7QM3wJm00ibXRg+p0eF/R9B9gVPV wDvZSjVq1qPztxMweu2wj7NUp1QEMni7vsDpeyoQDJOeMP5aCrF954dytyy9abyHmv2V gL3q+sysMqVGAoOb3Yov8WLk92lm2JluoT0euMFe7ENJyzcIDzIFw8SAAloYxX0QZfQ/ ++0l6nS3IeJpxd6MyPYSJhlProAza8eKhk7bKzaD/c2GF0itaDdHPaV1QKfPqrjgdWSY qqTaEYu2J4Wp998No0NB3DhGcrJhDXUohJIupsL71pfg0JlJEgYi0DF47W/95dnzb2TT 96Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781249696; x=1781854496; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0xGyDNl5ogOQbdawWazKlNM531Ep7GOTwGMofOmo3ME=; b=jUT4qBvUNiDLEJzbJj3gI454bkDETrAjsgkfi+hDqO10ImIGGc130z0Z0nLSMtQghw llYma/WVdoDciMSvYhKne7RAn/KNbup7glrr1h0P/+PhRN874EMB3a5aCWUmkwjmo/Zd 0RJl/RjOG3qzqppWJKkbMpC4IjKkkyBR5E0i24iRgUtzUYHrNzh19SSFS9mvUvGbnLYo k/mgv2ST7q4ygsq5VLYlXl3ohcN3fMw/easB6mXMGt4vKRO/8KmmnoOxzCHc3agOxrcJ /KL3BUGbTU/7j6aoG9zGT3XWXTMG4GJ3fhiwjvr/fSyQB496QZF79nU4jeMbGMyI9+Wa uYvg== X-Forwarded-Encrypted: i=2; AFNElJ8vimIvBjmPGEN+jMWdfdbeTPvrJQi1hIPzPEnMO3TV9EF1tqUJFZfK1SS5Yar9Ml0mYbXcnmrOaddl@gnusha.org X-Gm-Message-State: AOJu0YwIAkj3yMitCuCo5jTjrwbG10LWeztL1nTa5YCFegZ6OXwFiFCg 5j63VvcBuRYFJykSdUj7RgIXnh/SI+uNiN9UC0n16iKnIRTuXgRunL4P X-Received: by 2002:a05:6820:806:b0:69e:390e:b98b with SMTP id 006d021491bc7-69edd599c88mr650211eaf.1.1781249696141; Fri, 12 Jun 2026 00:34:56 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeUStuDrfpnzxv9U8IvOVT+Pmd07UvzeHdOSBM2IfAtLg==" Received: by 2002:a05:6820:5284:b0:67e:40f9:6090 with SMTP id 006d021491bc7-69ec70b67e2ls420371eaf.1.-pod-prod-00-us-canary; Fri, 12 Jun 2026 00:34:52 -0700 (PDT) X-Received: by 2002:a05:6808:1c0d:b0:485:729e:6ac8 with SMTP id 5614622812f47-4872dd9f44dmr1109411b6e.5.1781249691921; Fri, 12 Jun 2026 00:34:51 -0700 (PDT) Received: by 2002:ab3:7398:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-30478b24a62msc7a; Thu, 11 Jun 2026 23:53:00 -0700 (PDT) X-Received: by 2002:ac2:5293:0:b0:5ad:abf:1d36 with SMTP id 2adb3069b0e04-5ad2db5937dmr354756e87.27.1781247178541; Thu, 11 Jun 2026 23:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781247178; cv=none; d=google.com; s=arc-20240605; b=GwvlqcvE77NJQfN7E/C0uhl8T1hK4Vvy5y0KiEK9c+v7NnjjLTsgDO5SLRwvpH3tzA 1m8ySdllGgOLBHDfh2uJ5cRNZi+peYUo+IP5daWx8erA8d558KHj8nJxM4ceQLjjBBd6 a7lIYUREy4L6LqmE5Hvbs7JxbQf0utTpQtR6VMx7po5pRgwtKAZcoILsUn0K50+dEXGo DVE/wO94uwpadoE7S+EPySRq2lFSXK1/ljOvB5oU++ttW6IQXEmE4lFU21vBZ8unCx6G vdJayw1x0M7Kj/gjUjA25dv0cLi3wb/Hc9N+6If5NKynEh2Pj991U4Bm23Ydg41o2fVP AKQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=f/Yq9JD8TmzVkjItyxREC+06d8V1JVpePpsoQYTRusw=; fh=nebaEmqeS1YPbyQEX8Yd3pyFZdfW5JHdN1RV0AMA9Oo=; b=BN2jcbCjWDc6bWT6iZTBgMB2MJvHEpYF+gqG20ClhVYAtc523QPkF7D45nqeWBMcfV 2pS1PjreVdQ4lKuwKppDsqQm1JGGohCN8sr4YLfrVCOhcgb4onJ02Bmq6u/DEfiU7RmY OeAodhwCfblVK90zOfvcrnjTqi7TMOvH6gj19jFI0yv7XHGtbiLRK4bxXH01E5R7Sid8 Nl+XfTXb7mIl2Z2ZnFSLfVnMRhhWoId1FodNrZ/pLVVSeuIiR0hC7JalM2u8PZG4l55C ty/oB5NH/wPO8GAKRqM11K/cBJi9kon4w+lexTS0QcpJX+YgCoQ+6n7+dHehCbtiCbus iBqQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=V+9EW2cA; spf=pass (google.com: domain of somber.night@protonmail.com designates 79.135.106.96 as permitted sender) smtp.mailfrom=somber.night@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10696.protonmail.ch (mail-10696.protonmail.ch. [79.135.106.96]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5ad2e1a98d5si17275e87.7.2026.06.11.23.52.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 23:52:58 -0700 (PDT) Received-SPF: pass (google.com: domain of somber.night@protonmail.com designates 79.135.106.96 as permitted sender) client-ip=79.135.106.96; Date: Fri, 12 Jun 2026 06:52:53 +0000 To: Murch , "rkrux.connect@gmail.com" From: "'SomberNight' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions Message-ID: In-Reply-To: <0710406e-e91a-480e-82e4-938d1894f66d@murch.one> References: <212d5db3-7521-4afd-a551-fda8a6ef09c9n@googlegroups.com> <0710406e-e91a-480e-82e4-938d1894f66d@murch.one> Feedback-ID: 3205679:user:proton X-Pm-Message-ID: 8535f8dffd79ab3691582262a8aef8d9f3f64f83 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: somber.night@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=V+9EW2cA; spf=pass (google.com: domain of somber.night@protonmail.com designates 79.135.106.96 as permitted sender) smtp.mailfrom=somber.night@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: SomberNight Reply-To: SomberNight Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) Hello rkrux, Murch, list, The Electrum Wallet has for years been setting the nSequence of tx inputs t= o MAX-2 [0] by default for most transactions it creates. Between 2017-2022,= the default was MAX-2 (to signal RBF), with an option to set MAX-1 instead= . Around Dec 2022 [1], when Bitcoin Core 24 added the mempoolfullrbf option, = we removed the option and just started to (kind of) always set MAX-2. "kind of", because we always set MAX-2 for normal wallet transactions, but = for Lightning funding transactions, we have always (and still) set MAX-1 [2= ]. Similarly, if we add support for sending to silent payment addresses in the= future, we will set MAX-1 (the old opt-out) there as well [3]. The wallet code still respects (and will keep respecting) opt-in/opt-out of= BIP125 RBF, so it only allows replacing mempool transactions using the old= nSequence rules (so no replacement for MAX-1). All this is to support multi-device contexts: e.g. when a phone and a lapto= p both have a wallet restored from the same seed and they are used concurre= ntly (perhaps even open in parallel, though not necessarily). Instead of allowing the wallet to RBF any tx ignoring the signal, we abuse = the signal bit to store publicly visible information to be used in a multi-= device context [4]: - if the tx opted-in to RBF, any device can freely RBF it - if the tx did not opt-in to RBF, only the originating device can RBF it, = as that device knows the details of the tx, and can apply special restricti= ons for it - for example, a tx that pays to a silent-payment-addr, can have its fe= e bumped via decreasing the change output, but adding new inputs would burn= coins. The device (wallet instance) that created the tx knows that it is a= special tx that needs these restrictions upheld but can otherwise be safel= y RBF-ed. The other devices (that did not originate the tx) don't know it's= paying to a silent payment addr but they will simply refuse to RBF it all = together, as it did not opt-in to RBF and they did not originate it. - or consider a lightning funding tx: only the wallet instance that cre= ated it knows the exact conditions re when it is safe to RBF it. In case of= channel-establishment-v1, there is no way to RBF fee-bump the funding tx. = In case of channel-establishment-v2, the originator wallet instance can bum= p its fee interactively. In either case, naively RBF fee-bumping the fundin= g tx would result in the channel-open failing but the coins still being sen= t to the channel funding multisig script: recovering the coins would need m= anual cooperation from the channel-counterparty. Depending on the LN implem= entation and how long it takes for the two participants to react, the coins= might be lost forever if the counterparty automatically deletes the channe= l keys for the failed channel open. Note that double-spend-cancelling any tx (as opposed to fee-bumping) is saf= e AFAICT (though there could be contrived examples of multi-party protocols= involving multiple txs or time pressure where even that is not safe(?)). B= y double-spend cancel, I mean RBF-ing the tx with a new one that sends all = coins to a wallet address, another feature in Electrum. --- The Electrum Wallet has always tried to mimic the Bitcoin Core wallet in te= rms of fingerprinting, for wallet transactions. E.g. we have the exact same= anti-fee-sniping logic [5]. For this reason, it would be preferable to us if the Bitcoin Core wallet wo= uld *not* start setting nSequence fields to MAX or MAX-1 now. --- I hope my explanation was clear enough :) Cheers, SomberNight (ghost43) [0]: https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c18fdb71d= c6a376162de1/electrum/transaction.py#L2462 [1]: https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cb= e1613b252db388 [2]: https://github.com/spesmilo/electrum/issues/7072 [3]: https://github.com/spesmilo/electrum/pull/9900#discussion_r2257399243 [4]: https://github.com/spesmilo/electrum/pull/8821#issuecomment-3160469899 [5]: https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c18fdb71d= c6a376162de1/electrum/wallet.py#L203 On Thursday, June 11th, 2026 at 18:42, Murch wrote: > Hi rkrux and everyone, >=20 > I don=E2=80=99t have a strong recommendation at this time, but I have a f= ew > thoughts on what should be considered in making the decision: >=20 > Stopping to signal replaceability makes it sound like it=E2=80=99s a matt= er of > dropping a fingerprint, but it might be clearer to state that the signal > is expressed in the per-input sequence value, and that every sender has > to pick a sequence for every input! > The most common three settings for the sequence value would presumably > be final (MAX), non-final (MAX=E2=88=921), and non-final replaceable (MAX= =E2=88=922). > The past usage of BIP125 had caused a trend toward more wallets setting > the latter (MAX=E2=88=922). According to Mainnet Observer, currently abou= t 75% > of txs signal replaceability in the 30-day average (see > https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).=E2= =80=94Unfortunately, > that chart does not distinguish between (MAX) and (MAX=E2=88=921), so I= =E2=80=99m not > sure which of those two is more prevalent (probably (MAX)?). Does > someone have more data on that? Otherwise, I could throw together a Dune > dashboard later. >=20 > We should try to converge transactions on one common sequence. Signaling > finality means that locktimes in the transaction are disabled, so that > seems like a poor choice. While `mempoolfullrbf` appears to be fully > adopted by the network at this time, there are still some users that use > (MAX=E2=88=921) to explicitly convey absence of intent to replace, but th= at > signal would be ignored by the network for evaluating replaceability and > these senders could easily renege on the perceived signal. There are > also some wallets that generally still use (MAX) which now also > effectively is replaceable. So, the more natural convergence point would > perhaps be for everyone to adopt usage of (MAX=E2=88=922), as the emergen= t > behavior of the network is replaceability and it currently is the most > common signal. >=20 > Cheers, > Murch >=20 > On 2026-06-10 22:43, rkrux wrote:it > > Hello list, > > > > There is an intention in the bitcoin core wallet to remove the > > BIP 125 RBF signalling[0] in transactions for which a PR is raised[1]. > > The primary reason for its removal is because ever since fullrbf > > became the default In bitcoin core nodes in v28.0 two years back, > > this signalling has become redundant. > > > > However, a point[2] was raised in the review of the above PR that > > the default input sequence number should be the one that's agreed > > by the wide wallet community as a best practice. It would be helpful > > if other wallet developers can share if (when) they have plans to > > remove this explicit BIP 125 signalling for RBF in transactions. > > > > It's also an intention[3] to share an informational BIP later that > > highlights a recommended input sequence number in transactions. > > > > Looking forward to replies from wallet developers in the list. > > > > [0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki > > [1] https://github.com/bitcoin/bitcoin/pull/35405 > > [2] https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-46344696= 19 > > [3] https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-46750057= 59 > > > > - rkrux --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= uscVpXZgwC16jogiUouq2bY8y65G8BeiPWHizgCnU-IYtLwZyHY1bRC-VlpwTATpHTOuvQJ_c8K= tSkipAsRhieC1wTlR6CDflgz9gwdIv_Q%3D%40protonmail.com.