path: root/1a/cdbabfb0fd323bf638f96d86626ed18d5aec0f

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E8D2AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 13:39:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id C3BF560BDE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 13:39:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C3BF560BDE
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=OeodZZHh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.151
X-Spam-Level: 
X-Spam-Status: No, score=0.151 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
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 nKWPAq9oU3nm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 13:39:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 847CA60BB8
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [IPv6:2a00:1450:4864:20::52a])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 847CA60BB8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Dec 2022 13:39:11 +0000 (UTC)
Received: by mail-ed1-x52a.google.com with SMTP id r26so15758562edc.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 05 Dec 2022 05:39:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=0FTze2W7eGkUr0Z+/vsNNgpq3P0HHxGCupGE1soZ2M4=;
 b=OeodZZHhQHJusfCpsz3S73av98qCIcIGnZPtFHoM1yn2wCzKUcX1Pkj1MWo7fVb5ga
 xUKeSiqI/jGTHIGABeQbjqi4CEmHXCaflOj/h2Om7HJMVbmL9ZSPdhSDISCT4GculHM6
 7X62aG4cfSEp1LRroUyyAsLC0WTT54gdgiwlgX2Aw+mZiruv6Ivp1yrjELVlmwuc3n+v
 Q4g1POG5JNQm8X9q7RRM7j51xp2phZloBHtJtZuJjQFeubLGfvPlOfcallPZ1CjekwpV
 5Z7POZjYrxhwJsvYsfyt8+RGUK6BX+TGlE2iP7BRk59ya9wJUglqgkgEhuw1DWEY2Q6b
 8WEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=0FTze2W7eGkUr0Z+/vsNNgpq3P0HHxGCupGE1soZ2M4=;
 b=f+EWB+UsiQwvETWjV+XcsylS7JnsclISo6VPz9vwKUeUYkwz5zR8eYIs9Rdihiv3vx
 rR1UQiE07WOOv8ovpZG3tJaqyTTfPC4IUekw+PGzrUK+xZsDAg54xH9gMys2MHabI52M
 SsQLV0v+WOr7eHfdCxki3MFclkHnttj7OBOQ9tl/obmV53QMhFJNs4J1VSBGyHDWEt82
 Vn4ILMHbqcYO9NoefKB7+bgbpgI5wROnU3YUzM7wLIDVpmsS5pnYWBVpCoe9yyaZP78A
 +yTK8SxH2MWVWTFt/7V3FJB++6QbaLFvDVHq5RQFXyg6ApuB4eIIIVi/vizjSk3EHfGC
 nPAg==
X-Gm-Message-State: ANoB5pkTeoPevw8GaXR6+bfKTos68tLBAaA4aLzDWRR6ZMszgwjXr1zE
 XiO55pSNiu7t04SiPyzO0hyqBqfMbhtrOfhZ/0cksfNtXR0=
X-Google-Smtp-Source: AA0mqf6nnAOX4KYFKmduOuvv8lADDnnJOHBhNDRb4YM8sNQxpj4Wcgh/NPekT14fyStBwzG4WQSrMjhK4YPyRg7R5aI=
X-Received: by 2002:a05:6402:505:b0:46b:aa:856a with SMTP id
 m5-20020a056402050500b0046b00aa856amr35017207edv.171.1670247549439; Mon, 05
 Dec 2022 05:39:09 -0800 (PST)
MIME-Version: 1.0
References: <Y2I3w8O5X55sD/3C@petertodd.org> <Y2qc7Ubc5xtJhxGw@petertodd.org>
 <Y3MlSE7AWkBgiCyr@erisian.com.au> <Y3OljVGQbZ/Wj8T6@petertodd.org>
 <CAPapNH3NEBP2-GVZZ_75K-QU0psGdAHyjdAus-vfq-0jffTstg@mail.gmail.com>
In-Reply-To: <CAPapNH3NEBP2-GVZZ_75K-QU0psGdAHyjdAus-vfq-0jffTstg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 5 Dec 2022 08:38:58 -0500
Message-ID: <CAB3F3DtqpBWvDFn77pFaikCLZUDDevng5QUez9Y8XxDUOoRivw@mail.gmail.com>
To: El_Hoy <eloyesp@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000df197b05ef14cf58"
Cc: Daniel Lipshitz <daniel@gap600.com>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
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: Mon, 05 Dec 2022 13:39:14 -0000

