From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 963F1C000B for ; Sat, 12 Feb 2022 19:45:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8565F81AF3 for ; Sat, 12 Feb 2022 19:45:03 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKfT14bzbGAf for ; Sat, 12 Feb 2022 19:45:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6238881A8E for ; Sat, 12 Feb 2022 19:45:01 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id p14so5195665ejf.11 for ; Sat, 12 Feb 2022 11:45:01 -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=C9VY4se8hSso9/dpCPJBFw0BSDn79Rq1pKLz4FvjBQc=; b=Xs1OlgA21UBD+fTJ7rdRAc+psjXdTtjMS0G8LpxoJuSwXCQXYC/TwzksbrE7QCkY94 bLUQVXpWEv4tjiUmcz5sUP8rkqzaglVxJzWKPPHMurzHiS6LtfO16+xG+lm0wMKRyFfg jaGn3UhL7gVQU7CQ+HcyR8PNpivhEhXkjJz3Cnz+Ps0u5CrfRoCCFTQBe4JeZ/UCcfzO UW0HtJYp1NBcF07bXelkqSLxtkrG2nJ9UwHgd0ChT0IDdM0ONC+vl8MDI/Cjf3iLd5kV M6/1RXcWcub+V8DkYXRmD5+QXwQZsHQSYWQYPHvnkS4kVBJ5+XdCqm2LQWg1Rxv/zbGO Rc9A== 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=C9VY4se8hSso9/dpCPJBFw0BSDn79Rq1pKLz4FvjBQc=; b=GxNJp+vmM/pXAOPmfN22iD6eZ5BM12ua4fksYuHbMidKiYuQlqi9NS0XZF5w/0zs2W UPco+asNVaLurplul0A0aCfJKN/ebegf+gwc1o4HsorMobZbtGj7GM078EETeFOHjBJP Ei2e7nVsYUe5YbGxmyTTlTkY+rmNUCPq+fNbF/K1k0bDId0hmzrha/ji/JiB3xoHggbJ EmZ59JgvvHTgvuGw700V5/n5ZtxuYsZEe+caca7/8lXRYFMom2CuMp1ZTj95VGJ+SwYB lozA9Q93GwBlnMyEAb8pLg7LUpFsrmqxnnge637ejTuiAEng9gTB81iQR50xeJZ04MSn u5+w== X-Gm-Message-State: AOAM531FGfQUmUiGbNH1I2LsQNNSBFyDse2G9VZOqEPhqCkJzc6UnlnR rCkN07/adhGtG8XHFp5Zu06XZvI9jKSR79gR3H0= X-Google-Smtp-Source: ABdhPJy1Z9ahuX2WE68D4QDhOdYuVIKpE9qfDC3EzS+eUUHh+a+HsRWsm6rCDMst40oR7dkPmEG6I9BqliJFH31MYVY= X-Received: by 2002:a17:906:c154:: with SMTP id dp20mr5597295ejc.184.1644695099399; Sat, 12 Feb 2022 11:44:59 -0800 (PST) MIME-Version: 1.0 References: <9Vw6LCkr2d2uOBanXeIuGxA1fUGGOeV1OHlgBifbmij1Afs0ISjfKK-vmcnRZfBG4GwJhIVLMisjvS_zohS-cW0FkzZaCKa6Mn7VWolznJs=@protonmail.com> <4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com> In-Reply-To: <4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com> From: Billy Tetrud Date: Sat, 12 Feb 2022 13:44:41 -0600 Message-ID: To: darosior , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000029e4eb05d7d76bdc" X-Mailman-Approved-At: Sat, 12 Feb 2022 20:02:54 +0000 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: Sat, 12 Feb 2022 19:45:03 -0000 --00000000000029e4eb05d7d76bdc Content-Type: text/plain; charset="UTF-8" With respect to the disagreement/misunderstanding about the "<1vMB in the mempool" case, I think it's important to be clear about what the goals of relay policy are. Should the goal be to only relay transactions that increase miner revenue? Sure ideally, because we want to minimize load on the network. But practically, getting that goal 100% probably involves tradeoffs of diminishing returns. The only way to ensure that a transaction is only relayed when it increases miner revenue is to make relay rules exactly match miner inclusion rules. And since we don't want to (nor can we) force miners to do transaction inclusion the same as each other, we certainly can't realistically produce an environment where relay rules exactly match miner inclusion rules. So I think the goal should *not *be strictly minimal relay, because it's not practical and basically not even possible. Instead the goal should be some close-enough approach. This relates to the "<1vMB in the mempool" case because the disagreement seems to be related to what trade offs to make. A simple rule that the fee-rate must be bumped by at least X satoshi would indeed allow the scenario darosior describes, where someone can broadcast one large low-feerate transaction and then subsequently broadcast smaller but higher-feerate transactions. The question is: is that really likely be a problem? This can be framed by considering a couple cases: * The average case * The adversarial worst case In the average case, no one is going to be broadcasting any transactions like that because they don't need to. So in the average case, that scenario can be ignored. In the adversarial case however, some large actor that sends lots of transactions could spam the network any time blockchain congestion. What's the worst someone could do? Well if there's really simply not enough transactions to even fill the block, without an absolute-fee bump requirement, a malicious actor could create a lot of spam. To the tune of over 8000 transactions (assuming a 1 sat/vb relay rule) for an empty mempool where the malicious actor sends a 2MB transaction with a 1 sat/vb fee, then a 1MB transaction with a 2 sat/vb, then 666KB transaction for 3 sat/vb etc. But in considering that this transaction would already take up the entire block, it would be just as effective for an attacker to send 8000 minimal sized transactions and have them relayed. So this method of attack doesn't gain the attacker any additional power to spam the network. Not to mention that nodes should be easily able to handle that load, so there's not much of an actual "attack" happening here. Just an insignificant amount of avoidable extra spent electricity and unnecessary internet traffic. Nothing that's going to make running a full node any harder. And in the case that there *are* enough transactions to fill the block (which I think is the normal case, and it really should become a rarity for this not to the case in the future), higher feerate transactions are always better unless you already overpaid for fees. Sure you can overpay and then add some spam by making successively higher feerate but smaller transactions, but in that case you've basically paid for all that spam up front with your original fee. So is it really spam? If you've covered the cost of it, then its not spam as much as it is stupid behavior. So I'm inclined to agree with O'Beirne (and Lisa Neigut) that valid transactions with feerate bumps should never be excluded from relay as long as the amount of the feerate bump is more than the node's minimum transaction fee. Doing that would also get rid of the spectre of transaction pinning. *I'm curious if there's some other type of scenario where removing the absolute fee bump rule would cause nodes to relay more transactions than they would relay in a full/congested mempool scenario*. We shouldn't care about spam that only happens when the network is quiet and can't bring network traffic above normal non-quiet loads because a case like that isn't a dos risk. On Fri, Feb 11, 2022 at 3:13 AM darosior via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Well because in the example i gave you this decreases the miner's reward. > The rule of increasing feerate you stated isn't always economically > rationale. > > > Note how it can also be extended, for instance if the miner only has > 1.5vMB of txs and is not assured to receive enough transactions to fill 2 > blocks he might be interested in maximizing absolute fees, not feerate. > > > Sure, we could make the argument that long term we need a large backlog of > transactions anyways.. But that'd be unfortunately not in phase with > today's reality. > > > -------- Original Message -------- > On Feb 11, 2022, 00:51, James O'Beirne < james.obeirne@gmail.com> wrote: > > > > It's not that simple. As a miner, if i have less than 1vMB of > transactions in my mempool. I don't want a 10sats/vb transaction paying > 100000sats by a 100sats/vb transaction paying only 10000sats. > > I don't understand why the "<1vMB in the mempool" case is even worth > consideration because the miner will just include the entire mempool in the > next block regardless of feerate. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --00000000000029e4eb05d7d76bdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With respect to the disagreement/misunderstanding about th= e=C2=A0 "<1vMB in the mempool" case, I think it's=C2=A0important t= o be clear about what the goals of relay policy are. Should the goal be to = only relay transactions that increase miner revenue? Sure ideally, because = we want to minimize load on the network. But practically, getting that goal= 100% probably involves tradeoffs of diminishing returns.=C2=A0

