path: root/c2/06ee0103460a5b4e4f5244ba3e78c598e3aa14

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 963F1C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 12 Feb 2022 19:45:01 +0000 (UTC)
Received: by mail-ej1-x633.google.com with SMTP id p14so5195665ejf.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <9Vw6LCkr2d2uOBanXeIuGxA1fUGGOeV1OHlgBifbmij1Afs0ISjfKK-vmcnRZfBG4GwJhIVLMisjvS_zohS-cW0FkzZaCKa6Mn7VWolznJs=@protonmail.com>
 <CAPfvXfJ6dE2JycEdsK-gimyFwf64RfOen0maRq4LLg5R8RFEbQ@mail.gmail.com>
 <4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com>
In-Reply-To: <4D4Un0WaQ8pA19HVFy_xtBTQhItDVIPWPLwuS7Hv8RBxvHpV05dyWPeoveTTefc3cG6S7IOhuxnH5n2HnFbTpF9UszuuAygnOEVz9g6JOKA=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 12 Feb 2022 13:44:41 -0600
Message-ID: <CAGpPWDYv1LrH5MfRGr1fzhpPtjgg8JKLezbw96nKppGB4W5XRg@mail.gmail.com>
To: darosior <darosior@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr">With respect to the disagreement/misunderstanding about th=
e=C2=A0

&quot;&lt;1vMB in the mempool&quot; case, I think it&#39;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<div><br></d=
iv><div>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&#39;t want to (nor can we) force miners to do tran=
saction inclusion the same as=C2=A0each other, we certainly can&#39;t reali=
stically produce an environment where relay rules exactly match miner inclu=
sion rules.=C2=A0<div><br></div><div>So I think the goal should <b>not </b>=
be strictly minimal relay, because it&#39;s not practical and basically not=
 even possible. Instead the=C2=A0goal should be some close-enough approach.=
=C2=A0</div><div><br></div><div>This relates to the=C2=A0



&quot;&lt;1vMB in the mempool&quot; 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:</div><div><br></div><div>* The average case</di=
v><div>* The adversarial worst case</div><div><br></div><div>In the average=
 case, no one is going to be broadcasting any transactions like that becaus=
e they don&#39;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&#39=
;s the worst someone could do?=C2=A0</div><div><br></div><div>Well if there=
&#39;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&#39;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&#39;s not much of an actual &quot;attack&quot; happening he=
re. Just an insignificant amount of avoidable extra spent electricity and u=
nnecessary internet traffic. Nothing that&#39;s going to make running a ful=
l node any harder.=C2=A0</div><div><br></div><div>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&#39=
;ve basically paid for all that spam up front with your original fee. So is=
 it really spam? If you&#39;ve covered the cost of it, then its not spam as=
 much as it is stupid behavior.<br><div><br></div><div>So I&#39;m inclined =
to agree with O&#39;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&#39;s minimum transaction fee. Doing =
that would also get rid of the spectre of transaction pinning.=C2=A0</div><=
div><br></div><div><b>I&#39;m curious if there&#39;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</b>. We shouldn&#39;t care about spam that only happens when the network =
is quiet and can&#39;t bring network traffic above normal non-quiet loads b=
ecause a case like that isn&#39;t a dos risk.</div></div></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb =
11, 2022 at 3:13 AM darosior via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Well because in the example i gave you this decreases the miner&=
#39;s reward. The rule of increasing feerate you stated isn&#39;t always ec=
onomically rationale.<div><br></div><div><br></div>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.<div><br></div><div><br></div>Sure,=
 we could make the argument that long term we need a large backlog of trans=
actions anyways.. But that&#39;d be unfortunately not in phase with today&#=
39;s reality.<div><br></div><br>-------- Original Message --------<br>On Fe=
b 11, 2022, 00:51, James O&#39;Beirne &lt; <a href=3D"mailto:james.obeirne@=
gmail.com" target=3D"_blank">james.obeirne@gmail.com</a>&gt; wrote:<blockqu=
ote><br><div dir=3D"ltr">&gt; It&#39;s not that simple. As a miner, if i ha=
ve less than 1vMB of
transactions in my mempool. I don&#39;t want a 10sats/vb transaction paying
100000sats by a 100sats/vb transaction paying only 10000sats.<div><br></div=
><div>I don&#39;t understand why the &quot;&lt;1vMB in the mempool&quot; ca=
se is even worth consideration because the miner will just include the enti=
re mempool in the next block regardless of feerate.<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></blockquote></div>

--00000000000029e4eb05d7d76bdc--