From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D2EEC002D for ; Fri, 7 Oct 2022 21:37:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 54B7560ADB for ; Fri, 7 Oct 2022 21:37:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 54B7560ADB Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=QGF2gQYK X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9u4UnIqppj6 for ; Fri, 7 Oct 2022 21:37:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C982F60AB9 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by smtp3.osuosl.org (Postfix) with ESMTPS id C982F60AB9 for ; Fri, 7 Oct 2022 21:37:51 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id o5so3612975wms.1 for ; Fri, 07 Oct 2022 14:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muun-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GR/d6el84e6/zzZs1WnR/MaPlAPAtIvQaCueeFcVgXc=; b=QGF2gQYKMK2auNlZ1AT3XwpKS1S3hoxIvC0/bYdZ7ljwtoVUXzJpKLoa615RdKhUUr bozfeMAZNU819JAqh/WsCIL4yUjf49GRz3iAjfDt+k3xmOY2/7y3PhIF/EKkM5996+UB fQ7cLb2UyK9o+btQxxhbC43+o095DN7rM8Hxew95fnNkvyiqdnQ1QIutbw+tBAep33VU VhI5cdD/yTLs4GHDFzrxz4+XMsvINAQhiBDUUy7nmI6B7vX+qScu4LdMUvRW0jQG33Ji EAkgNa9svySLePG/ieEk+pmNMfoDP8KqJJubc+xniBrMCKQDGrLZheDffQYicUzTpucb sHjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GR/d6el84e6/zzZs1WnR/MaPlAPAtIvQaCueeFcVgXc=; b=RjTZaxPLq962rt6HCXM85HwTJmhw9C9vXMrv3hwfWvFGo+IBSNyn4sL0t5vn05IiHS PCsXhIJkXdrRVIwAaHFZAMVC5HS3dNbmY/0BpO8NAb6rSeyoazjaqgozUw6ASoykkfP7 l4lk80o428MWTPO7Ym7WgzHY/fba3luQzodZlXLKeJ0+DeiEwLG6Jvs0eZf386MuIvl3 lEIrWjVNfXhVet7JkU08q/9YGRpop0KBSDgsORR1soMGampWnG432xB9ZfyE5bWR9xsh 3uWOUQdC0XNxLoF1KqY3hnzLrQ02KrN9Kvke3n4h911EURcpPcORyQ3aZGYkoneTjsOo Gfqg== X-Gm-Message-State: ACrzQf3nzIoyAU1oPuPZ3dLmsoVWKmYd/uZROnE2E8mltbjxgHv1Idqh ODH6B8pv/ZKt4MttOnMQ3l1sIJ7Hve0+HTEdIGd+xrAcZv9scA== X-Google-Smtp-Source: AMsMyM7gvNli1jkLnBjqHxvtTy8vOO5vldVm2Ok9zven+NPe0ZLcId8LXmhv+J0q1mDPRmLWLEzy51mqIOXRWmefrBE= X-Received: by 2002:a05:600c:3582:b0:3c2:7002:2cb0 with SMTP id p2-20020a05600c358200b003c270022cb0mr4578619wmq.170.1665178669900; Fri, 07 Oct 2022 14:37:49 -0700 (PDT) MIME-Version: 1.0 References: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org> In-Reply-To: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org> From: Dario Sneidermanis Date: Fri, 7 Oct 2022 18:37:38 -0300 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="0000000000001b825305ea789f0f" X-Mailman-Approved-At: Fri, 07 Oct 2022 21:45:22 +0000 Cc: Bitcoin Protocol Discussion 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 21:37:53 -0000 --0000000000001b825305ea789f0f Content-Type: text/plain; charset="UTF-8" Hello David, Thanks for the fast answer! It seems I missed the link to the PR, sorry for the confusion. I'm referring to the opt-in flag for full-RBF from #25353 (https://github.com/bitcoin/bitcoin/pull/25353). On Fri, Oct 7, 2022 at 2:21 PM David A. Harding wrote: > 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. The "activation" of full-RBF after deployment works in a pretty interesting way: 1. If no miner is running full-RBF or there aren't easily accessible connected components of nodes running full-RBF connected to the miners, then full-RBF is mostly ineffective since replacements aren't relayed and/or mined. 2. There's a middle ground where *some* connected components of full-RBF nodes can relay and mine replacements, where some full-RBF nodes will be able to replace via full-RBF and some won't (depending on their peers). 3. With high enough adoption, the relay graph has enough density of full-RBF nodes that almost all full-RBF nodes can replace transactions via full-RBF. While there have been forks of Bitcoin Core (like Bitcoin Knots) running full-RBF for a while, today most nodes (by far) are running Bitcoin Core. So, Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to be picked up by most node operators. Making the flag opt-out (ie. on by default) would make it easier still. We are dealing with a gradient going from hard enough that we are still in 1, to easy enough that we get to 3. The question then is whether an opt-in flag for full-RBF will have enough adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its objective of allowing nodes participating in multi-party funding protocols to assume that they can rely on full-RBF. If it is, then zero-conf applications will be at severe risk (per the logic in the initial email). --0000000000001b825305ea789f0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello David,

Thanks for the fast a= nswer! It seems I missed the link to the PR,=C2=A0sorry for the
confusion. I'm referring to the opt-in flag for full-RBF fro= m #25353
(http= s://github.com/bitcoin/bitcoin/pull/25353).

On Fri, Oct 7, 2022 at 2= :21 PM David A. Harding <dave@dtrt.org<= /a>> wrote:
O= n 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> Hello list,
>
> I'm Dario, from Muun wallet [...] we've been reviewing the lat= est
> bitcoin core release
> candidate [...] we understood we had at least a year from the initial<= br> > opt-in=C2=A0 deployment until opt-out was deployed, giving us enough t= ime to
> adapt
> Muun to the new policies. However, when reviewing the 24.0 release > candidate
> just a few=C2=A0 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.=C2=A0 There are two R= BF-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]=C2=A0 There have been software forks of Bitcoin Cor= e
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.

The "a= ctivation" of full-RBF after deployment works in a pretty interesting = way:

1. If no miner is running full-RBF or there aren't easily a= ccessible connected
=C2=A0 =C2=A0components of nodes running full-RBF co= nnected to the miners, then full-RBF
=C2=A0 =C2=A0is mostly ineffective = since replacements aren't relayed and/or mined.
2. There's a mid= dle ground where *some* connected components of full-RBF nodes
=C2=A0 = =C2=A0can relay and mine replacements, where some full-RBF nodes will be ab= le to
=C2=A0 =C2=A0replace via full-RBF and some won't (depending on= their peers).
3. With high enough adoption, the relay graph has enough = density of full-RBF
=C2=A0 =C2=A0nodes that almost all full-RBF nodes ca= n replace transactions via full-RBF.

While there have been forks of = Bitcoin Core (like Bitcoin Knots) running
full-RBF for a while, today mo= st nodes (by far) are running Bitcoin Core. So,
Bitcoin Core adding an o= pt-in flag (ie. off by default) makes it easier to be
picked up by most = node operators. Making the flag opt-out (ie. on by default)
would make i= t easier still. We are dealing with a gradient going from hard
enough th= at we are still in 1, to easy enough that we get to 3.

The question = then is whether an opt-in flag for full-RBF will have enough
adoption to= get us from 1 to 2. If it isn't, then #25353 won't meet its
obj= ective of allowing nodes participating in multi-party funding protocols to<= br>assume that they can rely on full-RBF. If it is, then zero-conf applicat= ions
will be at severe risk (per the logic in the initial email).

--0000000000001b825305ea789f0f--