Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6F9F0C000B for ; Tue, 1 Feb 2022 00:42:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 578BB4015F for ; Tue, 1 Feb 2022 00:42:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcgC5Gh6T6E3 for ; Tue, 1 Feb 2022 00:42:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by smtp2.osuosl.org (Postfix) with ESMTPS id C30C340120 for ; Tue, 1 Feb 2022 00:42:38 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id s9so28663236wrb.6 for ; Mon, 31 Jan 2022 16:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=TyqNktyJdc4Ux73CxWz7HUMTjusDsSCAXWv/VqSb1O4=; b=M2nz4DJnVbuGOpI4Qzz6nMkEyN5XV5jjakMpN/Ljrth3lKkxuQ2jrEbYxxFaCIHk+6 gP+YUHQU117BZMmBM0Sxh67lYHd1klpPy2tfrSe/8mjAZhyoZsQnzDJkmrXTI+JGOPqg XxTcRhui0riUYb+0H2cJVo/3F1iwHkJl5p3HYA1XYuC6jPxugJCCLx1jrcn4QvGh77Q6 FP5F07gRxy40Wotyk6zTVm5AQm3l+xrc5eqq+PN/ZHoxy/eA6fv4NFtrN1+sSZlPlD6w kPoL6VOOKKMlpDszoazOYtH8REynSGdxSabXYOVWQQmcnq4T5eagTJU3/S3afNm6ZacA RbdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TyqNktyJdc4Ux73CxWz7HUMTjusDsSCAXWv/VqSb1O4=; b=565T5nIg7y3Zb5TOdf+S8Kx/aL1KkG+VxyHxPucKLInCKFYasHj3m1VyGzXEBoY2If dnwFpoMVXmrbUooXMvoMp5ar9HlFR7WLCqvuZv6jAXdbQ7EUBKHWi/4y+flrEZlu/z6L XeYB9DVkExeGlJRH8ewH/r19UEc5bXMFdr6igh/JyxL+R+b+RG3s7R7/ISHXVkBLLS1v hfwjIcr+QM5QkkVVsoj0GfNJmBXmM0TM760Kx/xHQNdYnXaNIyPiR7+4NxR7dCCVq88R 7/LwNi3Uy7sLoZMAzVem0/YT4H1LWcIEIueEtd6iU5ja4wdsNPDLRz5ZM4Hwz0JHRulO 3WJA== X-Gm-Message-State: AOAM532naElMkpc2uWNuuXPtrRBtYxBPqUvsuNBI5uzIgML1K3Kl77JC bKGbH1TfeuCIukVba5j8rhMLKqOv0NFBUHAdDfJPnWDypGE= X-Google-Smtp-Source: ABdhPJwOBiAPmqXVAVOJGS3ZAK7IByiS+lASFZrAR5plhOehNzWz/AuaMi7j+GmKUBOxBqsQKde0X4fSbgZpAtM8qu4= X-Received: by 2002:a5d:4dc6:: with SMTP id f6mr19099415wru.255.1643676156975; Mon, 31 Jan 2022 16:42:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 31 Jan 2022 19:42:24 -0500 Message-ID: To: Bram Cohen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000765de105d6ea2d56" X-Mailman-Approved-At: Tue, 01 Feb 2022 00:45:40 +0000 Subject: Re: [bitcoin-dev] Improving RBF policy 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: Tue, 01 Feb 2022 00:42:40 -0000 --000000000000765de105d6ea2d56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is it still verboten to acknowledge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to appease some people's delusions that zeroconf is a thing? It seems a bit overdue to disrespect the RBF flag in the direction of always assuming it's on. If you're thinking about the opt-in flag, not the RBF rules, please see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.ht= ml The latest state of the discussion is here : https://gnusha.org/bitcoin-core-dev/2021-10-21.log A gradual, multi-year deprecation sounds to be preferred to ease adaptation of the affected Bitcoin applications. Ultimately, I think it might not be the last time we have to change high-impact tx-relay/mempool rules and a more formalized Core policy deprecation process would be good. Le lun. 31 janv. 2022 =C3=A0 18:15, Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Gloria Zhao wrote: > >> >> This post discusses limitations of current Bitcoin Core RBF policy and >> attempts to start a conversation about how we can improve it, >> summarizing some ideas that have been discussed. Please reply if you >> have any new input on issues to be solved and ideas for improvement! >> > > Is it still verboten to acknowledge that RBF is normal behavior and > disallowing it is the feature, and that feature is mostly there to appeas= e > some people's delusions that zeroconf is a thing? It seems a bit overdue = to > disrespect the RBF flag in the direction of always assuming it's on. > > >> - **Incentive Compatibility**: Ensure that our RBF policy would not >> accept replacement transactions which would decrease fee profits >> of a miner. In general, if our mempool policy deviates from what is >> economically rational, it's likely that the transactions in our >> mempool will not match the ones in miners' mempools, making our >> fee estimation, compact block relay, and other mempool-dependent >> functions unreliable. Incentive-incompatible policy may also >> encourage transaction submission through routes other than the p2p >> network, harming censorship-resistance and privacy of Bitcoin payments. >> > > There are two different common regimes which result in different > incentivized behavior. One of them is that there's more than a block's > backlog in the mempool in which case between two conflicting transactions > the one with the higher fee rate should win. In the other case where ther= e > isn't a whole block's worth of transactions the one with higher total val= ue > should win. It would be nice to have consolidated logic which handles bot= h, > it seems the issue has to do with the slope of the supply/demand curve > which in the first case is gentle enough to keep the one transaction from > hitting the rate but in the second one is basically infinite. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000765de105d6ea2d56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is it still verboten to acknowled= ge that RBF is normal behavior and disallowing it is the feature, and that feature is mostly there to=20 appease some people's delusions that zeroconf is a thing? It seems a bi= t overdue to disrespect the RBF flag in the direction of always assuming=20 it's on.

