From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2BDD4C002D for ; Fri, 7 Oct 2022 17:21:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 070FF81025 for ; Fri, 7 Oct 2022 17:21:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 070FF81025 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs-PHmJI2Klt for ; Fri, 7 Oct 2022 17:21:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0ABE281D0C Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0ABE281D0C for ; Fri, 7 Oct 2022 17:21:31 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 5B88F2800050; Fri, 7 Oct 2022 10:21:29 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Fri, 7 Oct 2022 10:21:29 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 07 Oct 2022 07:21:29 -1000 From: "David A. Harding" To: Dario Sneidermanis , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 663c.63406019.22313.0 Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2022 17:21:33 -0000 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