--000000000000df197b05ef14cf58
Content-Type: text/plain; charset="UTF-8"

This will greatly centralize the network as well as not actually achieve
the intended goal which is literally impossible.

On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> >  - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> >  - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> >            is announced and propogates widely (1.2sat/vb)
>> >  - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> >            is announced and propogates widely (1.2sat/vb)
>> >  - 21:52 - ba967010 tx is announced and propogates widely, since
>> >            conflicting tx 746daab9 has been removed from default
>> >          mempools
>> >  - 21:53 - murch tweets about default mempool filling up
>> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> >            conflicting tx f503868 has already been removed from default
>> >          mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>>     2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> >  - 22:35 - block 763189 is mined
>> >  - 22:39 - block 763190 is mined
>> >  - 23:11 - block 763191 is mined
>> >  - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > That presumably means those pools (AntPool twice and "unknown") are
>> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>
>> To be clear, you think that AntPool and that other exchange is running
>> with a
>> larger than normal max mempool size limit? You mean those miners *did*
>> keep the
>> earlier 1.2sat/vb tx?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement.  While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000df197b05ef14cf58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">This will greatly centralize the network as well as not a=
ctually achieve the intended goal which is literally impossible.=C2=A0</div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Th=
e only option I see against the attack Peter Todd is doing to opt-in RBF an=
d 0Conf bitcoin usage is working on a bitcoin core implementation that stop=
s propagation of full-rbf replaced blocks. Running multiple of such nodes o=
n the network will add a risk to miners that enable full-rbf that would wor=
k as an incentive against that.</div><div><br></div><div>Obviously that wou=
ld require adding an option on bitcoin core (that is not technically but po=
litically difficult to implement as Petter Todd already have commit access =
to the main repository).</div><div><br></div><div>That said, a sufficiently=
 incentivized actor (like Daniel Lipshitz or Muun wallet developers) could =
work on a fork and run several nodes with such functionality. As far as I u=
nderstand the percolation model, with 10 to 20 nodes running such a rule wo=
uld create a significant risk for full-rbf miners.</div><div><br></div><div=
>Regards.<br></div><div><br></div><div><div dir=3D"ltr" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(56,118,29)"><span=
 style=3D"font-family:arial,helvetica,sans-serif">---=C2=A0 Eloy</span></sp=
an><br></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Nov 15, 2022 at 11:43 AM Peter Todd v=
ia bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.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">=
On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wro=
te:<br>
&gt; On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev w=
rote:<br>
&gt; &gt; FYI I&#39;ve gotten a few hundred dollars worth of donations to t=
his effort, and<br>
&gt; &gt; have raised the reward to about 0.02 BTC, or $400 USD at current =
prices.<br>
&gt; <br>
&gt; Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):=
<br>
<br>
I&#39;m turning it back on when (if) the mempool settles down. I&#39;ve got=
 more than<br>
enough donations to give another run at it (the majority was donated privat=
ely<br>
FWIW). There&#39;s a risk of the mempool filling up again of course; hard t=
o avoid<br>
that.<br>
<br>
Right now of course it&#39;s really easy to double spend with the obvious<b=
r>
low-fee/high-fee method as the min relay fee keeps shifting.<br>
<br>
&gt; <a href=3D"https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d=
2e72020b7d11fc2be29d934d69138c" rel=3D"noreferrer noreferrer" target=3D"_bl=
ank">https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d1=
1fc2be29d934d69138c</a><br>
&gt; <br>
&gt; The block it was claimed in seems to have been about an hour after the=
<br>
&gt; default mempool filled up:<br>
&gt; <br>
&gt; <a href=3D"https://twitter.com/murchandamus/status/1592274621977477120=
" rel=3D"noreferrer noreferrer" target=3D"_blank">https://twitter.com/murch=
andamus/status/1592274621977477120</a><br>
&gt; <br>
&gt; That block actually seems to have included two<br>
&gt; <a href=3D"http://alice.btc.calendar.opentimestamps.org" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">alice.btc.calendar.opentimestamps.org</a=
> txs, the other paying $7.88<br>
&gt; (309sat/vb):<br>
&gt; <br>
&gt; <a href=3D"https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc=
094894abdf59fe7aa020ccfead07cf" rel=3D"noreferrer noreferrer" target=3D"_bl=
ank">https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf5=
9fe7aa020ccfead07cf</a><br>
<br>
The second is because I turned down the full-rbf reward to more normal fee<=
br>
levels. There&#39;s also another full-rbf double-spend from the Bob calenda=
r, along<br>
the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008=
d2cd2<br>
<br>
I double-spent the txin of the high fee tx that got mined. But I mistakenly=
 had<br>