If you're thinking about the opt-in flag, not= the RBF rules, please see https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2021-June/019074.html
The latest state = of the discussion is here : https://gnusha.org/bitcoin-core-dev/2021-10-21.log
<= /div>A gradual, multi-year deprecation sounds to be preferred to ease adapt= ation of the affected Bitcoin applications.

Ultimately, I thi= nk it might not be the last time we have to change high-impact tx-relay/mem= pool rules and a more formalized Core policy deprecation process would be g= ood.



Le=C2=A0lun. 31= janv. 2022 =C3=A0=C2=A018:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> a =C3=A9crit=C2=A0:
Gloria Zhao wrote:

This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!

Is it still verboten to acknowledge that RBF = is normal behavior and disallowing it is the feature, and that feature is m= ostly there to appease some people's delusions that zeroconf is a thing= ? It seems a bit overdue to disrespect the RBF flag in the direction of alw= ays assuming it's on.
=C2=A0
- **Incentive Compatibility**: Ensure that our RBF p= olicy would not
=C2=A0 accept replacement transactions which would decrease fee profits
=C2=A0 of a miner. In general, if our mempool policy deviates from what is<= br> economically rational, it's likely that the transactions in our
mempool will not match the ones in miners' mempools, making our
fee estimation, compact block relay, and other mempool-dependent
functions unreliable. Incentive-incompatible policy may also
encourage transaction submission through routes other than the p2p
network, harming censorship-resistance and privacy of Bitcoin payments.
=

There are two different common regimes whi= ch result in different incentivized behavior. One of them is that there'= ;s more than a block's backlog in the mempool in which case between two= conflicting transactions the one with the higher fee rate should win. In t= he other case where there isn't a whole block's worth of transactio= ns the one with higher total value should win. It would be nice to have con= solidated logic which handles both, it seems the issue has to do with the s= lope of the supply/demand curve which in the first case is gentle enough to= keep the one transaction from hitting the rate but in the second one is ba= sically infinite.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000765de105d6ea2d56--