Return-Path: <eric@voskuil.org> Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 619AAC000B for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 1 Feb 2022 00:08:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5088560B1B for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 1 Feb 2022 00:08:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com 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 bS7r5dPz0O3O for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 1 Feb 2022 00:08:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8BEA6606A9 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 1 Feb 2022 00:08:32 +0000 (UTC) Received: by mail-pf1-x431.google.com with SMTP id e28so14304333pfj.5 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 31 Jan 2022 16:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:date:message-id :references:in-reply-to:subject:to; bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=; b=pd+6jVWptLtqfQMdkfqR7yqasII8WcsNwlJcruGB0nTOpyxcDg4Kw8MBG2K9zns0GA 4sxgz0UFwKNnATBYP6rexrz1qW59V2p68T9bWwwvZfeZv5QS92BnEGaeAlo+zeXbCDFS jrXU2DQ3HY1tpNmfqp+CEUGybH2wH+QeSv9ZsnpypKrOU9GPNB08oPWDeleJANwUsMhW zoL+X5VaPB2avvMMBYtNKW+JFsyWzr/WBkw22pTgO11wqOf2xr3fWGA9hvG0utuD4nq4 zomMeUqR/gjA4NbXg8CFBnOLRx22AwzmsRbiaX3Rl8lKhGUnDohQZLLucMSkiIpmXQFe YVkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:references:in-reply-to:subject:to; bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=; b=0wP9vrF91eNTGh42BsozgwKinAYtUDfG4CE7ZQbD6ggz7IbMvO1/kOSmlE8X3Etjrc AR3HgpM6HvtgKkmjRWkIYGhTt73D0lifRy0a3PNuPLLHEqNRCsC0nDaMUVZmM3yj3zP0 7jGzSxxBisFKaNtD6B13AGkopXBnUGnV+pFwh7mJzvezw8eh0ebpxsrW+Sl9hXSelGCq ikaikf7crcV1pbGxZ/BE/9COzcfBveiWWLrej8My/0DcneyH6T6C2NJj9lWT7ArnEKAs Jxd8V5WR5zaTTg0jGftTv4kg+0IYAvxgs0Pq0qvcVVzGM9vvmtcnfVu1/N+Amuf9peu+ Q0Sg== X-Gm-Message-State: AOAM533cStvNVVSnmgkOvwS5i391bEFGC+01+2nPGnCcBuW8RXJ5oR5A N3xVSefCZvPa8FFkSBKv3m0RaA== X-Google-Smtp-Source: ABdhPJxA3/Sw6FEfINVhwaZTb3HT46wRQujDiGDw4LlW5zWCBJzubKPIVZdBmlAl2rI3VySWsNIAEA== X-Received: by 2002:aa7:8595:: with SMTP id w21mr22335245pfn.18.1643674111788; Mon, 31 Jan 2022 16:08:31 -0800 (PST) Received: from smtpclient.apple ([2601:600:9c00:1d0::ff78]) by smtp.gmail.com with ESMTPSA id j14sm20151726pfj.218.2022.01.31.16.08.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 16:08:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305 Content-Transfer-Encoding: 7bit From: Eric Voskuil <eric@voskuil.org> Mime-Version: 1.0 (1.0) Date: Mon, 31 Jan 2022 16:08:30 -0800 Message-Id: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org> References: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com> In-Reply-To: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com> To: Bram Cohen <bram@chia.net>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> X-Mailer: iPhone Mail (19C63) 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 01 Feb 2022 00:08:33 -0000 --Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote: =E2=80=A6 > Is it still verboten to acknowledge that RBF is normal behavior and disall= owing it is the feature, and that feature is mostly there to appease some pe= ople's delusions that zeroconf is a thing? It seems a bit overdue to disresp= ect the RBF flag in the direction of always assuming it's on. What flag? >> - **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. >=20 > There are two different common regimes which result in different incentivi= zed 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 blo= ck's worth of transactions the one with higher total value should win. These are not distinct scenarios. The rational choice is the highest fee blo= ck-valid subgraph of the set of unconfirmed transactions, in both cases (wit= hin the limits of what is computationally feasible of course). When collecting pooled txs the only issue is DoS protection, which is simply= a question of what any given miner is willing to pay, in terms of disk spac= e, to archive conflicts for the opportunity to optimize block reward. > It would be nice to have consolidated logic which handles both, it seems t= he issue has to do with the slope of the supply/demand curve which in the fi= rst case is gentle enough to keep the one transaction from hitting the rate b= ut in the second one is basically infinite. --Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><meta http-equiv=3D"conten= t-type" content=3D"text/html; charset=3Dutf-8"><div dir=3D"ltr"></div><div d= ir=3D"ltr"><br></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Jan 3= 1, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.org> wrote:</blockquote></div><div dir=3D"ltr"><br></div>=E2=80=A6= </div><div dir=3D"ltr"><br><blockquote type=3D"cite"><div dir=3D"ltr"><div d= ir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><br></blockquote><div>Is it still verboten to acknowledge that RB= F 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 s= eems a bit overdue to disrespect the RBF flag in the direction of always ass= uming it's on.</div></div></div></div></blockquote><div><br></div><div>What f= lag?</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><d= iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- *= *Incentive Compatibility**: Ensure that our RBF policy would not<br> accept replacement transactions which would decrease fee profits<br> of a miner. In general, if our mempool policy deviates from what is<b= r> economically rational, it's likely that the transactions in our<br> mempool will not match the ones in miners' mempools, making our<br> fee estimation, compact block relay, and other mempool-dependent<br> functions unreliable. Incentive-incompatible policy may also<br> encourage transaction submission through routes other than the p2p<br> network, harming censorship-resistance and privacy of Bitcoin payments.<br><= /blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>= <div>These are not distinct scenarios. The rational choice is the highest fe= e block-valid subgraph of the set of unconfirmed transactions, in both cases= (within the limits of what is computationally feasible of course).</div><di= v><br></div><div>When collecting pooled txs the only issue is DoS protection= , which is simply a question of what any given miner is willing to pay, in t= erms of disk space, to archive conflicts for the opportunity to optimize blo= ck reward.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"l= tr"><div class=3D"gmail_quote"><div>It would be nice to have consolidated lo= gic which handles both, it seems the issue has to do with the slope of the s= upply/demand curve which in the first case is gentle enough to keep the one t= ransaction from hitting the rate but in the second one is basically infinite= .</div></div></div><br></div></blockquote></div></body></html>= --Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305--