RBF enabled in that double-spend, so while it propagated initially, I belie=
ve<br>
it was replaced when something (someone?) rebroadcast the high-fee 397dcb t=
x.<br>
<br>
&gt; Timeline (utc) to me looks like:<br>
&gt; <br>
&gt;=C2=A0 - 13:12 - block 763148 is mined: last one that had a min fee &lt=
; 1.5sat/vb<br>
&gt;=C2=A0 - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040c=
d8ce6dc6e1<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is announced and propogates w=
idely (1.2sat/vb)<br>
&gt;=C2=A0 - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabc=
d7759e0944<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is announced and propogates w=
idely (1.2sat/vb)<br>
&gt;=C2=A0 - 21:52 - ba967010 tx is announced and propogates widely, since<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicting tx 746daab9 has b=
een removed from default<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mempools<br>
&gt;=C2=A0 - 21:53 - murch tweets about default mempool filling up<br>
&gt;=C2=A0 - 22:03 - 397dcbe4 tx is announced and propogates widely, since<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicting tx f503868 has al=
ready been removed from default<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mempools<br>
<br>
Is that 22:03 time for 397 from your node&#39;s logs? It was originally ann=
ounced<br>
hours earlier. From one of my full-rbf nodes:<br>
<br>
=C2=A0 =C2=A0 2022-11-14T14:08:37Z [mempool] replacing tx 764867062b67fea61=
810c3858d587da83a28290545e882935a32285028084317 with 397dcbe4e95ec40616e3df=
c4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 additional fees, -1 =
delta bytes<br>
<br>
&gt;=C2=A0 - 22:35 - block 763189 is mined<br>
&gt;=C2=A0 - 22:39 - block 763190 is mined<br>
&gt;=C2=A0 - 23:11 - block 763191 is mined<br>
&gt;=C2=A0 - 23:17 - block 763192 is mined including 397dcbe4<br>
&gt; <br>
&gt; miningpool.observer reports both 397dcbe4 and ba967010 as missing in t=
he<br>
&gt; first three blocks, and gives similar mempool ages for those txs to wh=
at<br>
&gt; my logs report:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0<a href=3D"https://miningpool.observer/template-and-block/=
0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://miningpool.observer/template=
-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7=
</a><br>
&gt;=C2=A0 =C2=A0<a href=3D"https://miningpool.observer/template-and-block/=
00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://miningpool.observer/template=
-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309=
</a><br>
&gt;=C2=A0 =C2=A0<a href=3D"https://miningpool.observer/template-and-block/=
00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://miningpool.observer/template=
-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1=
</a><br>
&gt; <br>
&gt; That presumably means those pools (AntPool twice and &quot;unknown&quo=
t;) are<br>
&gt; running with large mempools that didn&#39;t kept the earlier 1.2sat/vb=
 txs.<br>
<br>
To be clear, you think that AntPool and that other exchange is running with=
 a<br>
larger than normal max mempool size limit? You mean those miners *did* keep=
 the<br>
earlier 1.2sat/vb tx?<br>
<br>
&gt; The txs were mined by Foundry:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0<a href=3D"https://miningpool.observer/template-and-block/=
00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://miningpool.observer/template=
-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5=
</a><br>
&gt; <br>
&gt; This seems to be pretty good evidence that we currently don&#39;t have=
 any<br>
&gt; significant hashrate mining with fullrbf policies (&lt;0.5% if there w=
as a<br>
&gt; high fee replacement available prior to every block having been mined)=
,<br>
&gt; despite the bounty having been collected.<br>
<br>
Oh, we can put much lower bounds on that. I&#39;ve been running OTS calenda=
rs with<br>
full-rbf replacements for a few months without clear evidence of a full-rbf=
<br>
replacement.=C2=A0 While there was good reason to think some miners were mi=
ning<br>
full-rbf before a few years back, they probably didn&#39;t bother to reappl=
y their<br>
patches each upgrade. `mempoolfullrbf=3D1` is much simpler to use.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://pet=
ertodd.org" rel=3D"noreferrer noreferrer" target=3D"_blank">petertodd.org</=
a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000df197b05ef14cf58--