[bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

[bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

[rkrux]

[-- Attachment #1.1: Type: text/plain, Size: 1498 bytes --]

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

-- 
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/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1974 bytes --]

Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

[Murch]

Hi rkrux and everyone,

I don’t 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’s a matter 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−1), and non-final replaceable (MAX−2). 
The past usage of BIP125 had caused a trend toward more wallets setting 
the latter (MAX−2). According to Mainnet Observer, currently about 75% 
of txs signal replaceability in the 30-day average (see 
https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).—Unfortunately, 
that chart does not distinguish between (MAX) and (MAX−1), so I’m 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.

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−1) to explicitly convey absence of intent to replace, but that 
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−2), as the emergent 
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
> -- 
> 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/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com 
> <https://groups.google.com/d/msgid/bitcoindev/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/0710406e-e91a-480e-82e4-938d1894f66d%40murch.one.

Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

['SomberNight' via Bitcoin Development Mailing List]

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, 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 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 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 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 it 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 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 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 funding tx. In case of channel-establishment-v2, the originator wallet instance 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 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 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 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/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/transaction.py#L2462
[1]: https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
[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/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/wallet.py#L203


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

> Hi rkrux and everyone,
> 
> I don’t 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’s a matter 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−1), and non-final replaceable (MAX−2).
> The past usage of BIP125 had caused a trend toward more wallets setting
> the latter (MAX−2). According to Mainnet Observer, currently about 75%
> of txs signal replaceability in the 30-day average (see
> https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).—Unfortunately,
> that chart does not distinguish between (MAX) and (MAX−1), so I’m 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.
> 
> 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−1) to explicitly convey absence of intent to replace, but that
> 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−2), as the emergent
> 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

-- 
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/uscVpXZgwC16jogiUouq2bY8y65G8BeiPWHizgCnU-IYtLwZyHY1bRC-VlpwTATpHTOuvQJ_c8KtSkipAsRhieC1wTlR6CDflgz9gwdIv_Q%3D%40protonmail.com.

Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

[rkrux]

[-- Attachment #1: Type: text/plain, Size: 8428 bytes --]

Thanks SomberNight, Murch for your inputs.
Based on this feedback, I've decided to close that PR now.

- rkrux <https://github.com/rkrux>


On Fri, Jun 12, 2026 at 12:22 PM SomberNight <somber.night@protonmail.com>
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, 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
> 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 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
> 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 it
> 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 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
> 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 funding
> tx. In case of channel-establishment-v2, the originator wallet instance 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
> 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 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
> 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/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/transaction.py#L2462
> [1]:
> https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
> [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/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/wallet.py#L203
>
>
> On Thursday, June 11th, 2026 at 18:42, Murch <murch@murch.one> wrote:
>
> > Hi rkrux and everyone,
> >
> > I don’t 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’s a matter 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−1), and non-final replaceable (MAX−2).
> > The past usage of BIP125 had caused a trend toward more wallets setting
> > the latter (MAX−2). According to Mainnet Observer, currently about 75%
> > of txs signal replaceability in the 30-day average (see
> > https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).
> —Unfortunately,
> > that chart does not distinguish between (MAX) and (MAX−1), so I’m 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.
> >
> > 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−1) to explicitly convey absence of intent to replace, but that
> > 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−2), as the emergent
> > 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
>
>

-- 
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/CAMmSeEENk33j7-HS4qdMxJ3bcw9pti-JAXFhYLnET3zJE895bw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 10900 bytes --]

Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

['SomberNight' via Bitcoin Development Mailing List]

Hi void867,

(Replying to list as well. Original email quoted in full below.)

> It is interesting to use the input sequence number as a field to
> signal whether a transaction can be replaced between several wallets
> sharing the same seed.
> However, this seems like a fingerprinting vector.

You are of course right this behaviour is a (~small) fingerprinting vector.

> I wonder whether it would be better to use a database field for the
> wallet transaction to indicate whether a transaction is permitted to
> be replaced.

Storing the signal bit in a local database, and letting the wallet do RBF if its local database has the tx marked as being locally-originated, would mostly work.

(1) The tradeoff is that while with our current approach (storing signal bit on-chain) where any device is allowed to RBF the most-common simple wallet transactions (that set nSequence to MAX-2), that would not be the case with the local db signal where only the originator could RBF any tx.

(2) Another scenario is the user creating the tx in another wallet software but there is mempool congestion and their tx is "stuck" in the mempool, and so they restore from seed in Electrum and try to RBF it there: currently this works if the other wallet software set nSequence to MAX-2, but with the local db signal it would never work.
Although this use case is somewhat weakened by the fact that wallet software that doesn't let the user properly RBF their tx likely doesn't set nSequence to MAX-2 anyway.

(3) Even disregarding mixing wallet software, if there is mempool congestion and the wallet has some stuck txs, and the user panics and restores from seed in desperation (and also deletes their old wallet file) then they could not RBF the tx anymore (if the signal bit is stored in the local db). This might be a contrived example - although weird edge cases do happen.

(4) Relatedly, I think it would be nice if other wallet software would only set nSequence to MAX-2 if the tx is safe to arbitrarily RBF. That is, for example, ideally a tx paying to a silent payment address should not set MAX-2 in any wallet. Otherwise in scenario (2), the user could lose the coins. Alternatively users would have to be educated RBF-ing txs created in other wallet software is not safe...

Indeed this last issue (4) would be avoided if a wallet strictly restricted RBF to locally originated txs using by storing a flag in a local database. hmm. Tradeoffs everywhere :)

I wonder what logic other wallets use to determine whether they expose a GUI option to RBF a mempool tx.

Regards,
SomberNight


On Tuesday, June 16th, 2026 at 07:52, void867 wrote:

> Hi SomberNight,
> 
> (replying off-list, but feel free to reply on-list)
> 
> It is interesting to use the input sequence number as a field to
> signal whether a transaction can be replaced between several wallets
> sharing the same seed.
> 
> However, this seems like a fingerprinting vector. When the majority of
> wallets use a specific sequence number by default, but one wallet
> allows the user on a tx-by-tx basis to use a sequence number different
> from the most frequently used default, then transactions using those
> non-default sequence numbers are less frequent and could more easily
> be grouped and filtered for chain analysis.
> 
> I wonder whether it would be better to use a database field for the
> wallet transaction to indicate whether a transaction is permitted to
> be replaced. The local transaction field could be anything (such as a
> flag if the transaction was locally created, or the wallet/device ID
> where the transaction was originally created, possibly even a local
> field for each transaction input in a multi-party transaction-creation
> context).
> 
> 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/NDkJg0T-NF7_W2e1dDsNmmfET-rDUbmRXhiiEQngqTNNnf2EyM4s4eM01O9--90LN985wXDHJgbiGyVthNdji9Zd3sB6OJgn5v03PFuEM-I%3D%40protonmail.com.

Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

[bitcoin-dev-ml.void867 via Bitcoin Development Mailing List]

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.