Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E8D2AC002D for ; 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 ; 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 ; 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 ; Mon, 5 Dec 2022 13:39:11 +0000 (UTC) Received: by mail-ed1-x52a.google.com with SMTP id r26so15758562edc.10 for ; 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: In-Reply-To: From: Greg Sanders Date: Mon, 5 Dec 2022 08:38:58 -0500 Message-ID: To: El_Hoy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000df197b05ef14cf58" Cc: Daniel Lipshitz 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
This will greatly centralize the network as well as not a= ctually achieve the intended goal which is literally impossible.=C2=A0
On Mo= n, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
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.

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).

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.

Regards.

---=C2=A0 Eloy


On Tue, Nov 15, 2022 at 11:43 AM Peter Todd v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
= On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wro= te:
> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev w= rote:
> > FYI I've gotten a few hundred dollars worth of donations to t= his 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 privat= ely
FWIW). There's a risk of the mempool filling up again of course; hard t= o 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/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d1= 1fc2be29d934d69138c
>
> The block it was claimed in seems to have been about an hour after the=
> default mempool filled up:
>
> https://twitter.com/murch= andamus/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/ba9670109a6551458d5e1e23600c7bf2dc094894abdf5= 9fe7aa020ccfead07cf

The second is because I turned down the full-rbf reward to more normal fee<= br> levels. There's also another full-rbf double-spend from the Bob calenda= r, along
the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008= d2cd2

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 belie= ve
it was replaced when something (someone?) rebroadcast the high-fee 397dcb t= x.

> Timeline (utc) to me looks like:
>
>=C2=A0 - 13:12 - block 763148 is mined: last one that had a min fee <= ; 1.5sat/vb
>=C2=A0 - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040c= d8ce6dc6e1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is announced and propogates w= idely (1.2sat/vb)
>=C2=A0 - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabc= d7759e0944
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is announced and propogates w= idely (1.2sat/vb)
>=C2=A0 - 21:52 - ba967010 tx is announced and propogates widely, since<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicting tx 746daab9 has b= een removed from default
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mempools
>=C2=A0 - 21:53 - murch tweets about default mempool filling up
>=C2=A0 - 22:03 - 397dcbe4 tx is announced and propogates widely, since<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conflicting tx f503868 has al= ready been removed from default
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mempools

Is that 22:03 time for 397 from your node's logs? It was originally ann= ounced
hours earlier. From one of my full-rbf nodes:

=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

>=C2=A0 - 22:35 - block 763189 is mined
>=C2=A0 - 22:39 - block 763190 is mined
>=C2=A0 - 23:11 - block 763191 is mined
>=C2=A0 - 23:17 - block 763192 is mined including 397dcbe4
>
> miningpool.observer reports both 397dcbe4 and ba967010 as missing in t= he
> first three blocks, and gives similar mempool ages for those txs to wh= at
> my logs report:
>
>=C2=A0 =C2=A0https://miningpool.observer/template= -and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7=
>=C2=A0 =C2=A0https://miningpool.observer/template= -and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309=
>=C2=A0 =C2=A0https://miningpool.observer/template= -and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1=
>
> That presumably means those pools (AntPool twice and "unknown&quo= t;) 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:
>
>=C2=A0 =C2=A0https://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 w= as 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 calenda= rs with
full-rbf replacements for a few months without clear evidence of a full-rbf=
replacement.=C2=A0 While there was good reason to think some miners were mi= ning
full-rbf before a few years back, they probably didn't bother to reappl= y their
patches each upgrade. `mempoolfullrbf=3D1` is much simpler to use.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000df197b05ef14cf58--