From: "bitcoin-dev-ml.void867 via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: SomberNight <somber.night@protonmail.com>
Cc: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions
Date: Tue, 16 Jun 2026 16:33:01 +0200 [thread overview]
Message-ID: <178162039498.7.16213177200751410070.1421232845@slmail.me> (raw)
In-Reply-To: <NDkJg0T-NF7_W2e1dDsNmmfET-rDUbmRXhiiEQngqTNNnf2EyM4s4eM01O9--90LN985wXDHJgbiGyVthNdji9Zd3sB6OJgn5v03PFuEM-I=@protonmail.com>
SomberNight wrote:
> Alternatively users would have to be educated RBF-ing txs created in other wallet software is not safe...
Right. I forgot to mention that the wallet software which stores the
signal bit in a local database would still allow the user to (full)rbf
the transaction with a warning, if the signal was missing and the user
really wanted to do a replacement.
In the normal case of a single wallet and a single device, the user
can follow the happy path and replace any transaction if the local
wallet database allows it.
When a wallet or wallet seed is used on several devices, it is likely
best to educate the user with a warning that replacing the transaction
is possible, but may cause issues (or even loss of funds) in the
wallet that originally created the transaction.
The benefit of a conditional warning and then unconditionally allowing
a replacement is that even transactions from legacy wallets that do
not signal BIP125 can be replaced.
Maybe a good rule of thumb could be to expose the normal, harmless and
happy path as-is and hide the "forced" replacement as a possibly risky
expert feature?
Best, void867
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/178162039498.7.16213177200751410070.1421232845%40slmail.me.
prev parent reply other threads:[~2026-06-16 14:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 5:43 [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions rkrux
2026-06-11 18:28 ` Murch
2026-06-12 6:52 ` 'SomberNight' via Bitcoin Development Mailing List
2026-06-16 7:05 ` rkrux
[not found] ` <178159635281.7.13516081672246118406.1420460464@slmail.me>
2026-06-16 10:46 ` 'SomberNight' via Bitcoin Development Mailing List
2026-06-16 14:33 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178162039498.7.16213177200751410070.1421232845@slmail.me \
--to=bitcoindev@googlegroups.com \
--cc=bitcoin-dev-ml.void867@slmail.me \
--cc=somber.night@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox