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 75F55C000B for ; Wed, 2 Feb 2022 10:21:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 5B19D403A2 for ; Wed, 2 Feb 2022 10:21:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 RwgAYFW2CjlR for ; Wed, 2 Feb 2022 10:21:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8647840012 for ; Wed, 2 Feb 2022 10:21:26 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1nFClN-0001bM-Oy; Wed, 02 Feb 2022 20:21:23 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 02 Feb 2022 20:21:16 +1000 Date: Wed, 2 Feb 2022 20:21:16 +1000 From: Anthony Towns To: Bastien TEINTURIER , Bitcoin Protocol Discussion Message-ID: <20220202102116.GB5140@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - 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: Wed, 02 Feb 2022 10:21:27 -0000 On Tue, Feb 01, 2022 at 10:30:12AM +0100, Bastien TEINTURIER via bitcoin-dev wrote: > But do you agree that descendants only matter for DoS resistance then, > not for miner incentives? There's an edge case where you're replacing tx A with tx X, and X's fee rate is higher than A's, but you'd be obsoleting descendent txs (B, C, D...) and thus replacing them with unrelated txs (L, M, N...), and the total feerate/fees of A+B+C+D... is nevertheless higher than X+L+M+N... But I think that's probably unusual (transactions D and L are adjacent in the mempool, that's why L is chosen for the block; but somehow there's a big drop off in value somewhere between B/C/D and L/M/N), and at least today, I don't think miners consider it essential to eke out every possible sat in fee income. (If, as per your example, you're actually replacing {A,B,C,D} with {X,Y,Z,W} where X pays higher fees than A and the package in total pays either the same or higher fees, that's certainly incentive compatible. The tricky question is what happens when X arrives on its own and it might be that no one ever sends a replacement for B,C,D) > The two policies I proposed address miner incentives. I think they're > insufficient to address DoS issues. But adding a 3rd policy to address > DoS issues may be a good solution? >>> 1. The transaction's ancestor absolute fees must be X% higher than the >>> previous transaction's ancestor fees >>> 2. The transaction's ancestor feerate must be Y% higher than the >>> previous transaction's ancestor feerate Absolute fees only matter if your backlog's feerate drops off. If you've got 100MB of txs offering 5sat/vb, then exchanging 50kB at 5sat/vb for 1kB at 6sat/vb is still a win: your block gains 1000 sats in fees even though your mempool loses 245,000 sats in fees. But if your backlog's feerate does drop off, *and* that matters, then I don't think you can ignore the impact of the descendent transactions that you might not get a replacement for. I think "Y% higher" rather than just "higher" is only useful for rate-limiting, not incentive compatibility. (Though maybe it helps stabilise a greedy algorithm in some cases?) Cheers, aj