From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 16 Jun 2026 00:44:26 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZOTA-0007nh-VZ for bitcoindev@gnusha.org; Tue, 16 Jun 2026 00:44:26 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43d197b99b8sf6551547fac.0 for ; Tue, 16 Jun 2026 00:44:24 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781595858; cv=pass; d=google.com; s=arc-20240605; b=CO4fpZpWM7RujZGlmLWTrT3aowImkQao2rLY63hi2l6tgzUtGeGnclFFMmRD3AVJ3i r7VLfeBAmqIEyfcSdd1jIYf8uyyQiM4zInG4ycOYF88lRdUOZCqzo8BgfqKamLBKf5IH m36QGw2KAh4+gmciqOGRf34G/zh1PiJpNcOSk9GvDvA2Nw9YRLj6eRM6OgvycJbnvpRk RH5tMZiS/g+2ejmYrX01jng8AHZROXUz8qDS0UKxtoqpXvBbkSbEHo1W1Q6JBvLGeETE BixLvB2OCoUuCO6JBobd/oDrCLOUccjrsRlRwEgJyUVlAC0tsE94GFF9cbsTNVpwrNQS K7Tw== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=FpIdh4ci/nbkKUGYio+gs3IeooD3aKooImQoKaAKulY=; fh=NpWDRn/zl7NkGEhhh0NWcNidk4T4T0lFg37ppJ90mx4=; b=ZuDu5XE6MepHRAZKBPy/6S09kzMorTP6UKyYwCZMD9RChlNr3rnraKOCbpylrqc5fE lLX7SlC5T+GZiiwM9a5ladho1119Wxel2GCe+4f2BvOJpGsGc+vYP57uSAgOO9+vWlSo 86+FpJlcGhd/AqGGO9N1+WrKbcV3s3TP9t2h1H8iwyaR3eF0Oj+qcAiTntcAIVCB+4hL 3asrqo7nmiDFt5/Oi1DlXjBzr8ORV8ag+m9I7ftAUi57kfPgsYcNmuGZc2oReATrzKSb W7DZfVPL+dl6wIJxRZmAHqK0RkGWjHTGnziCUffO8uc1KflRqWueEcGU/Xo9/F8U2AW2 YeVQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=XMWAB9Vp; arc=pass (i=1); spf=pass (google.com: domain of rkrux.connect@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=rkrux.connect@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781595858; x=1782200658; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=FpIdh4ci/nbkKUGYio+gs3IeooD3aKooImQoKaAKulY=; b=r4zYz1nUZwc/n4Rbbjt0AJGWh5wrNhDnf7+q5VQ67baQlkFlH5l3mf4M9Z/PfNDocX Y/+iDHpGuhP6IZjHMmuXesMx1+Xzc5HWrlOCJE1dUmxFOEmNHFSQE+KSSEx23Ll3UFdZ DfaafkkAzXR9jrYaG/1Uc5HLVcVd3737erq/hhAR+GHx4w/1SuwwkJ20F1sjY/ZO5ZwT SZp9GolE7Kde3LWwhWbZn2w8Q79+cituSS+jdJHZ6H2HaZD6L4fJqgWbr9n47zfgy4ZI fBR7Mk5dWI3GiPB5YWz9kHP2eHZVOguOR42dyqJewzEspGQfEy69WZIMsxST1ffxpQRZ SrnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781595858; x=1782200658; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FpIdh4ci/nbkKUGYio+gs3IeooD3aKooImQoKaAKulY=; b=GsdK2xdW7Bm9n9EwUYet8Wr0iM9NND3s51uZ1J6c5XgdXRSToFPcE34h1AWVCv0ZEL PrWP8DD0VcwB23Cuz1gzvmMJY6CF3qRnhiwQ/6ykOqvaLQvch5AV+yhlKIIqRD0CUZMD GT1dTyWxqTgtI+x4SQuJT0kVmMGW4YpVI1CV62kbcwqha8QhoRafDVTXWFxo+5XOCocy ChespxBa0cd5eQv6VD8cqiMxvP47nPupXDuq5R05fO2rybPqawJB/fJ8E47L3BC4EFKZ 7R7Ns7HWjZ6HKOPidoS36eGKwuOWFK/K+QowS06obdWiU0sFKlLvl6wN//Q066xCE9Ff GP5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781595858; x=1782200658; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=FpIdh4ci/nbkKUGYio+gs3IeooD3aKooImQoKaAKulY=; b=Kols4Ee2O0QLkLFRJZUHfDchp0NZ1ivnd9WJFPgoAsyaGTQ4xYdAqx+TrNdihv9oNl zJW9zc2yMF4/kSHMDLYlQjhTiyvctXatImlmHqiarp3el+BGe8KOqol9fFBT5/ZhgiGG DmQpze6mB1Z1FYeXGKroVTCNgb9YRgtxbooYAm1czaWb3v8G8XBhxVqq1rz5ZCAu7mQA Sd40kko7jukyUH2y4cpaEYbODsaiaNX+sd8dWdemGPsZvfPDRx9WQ2ek8AIeOk4S7Duk NvjIIwjav4fBBMObeoRWis/7D4REhW5KH0D5Qt7i/6MEvyn/5dLsbPtnLatDlp3DNOWj dX5Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/wAv8PbJ1J9hHSSHXYnMxdYAncjuXUjFMoz4fTyHHc6hwQ7IOKkMTaNyr9yxuekkdy5FzWWf9KeKLC@gnusha.org X-Gm-Message-State: AOJu0YzWXkWurnSQZP40s6NJQ7k8UeQtBXm4U8tWGWw4sgA7DYISXEV/ mjJtCvRYSpViOik3Q/QlOBb5UawM812YuYmBWfu6VOYZZjSxjGWtNfRP X-Received: by 2002:a05:6871:739d:b0:43e:942:dfab with SMTP id 586e51a60fabf-4430b759453mr2000884fac.33.1781595858238; Tue, 16 Jun 2026 00:44:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeJV+40KwWEbHu+/OZFfMCdqggP4uPgbGHixiTB1t8RPg==" Received: by 2002:a05:6870:6017:10b0:441:4757:d522 with SMTP id 586e51a60fabf-442617dc4cals1935558fac.0.-pod-prod-09-us; Tue, 16 Jun 2026 00:44:13 -0700 (PDT) X-Received: by 2002:a05:6808:3098:b0:479:ff59:dcec with SMTP id 5614622812f47-4884c1ff747mr2119130b6e.32.1781595853697; Tue, 16 Jun 2026 00:44:13 -0700 (PDT) Received: by 2002:a05:6808:4a4c:20b0:480:77ce:ad79 with SMTP id 5614622812f47-4872db787c7msb6e; Tue, 16 Jun 2026 00:05:20 -0700 (PDT) X-Received: by 2002:a05:6a00:94cf:b0:829:8942:2c93 with SMTP id d2e1a72fcca58-845152ae41emr2266904b3a.9.1781593519764; Tue, 16 Jun 2026 00:05:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781593519; cv=pass; d=google.com; s=arc-20240605; b=WgnD6GhVSkICk+/PfXHzuBh6QBgL0tZVovqV/2421eU/fvQK6FjQm8FGl+pzkMiSHW q4p8d8gkY+GZYGOZCo8/1gT5KAkLcRfZdl84oOsPv+Ke8IAycDjwICnXodiE7YSI3lTY PF3JtvStux3WcSkBhc4dU2OWeapmfQ8AACi/tV4gHufG2iqAAkuTfWHUPAIjoXItDIIA yPHJZRP8Q+ICgvzJH0KS33d/atQDzIz90SGmxnJO9uuxiHQwPZNok93PbBrBwHgl+FIs GaADdMEKj6k3YerG1yUgPl9uoK3U/fILlKQL+NVu8c2qVtVZ88tGJ0nm05y8yi3KjuaN +/Bw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=m4YaknpcgBpyel2VeJobZ7r7ZLcvKSKXFf9rEo25+wc=; fh=SmB/neCRdXFdanO0tZqyPjvXW00OJVl+CMqcA+y6WBI=; b=B4AZAjQM5dgHuKjQPRCzwo61PVJNhfDFJqL9/Ui1vNxbi7Y9fASuT6fRCVyDYvTz29 t42dT1l8wMWC6gEJNQvjS3qB1PrW7aDTu0K8V5p3s5htxUTi/T5yrvZZOLLerBqukbU4 Rlsp9+rju+XwCMdzQu0dHjp7+w/qJ92FRSgVEZFVs6HgfLAoC/AEJhohguB+NXqEjHBg Qh0bgmDnS4J6sonCqH1DIwgkrGhWgftINWf3XrwSvwbgobKgKx3U0efIEV+8xkmirA+E Pf1/hBGjvvxaG/0Cosl9zKi2bfd8dTiXwFSLvjDnAZSr7wFJlCX1AC1//qVxeSb0GfDq fr2g==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=XMWAB9Vp; arc=pass (i=1); spf=pass (google.com: domain of rkrux.connect@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=rkrux.connect@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com. [2607:f8b0:4864:20::1030]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-8434aeb022csi396353b3a.3.2026.06.16.00.05.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 00:05:19 -0700 (PDT) Received-SPF: pass (google.com: domain of rkrux.connect@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) client-ip=2607:f8b0:4864:20::1030; Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-36bdb11bf8bso2225413a91.0 for ; Tue, 16 Jun 2026 00:05:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781593519; cv=none; d=google.com; s=arc-20240605; b=gDQkVLMdV91TXAziEcBEgL78Jg3YioJDGYQ5WEXCuXE0eA1P78U9hYE6oB86ulP2TT ss2DF1twH0CW4yCMjlMfhzOBOFxdH6cPBIUWTh50bazBCMEG/4sPy3kYQbVNFK3dscbO Yq9OsS9KTBVTGoOwrgpy1sqavPaUxpPf9j97qXTyFIeVeojSrSJ94zrqqsVOAvUDaxeq uTxhWZiZhury3gKCJToBJCm9e9LwAg+MfiPzzSlqKEnfiyN4Zav1X/opHJgRFQ+rIFGh uaY+ACv+ZUFQf8TP3zrwvuhkHqtVeq/+Jr7CWjIsdkPrs6c73M5b+qVp4wiYYk5inVXF GtqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=m4YaknpcgBpyel2VeJobZ7r7ZLcvKSKXFf9rEo25+wc=; fh=SmB/neCRdXFdanO0tZqyPjvXW00OJVl+CMqcA+y6WBI=; b=YQzrwYVT7OJiCvZ1tASEhY5XPVA/yegNy7maHT4GmlHz1YdmxAFPw/i7Cs2pOEyaom 3Fw9jazs0KgdGI/gG5WMHaaoj5s1sg6P6sm+9teTKuebp7SE2YtRiHaOcm5u0GNJW/Vn 9VlMV4f61n71U9wI6d/CrCp3Kc7UflUVR9uYp06/uVMzeX8BTpMMt134LN82gzSX8y+u 5vi/HOghgdkNCWgj4y94KCJ3jUTm6rLdyy4DFJjpFVIce/83F/Ozo3G5VApG8mZ7JPqt 9ZgedHd+wafQgRMuYavKkxkXs7RVDIiEHq6rKnn+qjkCt+7munBFLjYGR5Wi4Su9fHzq zCXw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OFYqbC5wWzub82ZYgEcb9fDBfYa/10liyhWSFzSlXq88iNV16kM25vcae++jDZ bF5wTSS3eVWG8aVoej6nAJ0LgGoaBiQ3ugdYyXK3cs6JzSNcfMEkMSNv6+tAqO2ZHBZL8BXXmVr 5ib0em3EyHCjDnf/Hu2+boSh12sjTGp/wA6I3stdK0s6NB0jB5WF9dWwHGDAu2+Rh5TNLeeWqSJ T+XHJ9GgLrcSnO5Vsox7fi8l6eiC8wLSfEpGzPae+gNaWZw4GCRpR5HO0eq3vTNLGMVhBtPx/Hq hhEhTEewRyJCUNkI+kk= X-Received: by 2002:a17:90b:3849:b0:367:b8ad:f0e9 with SMTP id 98e67ed59e1d1-37c528e00d1mr2346586a91.16.1781593519067; Tue, 16 Jun 2026 00:05:19 -0700 (PDT) MIME-Version: 1.0 References: <212d5db3-7521-4afd-a551-fda8a6ef09c9n@googlegroups.com> <0710406e-e91a-480e-82e4-938d1894f66d@murch.one> In-Reply-To: From: rkrux Date: Tue, 16 Jun 2026 12:35:07 +0530 X-Gm-Features: AVVi8CdiqYeq45axsBrjQ2L48ZyebE2p1bK8GVKNm9ODsChd-2nAx0tqd_pYeMg Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions To: SomberNight , Murch Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000d694f606545990a0" X-Original-Sender: rkrux.connect@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=XMWAB9Vp; arc=pass (i=1); spf=pass (google.com: domain of rkrux.connect@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=rkrux.connect@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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: -0.5 (/) --000000000000d694f606545990a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks SomberNight, Murch for your inputs. Based on this feedback, I've decided to close that PR now. - rkrux On Fri, Jun 12, 2026 at 12:22=E2=80=AFPM SomberNight wrote: > Hello rkrux, Murch, list, > > The Electrum Wallet has for years been setting the nSequence of tx inputs > to 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, bu= t > 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 > laptop both have a wallet restored from the same seed and they are used > concurrently (perhaps even open in parallel, though not necessarily). > > Instead of allowing the wallet to RBF any tx ignoring the signal, we abus= e > 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 > restrictions for it > - for example, a tx that pays to a silent-payment-addr, can have its > fee bumped via decreasing the change output, but adding new inputs would > burn coins. The device (wallet instance) that created the tx knows that i= t > is a special tx that needs these restrictions upheld but can otherwise be > safely RBF-ed. The other devices (that did not originate the tx) don't kn= ow > it's paying to a silent payment addr but they will simply refuse to RBF i= t > 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 > created it knows the exact conditions re when it is safe to RBF it. In ca= se > 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 c= an > bump its fee interactively. In either case, naively RBF fee-bumping the > funding tx would result in the channel-open failing but the coins still > being sent to the channel funding multisig script: recovering the coins > would need manual cooperation from the channel-counterparty. Depending on > the LN implementation and how long it takes for the two participants to > react, the coins might be lost forever if the counterparty automatically > deletes the channel keys for the failed channel open. > > Note that double-spend-cancelling any tx (as opposed to fee-bumping) is > safe AFAICT (though there could be contrived examples of multi-party > protocols involving multiple txs or time pressure where even that is not > safe(?)). By double-spend cancel, I mean RBF-ing the tx with a new one th= at > sends all coins to a wallet address, another feature in Electrum. > > --- > > The Electrum Wallet has always tried to mimic the Bitcoin Core wallet in > terms 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 > would *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/34f83a07617c2715522c18fdb71dc6a= 376162de1/electrum/transaction.py#L2462 > [1]: > https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe16= 13b252db388 > [2]: https://github.com/spesmilo/electrum/issues/7072 > [3]: https://github.com/spesmilo/electrum/pull/9900#discussion_r225739924= 3 > [4]: > https://github.com/spesmilo/electrum/pull/8821#issuecomment-3160469899 > [5]: > https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c18fdb71dc6a= 376162de1/electrum/wallet.py#L203 > > > On Thursday, June 11th, 2026 at 18:42, Murch wrote: > > > Hi rkrux and everyone, > > > > I don=E2=80=99t have a strong recommendation at this time, but I have a= few > > thoughts on what should be considered in making the decision: > > > > Stopping to signal replaceability makes it sound like it=E2=80=99s a ma= tter of > > dropping a fingerprint, but it might be clearer to state that the signa= l > > 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 (M= AX=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 ab= out 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 Dun= e > > dashboard later. > > > > We should try to converge transactions on one common sequence. Signalin= g > > 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 us= e > > (MAX=E2=88=921) to explicitly convey absence of intent to replace, but = that > > signal would be ignored by the network for evaluating replaceability an= d > > 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 woul= d > > perhaps be for everyone to adopt usage of (MAX=E2=88=922), as the emerg= ent > > behavior of the network is replaceability and it currently is the most > > common signal. > > > > Cheers, > > Murch > > > > 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-4634469619 > > > [3] > https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4675005759 > > > > > > - 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/= CAMmSeEENk33j7-HS4qdMxJ3bcw9pti-JAXFhYLnET3zJE895bw%40mail.gmail.com. --000000000000d694f606545990a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks SomberNight, Murch for your inputs.
= Based on this feedback, I've decided to close that PR now.


On Fri,= Jun 12, 2026 at 12:22=E2=80=AFPM SomberNight <somber.night@protonmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hello rkrux, Murch, list,<= br>
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 transact= ions, but for Lightning funding transactions, we have always (and still) se= t 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
=C2=A0 =C2=A0 - for example, a tx that pays to a silent-payment-addr, can h= ave its fee bumped via decreasing the change output, but adding new inputs = would burn coins. The device (wallet instance) that created the tx knows th= at it is a special tx that needs these restrictions upheld but can otherwis= e be safely RBF-ed. The other devices (that did not originate the tx) don&#= 39;t know it's paying to a silent payment addr but they will simply ref= use to RBF it all together, as it did not opt-in to RBF and they did not or= iginate it.
=C2=A0 =C2=A0 - or consider a lightning funding tx: only the wallet instanc= e that created 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 fu= nding tx. In case of channel-establishment-v2, the originator wallet instan= ce can bump its fee interactively. In either case, naively RBF fee-bumping = the funding tx would result in the channel-open failing but the coins still= being sent to the channel funding multisig script: recovering the coins wo= uld need manual cooperation from the channel-counterparty. Depending on the= LN implementation and how long it takes for the two participants to react,= the coins might be lost forever if the counterparty automatically deletes = the channel 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/34f83a07617c2715= 522c18fdb71dc6a376162de1/electrum/transaction.py#L2462
[1]: https://git= hub.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
[2]: https://github.com/spesmilo/electrum/issues/707= 2
[3]: https://github.com/spesmil= o/electrum/pull/9900#discussion_r2257399243
[4]: https://github.com/spesmi= lo/electrum/pull/8821#issuecomment-3160469899
[5]: https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c1= 8fdb71dc6a376162de1/electrum/wallet.py#L203


On Thursday, June 11th, 2026 at 18:42, Murch <murch@murch.one> wrote:=

> Hi rkrux and everyone,
>
> I don=E2=80=99t have a strong recommendation at this time, but I have = a few
> thoughts on what should be considered in making the decision:
>
> Stopping to signal replaceability makes it sound like it=E2=80=99s a m= atter of
> dropping a fingerprint, but it might be clearer to state that the sign= al
> is expressed in the per-input sequence value, and that every sender ha= s
> 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 settin= g
> the latter (MAX=E2=88=922). According to Mainnet Observer, currently a= bout 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 Du= ne
> dashboard later.
>
> We should try to converge transactions on one common sequence. Signali= ng
> 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 u= se
> (MAX=E2=88=921) to explicitly convey absence of intent to replace, but= that
> signal would be ignored by the network for evaluating replaceability a= nd
> 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 wou= ld
> perhaps be for everyone to adopt usage of (MAX=E2=88=922), as the emer= gent
> behavior of the network is replaceability and it currently is the most=
> common signal.
>
> Cheers,
> Murch
>
> 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 raise= d[1].
> > The primary reason for its removal is because ever since fullrbf<= br> > > 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 ag= reed
> > by the wide wallet community as a best practice. It would be help= ful
> > if other wallet developers can share if (when) they have plans to=
> > remove this explicit BIP 125 signalling for RBF in transactions.<= br> > >
> > 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/bitco= in/bips/blob/master/bip-0125.mediawiki
> > [1] https://github.com/bitcoin/bitcoin/pull/3= 5405
> > [2] https://github.co= m/bitcoin/bitcoin/pull/35405#issuecomment-4634469619
> > [3] https://github.co= m/bitcoin/bitcoin/pull/35405#issuecomment-4675005759
> >
> > - rkrux

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CAMmSeEENk33j7-HS4qdMxJ3bcw9pti-JAXFhYLnET3zJE895bw%40mail.g= mail.com.
--000000000000d694f606545990a0--