public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt•org>
To: Dario Sneidermanis <dario@muun•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Fri, 07 Oct 2022 07:21:29 -1000	[thread overview]
Message-ID: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org> (raw)
In-Reply-To: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>

On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> Hello list,
> 
> I'm Dario, from Muun wallet [...] we've been reviewing the latest 
> bitcoin core release
> candidate [...] we understood we had at least a year from the initial
> opt-in  deployment until opt-out was deployed, giving us enough time to 
> adapt
> Muun to the new policies. However, when reviewing the 24.0 release 
> candidate
> just a few  days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.

Hi Dario,

I'm wondering if there's been some confusion.  There are two RBF-related 
items in the current release notes draft:[1]

1. "A new mempoolfullrbf option has been added, which enables the 
mempool to accept transaction replacement without enforcing BIP125 
replaceability signaling. (#25353)"

2. "The -walletrbf startup option will now default to true. The wallet 
will now default to opt-in RBF on transactions that it creates. 
(#25610)"

The first item (from PR #25353) does allow a transaction without a 
BIP125 signal to be replaced, but this configuration option is set to 
disabled by default.[2]  There have been software forks of Bitcoin Core 
since at least 2015 which have allowed replacement of non-signaling 
transactions, so this option just makes that behavior a little bit more 
accessible to users of Bitcoin Core.  Some developers have announced 
their intention to propose enabling this option by default in a future 
release, which I think is the behavior you're concerned about, but 
that's not planned for the release of 24.0 to the best of my knowledge.

The second item (from PR #25610) only affects Bitcoin Core's wallet, and 
in particular transactions created with it through the RPC interface.  
Those transactions will now default to signaling BIP125 replacability.  
This option has been default false for many years for the RPC, but for 
the GUI it's been default true since Bitcoin Core 0.16, released in 
early 2018[3].  It's no different than another popular wallet beginning 
to signal BIP125 support by default.

In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly 
changes the current situation related to transaction replacability.  All 
it does is give Bitcoin Core RPC users by default the same settings long 
used for GUI users and introduce an option that those who object to 
non-signalled RBF will later be able to use to disable their relay of 
non-signalled replacements.

Does the above information resolve your concerns?

Thanks,

-Dave

[1] 
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft

[2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf
   -mempoolfullrbf
        Accept transaction replace-by-fee without requiring 
replaceability
        signaling (default: 0)

[3] 
https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui


  reply	other threads:[~2022-10-07 17:21 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 16:20 Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding [this message]
2022-10-07 17:28   ` Greg Sanders
2022-10-07 21:37   ` Dario Sneidermanis
2022-10-11 16:18     ` Pieter Wuille
2022-10-12  5:42     ` Anthony Towns
2022-10-12 16:11       ` Pieter Wuille
2022-10-12 21:44         ` Dario Sneidermanis
2022-10-13  4:35         ` Anthony Towns
2022-10-16  8:08           ` Anthony Towns
2022-10-17 14:25             ` Greg Sanders
2022-10-17 21:41             ` Antoine Riard
2022-10-18  7:00               ` Anthony Towns
2022-10-19  3:01                 ` Antoine Riard
2022-10-19  3:17                 ` alicexbt
2022-10-20 22:08                   ` Peter Todd
2022-11-02 15:04                     ` AdamISZ
2022-10-20 23:18                 ` Peter Todd
2022-11-09 13:19                 ` ArmchairCryptologist
2022-11-10  9:35                   ` ZmnSCPxj
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14  2:44   ` alicexbt
2022-10-14 15:02     ` Peter Todd
2022-10-17 20:31 ` Antoine Riard
2022-10-17 22:14 ` Antoine Riard
     [not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04   ` Peter Todd
2022-10-14 16:28     ` Erik Aronesty
2022-10-15  4:08       ` John Carvalho
2022-10-15  4:20     ` John Carvalho
     [not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45   ` Erik Aronesty
2022-10-19 15:43   ` Jeremy Rubin
2022-10-19 15:51     ` Greg Sanders
2022-10-19 16:04     ` Sergej Kotliar
2022-10-19 16:08       ` Greg Sanders
2022-10-20  1:37   ` Antoine Riard
2022-10-20 14:11     ` Sergej Kotliar
2022-10-21  1:04       ` Antoine Riard
2022-10-20  4:05   ` Peter Todd
2022-10-21 19:35     ` Peter Todd
2022-10-20  7:22   ` Anthony Towns
2022-10-20 12:37     ` Sergej Kotliar
2022-10-20 14:14       ` Ruben Somsen
2022-10-20 14:17         ` Sergej Kotliar
2022-10-20 19:58       ` Anthony Towns
2022-10-20 21:05         ` David A. Harding
2022-10-20 21:07         ` Greg Sanders
2022-10-20 22:02           ` Eloy
2022-10-21 12:02           ` Sergej Kotliar
2022-10-21 14:01             ` Greg Sanders
2022-10-21 14:19               ` Sergej Kotliar
2022-10-21 14:47                 ` Greg Sanders
2022-10-21 19:43             ` Peter Todd
2022-10-24  7:55               ` Sergej Kotliar
2022-10-20 22:13         ` Peter Todd
2022-10-21  9:34           ` Sergej Kotliar
2022-10-21 19:33             ` Peter Todd
2022-10-24  7:45               ` Sergej Kotliar
2022-10-21 11:56         ` Sergej Kotliar
2022-10-23 19:20   ` David A. Harding
2022-10-23 20:51     ` alicexbt
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02  6:34   ` Daniel Lipshitz
2022-12-02  1:52 ` Antoine Riard
2022-12-02  6:59   ` Daniel Lipshitz
2022-12-02  4:30 ` Peter Todd
2022-12-02  7:06   ` Daniel Lipshitz
2022-12-03  8:50     ` Peter Todd
2022-12-03 11:01       ` Daniel Lipshitz
2022-12-03 11:51         ` Daniel Lipshitz
2022-12-03 12:12         ` Peter Todd
2022-12-03 13:17           ` Daniel Lipshitz
2022-12-03 14:03             ` Daniel Lipshitz
2022-12-05 12:21               ` angus
     [not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz

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=1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org \
    --to=dave@dtrt$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dario@muun$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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