The only way to ensure that a transaction is only relayed when it i= ncreases miner revenue is to make relay rules exactly match miner inclusion= rules. And since we don't want to (nor can we) force miners to do tran= saction inclusion the same as=C2=A0each other, we certainly can't reali= stically produce an environment where relay rules exactly match miner inclu= sion rules.=C2=A0

So I think the goal should not = be strictly minimal relay, because it's not practical and basically not= even possible. Instead the=C2=A0goal should be some close-enough approach.= =C2=A0

This relates to the=C2=A0 "<1vMB in the mempool" case because the disagreement seems to = be related to what trade offs to make. A simple rule that the fee-rate must= be bumped by at least X satoshi would indeed allow the scenario darosior d= escribes, where someone can broadcast one large low-feerate=C2=A0transactio= n and then subsequently broadcast smaller but higher-feerate transactions. = The question is: is that really likely be a problem? This can be framed by = considering a couple cases:

* The average case
* The adversarial worst case

In the average= case, no one is going to be broadcasting any transactions like that becaus= e they don't need to. So in the average case, that scenario can be igno= red. In the adversarial case however, some large actor that sends lots of t= ransactions could spam the network any time blockchain congestion. What'= ;s the worst someone could do?=C2=A0

Well if there= 's really simply not enough transactions to even fill the block, withou= t an absolute-fee bump requirement, a malicious actor could create a lot of= spam. To the tune of over 8000 transactions (assuming a 1 sat/vb relay rul= e) for an empty mempool where the malicious actor sends a 2MB transaction w= ith a 1 sat/vb fee, then a 1MB transaction with a 2 sat/vb, then 666KB tran= saction for 3 sat/vb etc. But in considering that this transaction would al= ready take up the entire block, it would be just as effective for an attack= er to send 8000 minimal sized transactions and have them relayed. So this m= ethod of attack doesn't gain the attacker any additional power to spam = the network. Not to mention that nodes should be easily able to handle that= load, so there's not much of an actual "attack" happening he= re. Just an insignificant amount of avoidable extra spent electricity and u= nnecessary internet traffic. Nothing that's going to make running a ful= l node any harder.=C2=A0

