From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 74B65C000B for ; Tue, 1 Feb 2022 08:32:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5D6DB60F6D for ; Tue, 1 Feb 2022 08:32:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=chia.net 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 unX47hllafcu for ; Tue, 1 Feb 2022 08:32:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4ED6760BA8 for ; Tue, 1 Feb 2022 08:32:24 +0000 (UTC) Received: by mail-lf1-x12f.google.com with SMTP id i34so11903111lfv.2 for ; Tue, 01 Feb 2022 00:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZRKlxKmyo9an29KIS+sym9XB5FNWCVUXUKStX14CGs8=; b=BIiMNBDg7z4vv6swFtRxZ+a3kUbpjLbzCZuDL2v1bzapx8oSdQ/pWLW50C+9Mwc/AA NVJMcsf5LMdsOnuO8c2DDXci+lSa3uRtvMRGdko+jWa+wvHNCeGAJqPcrUCDiy16CEdX V4d7zn0ov/GnjSCfna/Kgvgb4Thsxt+lX/EvxPO2W/UX3tu2iSBMVti9zqY5HOMmFMyj JanZNOGbtef7axbCfbNCn7LGybcd0ffniy/+WRGhG/epIze1B7P9izodJIxlgqjtZQlP F/BS34L1pUe3UUXGqh5VWXPuq/U/y5nHmOtZ2CNBvTF/EyMeD4wY1oG/OLHYzhbXDTBs TG2g== 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:cc; bh=ZRKlxKmyo9an29KIS+sym9XB5FNWCVUXUKStX14CGs8=; b=SNPrRr+lf5HC+/0UqPBck06UWDezqYDTsuCzCt2NMlQwCcEaAPFMSraC0WnsTE6zQW a26M8i3KbobUreS3idYnCd6s2oqAz+/KzJad841IXEG7avkcHtSoTk0IMJ3r9OLQ/UNx 5W5Q+PAfTT7Z65pI4+V5KXwmBD+D1OUgx+STYkqTPUPejwL2fVxYbdPAVcyvVog44j2A YtAE1v6dcoWRUGdHkm4umcIxYxOUMQ9nW7lwSjW2upUUGWAbbuuMzbaSI3vKMgcacPWA TQhqoepwH2bnbEFrGpX00Sip8gTgo6ezt7Qdr1NPiy9zFPWuh8kS5535hojeiNNsXV7P 3PnQ== X-Gm-Message-State: AOAM532/k5SvIxILMEcMZLMSEmN7SnEdD3DtQgvVdBYWsrwNKVLSpe+C IJ84D4jxb68z7quQFYjlc6BELura4mlPmBWqQzg4e7i/k+Q= X-Google-Smtp-Source: ABdhPJy8OhKBZLRWhKczMjEWhn261MUmeqM0FXmSqnBhzAqsLDPcXhJ86+TnmRk8meZjqMYv1r1Aqzt5Jg8XXRnOOcQ= X-Received: by 2002:ac2:51d9:: with SMTP id u25mr18347123lfm.228.1643704342065; Tue, 01 Feb 2022 00:32:22 -0800 (PST) MIME-Version: 1.0 References: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org> In-Reply-To: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org> From: Bram Cohen Date: Tue, 1 Feb 2022 00:32:09 -0800 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="0000000000006ccb1e05d6f0bddf" X-Mailman-Approved-At: Tue, 01 Feb 2022 09:13:31 +0000 Cc: Bitcoin Protocol Discussion 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 08:32:25 -0000 --0000000000006ccb1e05d6f0bddf Content-Type: text/plain; charset="UTF-8" On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote: > > > On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > What flag? > The opt-in RBF flag in transactions. > 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 there > isn't a whole block's worth of transactions the one with higher total value > should win. > > These are not distinct scenarios. The rational choice is the highest fee > block-valid subgraph of the set of unconfirmed transactions, in both cases > (within the limits of what is computationally feasible of course). > It's weird because which of two or more conflicting transactions should win can oscillate back and forth depending on other stuff going on in the mempool. There's already a bit of that with child pays but this is stranger and has more oddball edge cases about which transactions to route. --0000000000006ccb1e05d6f0bddf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 31, 2022 at 4:08 PM Eric = Voskuil <eric@voskuil.org> wr= ote:

<= div dir=3D"ltr">
On Jan 31, 2022, at 15:15, Br= am Cohen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
<= div dir=3D"ltr">
Is it stil= l 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 t= he RBF flag in the direction of always assuming it's on.
What flag?
The opt-in RBF flag in transactions.
=C2=A0
There are two different common regimes which resu= lt 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 confli= cting transactions the one with the higher fee rate should win. In the othe= r case where there isn't a whole block's worth of transactions the = one with higher total value should win.
These are not distinct scenarios. The rational choice is the highest = fee block-valid subgraph of the set of unconfirmed transactions, in both ca= ses (within the limits of what is computationally feasible of course).

It's weird because which = of two or more conflicting transactions should win can oscillate back and f= orth depending on other stuff going on in the mempool. There's already = a bit of that with child pays but this is stranger and has more oddball edg= e cases about which transactions to route.
--0000000000006ccb1e05d6f0bddf--