From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3EEE9C000B for ; Thu, 17 Feb 2022 18:18:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 25B5E403E7 for ; Thu, 17 Feb 2022 18:18:25 +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, 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 pOUUXPIok5PS for ; Thu, 17 Feb 2022 18:18:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by smtp2.osuosl.org (Postfix) with ESMTPS id D217140223 for ; Thu, 17 Feb 2022 18:18:23 +0000 (UTC) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-2d07ae0b1c5so41315857b3.5 for ; Thu, 17 Feb 2022 10:18:23 -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 :cc; bh=kQSFI4ywqYUHiUb1kmYxsEgtRTgQWjHMj0hm3cOxtYc=; b=QV0ze6dsI+SWoH9x8lcJRKpHriRVre6y0JRIHwkAKmlHw5TDGp/EuuGL4ts6zB3R3+ eD63Lrhjc0rkXk6oyu+beQQg694gKvtn3ihMJoeN++Zme3/xndnwy4QUQZI5JZyVDMT7 1XwSuecpUpHe4SuL8234AC+1QYc5kCHgH0P5dttfWN4LVGv+Ua5z7AjLByijZ75KWX2O ZoNUxP66S2gM22Q7o39kk6HOH8UXMD31ezluUFwYml21+n1nqd4uoN2B2BujAwKo3Q5w 2rDA8U+B0oApvFvjwpF3tg6+KlM20r8IaICDVKMjzHT+IK7iHymfp35GSsRU0zuwIjxp 6E0A== 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=kQSFI4ywqYUHiUb1kmYxsEgtRTgQWjHMj0hm3cOxtYc=; b=Yl63xlbEM+vUsknrOJHf6Zp03EYCy5y20G0TJD6OUCCF3kjcnMGV2HsWbHhxNaSjDu Vfe1Hm8NDe49qz1QoFlyKwH6UhrzjWI8Y8+Hj9gf+gDE4hK5EzhkHG/qGIyeGkDZkDSB 4bTn2bCLSpG6MhtReYPz1a3o0QsOpM4FXUafPvluSQEVmnOMqGGhdMNFtbB5FhYiwBy3 RiYvDDYphcDjlTQqE3Iaw1KgF2cBjVZPnvpzxJVJsdhdBIuk8goOIvOyJesnmLl9Ti3n UhQ4Shu0l0H1C1x+XRREnAGsigKpFETW2lokKNVcNIvfhg5CGrMIYX12XsVcvfd/MTm2 5ECQ== X-Gm-Message-State: AOAM533+lygNZE8MVl3TCijoHZgSlZzYfgBas8ixWlxnZBYwfvluhiCd NYAWtHLXX0TfkwV6iMpSwDIvdX5/eML6Lqj03uJZbz3S+PxvBg== X-Google-Smtp-Source: ABdhPJyiA9WhkA0H1zj9Op++N4BmNkq6XkymJrcBa3knsS+sWP9czSXPNmp0aDTTIA/8OYGMaE57iIWi8au8u8iHRt0= X-Received: by 2002:a81:3d8c:0:b0:2d1:de9a:c86e with SMTP id k134-20020a813d8c000000b002d1de9ac86emr3652703ywa.459.1645121902638; Thu, 17 Feb 2022 10:18:22 -0800 (PST) MIME-Version: 1.0 References: <9Vw6LCkr2d2uOBanXeIuGxA1fUGGOeV1OHlgBifbmij1Afs0ISjfKK-vmcnRZfBG4GwJhIVLMisjvS_zohS-cW0FkzZaCKa6Mn7VWolznJs=@protonmail.com> <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com> <20220217143225.GB1429@erisian.com.au> In-Reply-To: <20220217143225.GB1429@erisian.com.au> From: "James O'Beirne" Date: Thu, 17 Feb 2022 13:18:11 -0500 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="0000000000009e7c2b05d83acab7" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Thoughts on fee bumping 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: Thu, 17 Feb 2022 18:18:25 -0000 --0000000000009e7c2b05d83acab7 Content-Type: text/plain; charset="UTF-8" > Is it really true that miners do/should care about that? De facto, any miner running an unmodified version of bitcoind doesn't care about anything aside from ancestor fee rate, given that the BlockAssembler as-written orders transactions for inclusion by descending ancestor fee-rate and then greedily adds them to the block template. [0] If anyone has any indication that there are miners running forks of bitcoind that change this behavior, I'd be curious to know it. Along the lines of what AJ wrote, optimal transaction selection is NP-hard (knapsack problem). Any time that a miner spends deciding how to assemble the next block is time not spent grinding on the nonce, and so I'm skeptical that miners in practice are currently doing anything that isn't fast and simple like the default implementation: sorting fee-rate in descending order and then greedily packing. But it would be interesting to hear evidence to the contrary. --- You can make the argument that transaction selection is just a function of mempool contents, and so mempool maintenance criteria might be the thing to look at. Mempool acceptance is gated based on a minimum feerate[1]. Mempool eviction (when running low on space) happens on the basis of max(self_feerate, descendant_feerate) [2]. So even in the mempool we're still talking in terms of fee rates, not absolute fees. That presents us with the "is/ought" problem: just because the mempool *is* currently gating only on fee rate doesn't mean that's optimal. But if the whole point of the mempool is to hold transactions that will be mined, and if there's good reason that txns are chosen for mining based on fee rate (it's quick and good enough), then it seems like fee rate is the approximation that should ultimately prevail for txn replacement. [0]: https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320 [1]: https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106 [2]: https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144 --0000000000009e7c2b05d83acab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is it really true that miners do/should care about th= at?

De facto, any miner running an unmodified version of bitcoind do= esn't
care about anything aside from ancestor fee rate, given that t= he
BlockAssembler as-written orders transactions for inclusion by
des= cending ancestor fee-rate and then greedily adds them to the block
templ= ate. [0]

If anyone has any indication that there are miners running = forks of
bitcoind that change this behavior, I'd be curious to know = it.

Along the lines of what AJ wrote, optimal transaction selection = is
NP-hard (knapsack problem). Any time that a miner spends deciding how=
to assemble the next block is time not spent grinding on the nonce, and=
so I'm skeptical that miners in practice are currently doing anythi= ng
that isn't fast and simple like the default implementation: sorti= ng
fee-rate in descending order and then greedily packing.

But i= t would be interesting to hear evidence to the contrary.

---

= You can make the argument that transaction selection is just a function
= of mempool contents, and so mempool maintenance criteria might be the
th= ing to look at. Mempool acceptance is gated based on a minimum
feerate[1= ].=C2=A0 Mempool eviction (when running low on space) happens on
the bas= is of max(self_feerate, descendant_feerate) [2]. So even in the
mempool = we're still talking in terms of fee rates, not absolute fees.

T= hat presents us with the "is/ought" problem: just because the mem= pool
*is* currently gating only on fee rate doesn't mean that's = optimal. But
if the whole point of the mempool is to hold transactions t= hat will be
mined, and if there's good reason that txns are chosen f= or mining based
on fee rate (it's quick and good enough), then it se= ems like fee rate
is the approximation that should ultimately prevail fo= r txn
replacement.


[0]:
https://github.com/bi= tcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320
[1]:
https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106
[2]:
https://github.com/bitcoin/bitcoin/blob/master/= src/txmempool.cpp#L1138-L1144
--0000000000009e7c2b05d83acab7--