And in the case that ther= e *are* enough transactions to fill the block (which I think is the normal = case, and it really should become a rarity for this not to the case in the = future), higher feerate transactions are always better unless you already o= verpaid for fees. Sure you can overpay and then add some spam by making suc= cessively higher feerate but smaller transactions, but in that case you'= ;ve basically paid for all that spam up front with your original fee. So is= it really spam? If you've covered the cost of it, then its not spam as= much as it is stupid behavior.

So I'm inclined = to agree with O'Beirne (and Lisa Neigut) that valid transactions with f= eerate bumps should never be excluded from relay as long as the amount of t= he feerate bump is more than the node's minimum transaction fee. Doing = that would also get rid of the spectre of transaction pinning.=C2=A0
<= div>
I'm curious if there's some other type of sce= nario where removing the absolute fee bump rule would cause nodes to relay = more transactions than they would relay in a full/congested mempool scenari= o. We shouldn't care about spam that only happens when the network = is quiet and can't bring network traffic above normal non-quiet loads b= ecause a case like that isn't a dos risk.

On Fri, Feb = 11, 2022 at 3:13 AM darosior via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.org> wrote:
Well because in the example i gave you this decreases the miner&= #39;s reward. The rule of increasing feerate you stated isn't always ec= onomically rationale.


Note how it can also be = extended, for instance if the miner only has 1.5vMB of txs and is not assur= ed to receive enough transactions to fill 2 blocks he might be interested i= n maximizing absolute fees, not feerate.


Sure,= we could make the argument that long term we need a large backlog of trans= actions anyways.. But that'd be unfortunately not in phase with today&#= 39;s reality.


-------- Original Message --------
On Fe= b 11, 2022, 00:51, James O'Beirne < james.obeirne@gmail.com> wrote:
> It's not that simple. As a miner, if i ha= ve less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 100000sats by a 100sats/vb transaction paying only 10000sats.

I don't understand why the "<1vMB in the mempool" ca= se is even worth consideration because the miner will just include the enti= re mempool in the next block regardless of feerate.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000029e4eb05d7d76bdc--