path: root/08/7eca25218abe151894be52e9063635c7134a80

Delivery-date: Sun, 21 Jul 2024 11:04:53 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBO436W2AMGQEMA7H6VY@googlegroups.com>)
	id 1sVavS-00029P-LU
	for bitcoindev@gnusha.org; Sun, 21 Jul 2024 11:04:53 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e0872023b7dsf3407755276.2
        for <bitcoindev@gnusha.org>; Sun, 21 Jul 2024 11:04:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721585084; x=1722189884; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=;
        b=nqwaA8S8Xj6/guypTlUudEUFzy4vkRVAHCbi6xTXZohgcq/HpCLERlm9/L8Flq07fB
         e0crtjfD9QdCQFqMjsBm6IefcW1mYWE8J76qboZtHTT3z9aFSDlNtYlxL8HXpGuqq34w
         Y+zQuSDRv2Oi8jDsWBSZk/rJICXozcRs5y0+3/MpAL5CYWjT+qlUtZAL15XJsk8E0t/W
         PvDIYX9fwJ0Ap/4h5IYFrJL1j0wwGdoT05LzEWXipB8vq0BIs85dYcRFRWSScG8ho25Z
         4RPWQ1UhmI6Pi8zQGMTVwmhhoaO4JC7rdY0itsOgLbQ6J4d+EPHJ3IPDSoeItfNEgVHb
         Rl8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1721585084; x=1722189884; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=;
        b=FlFo3WysxVeOY64r4AH5eJa6Ygin95dh1096ghRZBAvZLs9zewpRxCP2RJxQR9s+k/
         0eEvmYr2CJhjXwiTIfAjN+BM4Cyjjfv9ce2zURLEhJDZSBa0bhx0fqsZAkX8KT27h816
         PjrYosdUZzV4+Rqyme9Z2HB5r6jhVvOzw5SnJjnOKXqEWXDfkrCMoPOGj2iZlfuTXm1S
         Dim46FaEqQKyq+H0K/GZF0mTlCwxDLJNt7X6qX7EB5uUfH6h9cMrTi8FMCe07AGEuDlP
         zDe9bfR3hXN4XE4UW3nF+nWbmNq+Wevwh5xPSKTMrWYhBDgq7L97jWBaH8/ELf7dMdDe
         9Tow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721585084; x=1722189884;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9yLoje/KkDuOabtdEu0t8wq0RtuxZ4Vud7TjOVpq44g=;
        b=eiL+/4JqqgBKT84tCJgAngIFgJL/K/Hz/EXOLSwIphT5bfXW5VTR6qLYqsi3h2jyul
         mi2uTl359+27/eopjzQMQ+t+MdNHb2zjh2ElypF+scwmL85CC95yuN9yDJ9h2OxdJFWs
         YnH7HXj0PTZ+/QmrxnQ0OzXqrQwzaRFcndLUCUQjSWEHJED5kiwRjnTaM0OSLLfDQevW
         CRq9+IY48TElbPzpQhwW27FHMHi6NoEFpO79Ih7bitw7hqwmw2Swbu3xkc3EarRymUrK
         zJnwA0vwciTpLvMe2a1tng5gts4jzquOfSjO7sT4oZsA1kk467myQobeGqOiFFkK73bR
         tTgA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXxhBYs+EAAxYhfxiNrefLjqB/mgEpXu1wXuF6CbawYOnS9skkLcjNmMM4/6Loi40sBGc3GPwWOJAkb1b6S2Fcp4qGgfIY=
X-Gm-Message-State: AOJu0Ywg0ryEMn7kchhaKM7Awf44kbphCdxDYgzvEkPuezR9UMM85k77
	e7grp7g0sTLFm/HyuRSmbYZvINBNyece4ydLtSFpsy+wdnILkZZQ
X-Google-Smtp-Source: AGHT+IES56h2ywfhI6BU5jqhFUk/2LASP7t5CBEnoOMhVYwt/XFxP5yhuJ+RkR5tehOiuO20VsjRGQ==
X-Received: by 2002:a05:6902:200b:b0:e08:726a:5a87 with SMTP id 3f1490d57ef6-e087b345739mr4375806276.4.1721585084436;
        Sun, 21 Jul 2024 11:04:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:870d:0:b0:e03:3e31:f7ca with SMTP id 3f1490d57ef6-e05fdd4eb6bls5303007276.2.-pod-prod-03-us;
 Sun, 21 Jul 2024 11:04:43 -0700 (PDT)
X-Received: by 2002:a05:690c:398:b0:61b:e103:804d with SMTP id 00721157ae682-66a63b6c182mr630617b3.0.1721585083226;
        Sun, 21 Jul 2024 11:04:43 -0700 (PDT)
Received: by 2002:a05:690c:2e0a:b0:64a:6fb4:b878 with SMTP id 00721157ae682-669195b3414ms7b3;
        Sat, 20 Jul 2024 19:10:55 -0700 (PDT)
X-Received: by 2002:a05:690c:10d:b0:627:a671:8805 with SMTP id 00721157ae682-66a63f48814mr3491257b3.3.1721527853855;
        Sat, 20 Jul 2024 19:10:53 -0700 (PDT)
Date: Sat, 20 Jul 2024 19:10:53 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
In-Reply-To: <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_507422_1310615009.1721527853625"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: 1.5 (+)

------=_Part_507422_1310615009.1721527853625
Content-Type: multipart/alternative; 
	boundary="----=_Part_507423_1098517225.1721527853625"

------=_Part_507423_1098517225.1721527853625
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dave,

Thanks for your thoughtful answer (even if its wasn't addressed to me=20
primarly).

> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.

From my experience code reviewing the wallet / mempool re-broadcast of few
years ago, free tx-relay / bandwidth waste attacks were far to be=20
understood=20
or plainly weighted by some contributors of a newer generations, including=
=20
by
the own champion of the proposal. The proposal was finally abandonned when =
a
more senior dev came up with quantitative analysis of code changes [0].

[0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105

> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.

I think what is more interesting and noteworhty in the whole line of=20
reaosning
of Peter with the present disclosure is how much the adversial effect is=20
favor
by the supermajority of miners running `mempoolfullrbf` [1].

[1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316

That Peter's sample calls for empirical measures of their own by other=20
contributors=20
that can only make the whole review process and consensus-building towards=
=20
a change
or the status quo better. Being able to empirically measure how bitcoin=20
full-node
software is practically used by end-users, be it miners, second-layers=20
nodes, simple
coins wallet users, exchanges, and making that a protocol development=20
standard I believe
that how we progress as an ecosystem.

> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.

The strong statement we have from the bitcoin core about attacks and=20
vulnerabilities
mitigation, which probably represents the viewpoint of many generation of
contributors is the following as old than few weeks ago:

"The project has historically done a poor job at publicly disclosing=20
security-critical bugs,
whether externally reported or found by contributors. This has led to a=20
situation where a lot
of users perceive Bitcoin Core as never having bugs. This perception is=20
dangerous and,=20
unfortunately, not accurate."

[2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Under those conditions, where it took 9 years for the bitcoin core project=
=20
to disclosre
some vulnerabilitires, personally I'm more likely to understand that the=20
bitcoin core project
is under-staffed is competent experts to keep public disclosure in=20
reasonable timeframe (-- at
least equivalent to the kernel world), and as corollorary to fully evaluate=
=20
technical proposal
with all its strength and weaknesses.

Saying an "already overdiscussed issues that gets nobody closer to=20
fundamental solutions" is
insulting for Peter, honestly.

> Many protocol developers have attempted to address the problem over the=
=20
years, most recently just
> a few months ago with an updated proposal for using weak blocks as a=20
first step to address
> "diverging mempool policies".[1]

With all my respect for the developers involved in the design of this=20
proposal who are skilled bitcoin
engineers in themsleves, I think betting on the "weak blocks" idea is a=20
dead end in itself as in relying
on the slow convergence idea, that it's at the heart of the ghost, block=20
dag and other ideas we've seen
10 years ago to make mining income "more fair" among geographically=20
distributed mining pools.

I conjecture, it's a dead end as you will more or less have to re-build a=
=20
secondary consensus algorithm
in the block-relay stack or in the mining stack, which is going to run=20
intou its own mempool convergence
issues again, in a recursive fashion.

I believe such proposal is more an instance of the ill-managed conflict of=
=20
interest blockstream-style
syndrom that bitcoin protocol devs, who ever they care can be affected=20
with. In the present instance:

"My employer has gained a commercial interest in mining business recently=
=20
so now let's advocate a very
complex bitcoin p2p protocol changes, rather than humbly realize that=20
mining economic units are more akin
to a traditional energy company which not really in the less than 2-decades=
=20
corporate DNA of said employer,
and why actually the economic units results of our mining division are=20
floppy and now we engage in bitcoin
core changes at our advantage" (in my own reasonable view -- though I can=
=20
only invite the "weak block" employer
company corporate board to comment here if they diverge on my analysis).

From a more pure technical viewpoint, I think bitcoin core compact blocks=
=20
block-relay handling code, after
7 years of having been merged in bitcoin core has still `TODO` left in the=
=20
codebase, and it could be an area
worhty of more testing / cleaning refactoring, I'm just saying by the way.

> You've previously argued against designing contract protocols to depend=
=20
> CPFP-style fee bumping for their offchain transactions, however that is=
=20
> what is widely used by LN today and it appears to be what LN and other=20
> offchain protocol developers want to use in the future. If we accept=20
> that, at least for the purposes of argument, what can we do to improve=20
> CPFP fee bumping for LN?=20

As an offchain protocol developers which has been involved in the majority=
=20
of technical conversations,
implementations and deployment of the "anchor output" upgrade, I believe on=
=20
the long-term CPFP-style fee-bumping
of contract protocol, including lighting, is not the most robust technical=
=20
solutions. I think anyone can check
in the bitcoin optech anchor output glossary the numerous vulnerabilities=
=20
that have plagued this fee-bumping=20
solutions over the past years.

Pursuing on that trend will more only probably lead to a current state of=
=20
what we have with DNS / BGP at the
internet-stack level, which are still constantly the sources of new=20
security vulnerabilitiies and single-point
of-failure securiyt solutions like X509 certificates management (do we wish=
=20
bitcoin to be plagued by crowdstyle
technical incident 15 years from now ? I'm not so sure).

> All we really need at this point is to enable package relay so that=20
> parent transactions are no longer subject to a dynamic mempool minimum=20
> when they're bundled with a high-feerate child. Preliminary support for=
=20
> that should be released in the next major version of Bitcoin Core, with=
=20
> improved support being worked on for later releases.=20
>=20
> Package relay is the only thing we need at this point because the=20
> existing LN protocol makes use of CPFP carve-out, which minimizes=20
> transaction pinning issues.=20

I don't disagree on package relay deployment at this stage, with the some=
=20
degree of technical skeptiscism
that shall accomaphny all p2p proposals. Let's remember things that have=20
been rollback or slowly rollout like
bip37 or `MEMPOOL` p2p message.

> However, another substantial Bitcoin Core improvement, cluster mempool,=
=20
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP=20
> carve-out that is easy to reason about, easy to use, more general in=20
> nature (good news for newer contract protocols), and which can possibly=
=20
> be automatically applied to existing LN onchain transactions, allowing=20
> cluster mempool to be deployed ASAP without requiring any significant=20
> changes to anyone else's software.=20

If you or anoyone think TRUC as an alternative to the CPFP as a transsction=
=20
pinning mitigation as argued
in its merged BIP is easy to reason on, thanks to communicate your=20
lightning node pubkey, with TRUC patch
applied and a GPG-signed message authorizing me to demonstrate the security=
=20
properties of this solutions have
not been submitted to a fully contradictory evaluation.

I pointed out few years ago that relying on mempool-policy changes as a=20
fully hardening solution was very
likely limited to mitigate econommical-based pinnings (i.e bip125 absolute=
=20
fee rule), and this was before
the discovery of new transaction-relay jamming vector (a terminology=20
catched by your himself in some
private conversation if my memory is correct) like replacement cycling=20
attacks [4].

[4]=20
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019084.ht=
ml=20
"high-half" in this post
corresponds to what roughly is bip331 today.

> I don't think we need to be overly concerned about large numbers of LN=20
users suddenly performing a malicious
> action that does not benefit them and does not put the network at risk.

Have a look on base-layer based exploitation description that could provoke=
=20
a large number of LN users, without
their own involvement, that could put the base-network at risk [5].

[5]=20
https://github.com/jamesob/mempool.work?tab=3Dreadme-ov-file#failure-one-me=
mpool-to-rule-them-all

> The alternative to TRUC that you've proposed is replace-by-feerate=20
> (RBFr). This is also compatible with existing LN transactions and it's=20
> conceptually super simple (I assume the code is too), which is=20
> wonderful. However, it's downsides are:=20

About replace-by-feerate, I think it's a solution that have downside on its=
=20
own, especially for
second-layers like lightning. I never took time to write a canonical post=
=20
as infosec ethics would ask
me to notice lightning maininters to do first, even if the vulnerability=20
idea has been vaguely sketched
out to few years ago.

On all your replace-by-feerate analysis, I think it deserves a thread on=20
its own, as somehow the issue
can have interactions with degree of fulfillness of miner block templates,=
=20
a conversation we had when V3
was proposed as solution [6].

[6]=20
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817=
.html=20
and following answers

> but the deployment of cluster mempool requires removal of CPFP carve-out,=
=20
and removal of CPFP carve-out requires
> either the upgrade of thousands of LN nodes and channels or a drop-in=20
solution (ideally one that can be analyzed=20
> independently from cluster mempool, like TRUC)

And as I observed on one of the V3 PR threads and corresponding=20
conversations, the CPFP carve-out do not provide
security to lightning implementation as (a) old revoked commitment=20
transactions can be used to fail the CPFP bump,
V3 or not V3 and (b) there is no base-layer p2p protocol discovery of txids=
=20
[6]. And I won't observe that when I looked
on lightning implementations code, only Eclair have minimal correct=20
implementation of remote valid commitment transactions
broadcast, not the other one as it's not even in the bolt spec.

[6] https://github.com/bitcoin/bitcoin/pull/28948

So unless someone argued to the contrary, saying TRUC was needed to then=20
deploy cluster mempool is an intellectual
fallacy, of which the origin could likely arises from the back macket of PR=
=20
reviews trading happening in the bitcoin core
project for people to advance their own pet projects. At the very least,=20
from my own code review of the folks bitcoin
core PR related to this line of deployment you're exposing, I'm not sure=20
they're understanding so well cross-layers issues [7].

[7] https://github.com/bitcoin/bitcoin/pull/29427

I think you're rather making the points that the current group of most=20
active bitcoin core contributors, are indeed
skilled bitcoin engineers, vetted with project-management know-how and=20
informed about bitcoin technical history and know
how to stay polite and civil (most of the time) to create a fruitful=20
technical conversation atmosphere. They're not necessarily
the most astute and adversarial minds to spot on the flight the weakness of=
=20
new technical proposals, neither with the character
to say so _at the cost_ of sometimes being rude and negative in the=20
communication tone. And this in line with my point above
recalling that the bitcoin core group of people themselves estimate=20
themsleves they don't do a good job in term of security
vulnerabilties handling.

> There have already been multiple public discussions about how improved=20
> RBF policies can be implemented once cluster mempool is available, many=
=20
> of which bring us closer to something like RBFr in a way that's easier=20
> to prove won't enable free relay, and perusing that seems to me like a=20
> productive outlet if you are interested.=20

I already reviewed some parts of cluster mempool. Fundamentally, economical=
=20
mempool pinnings for second-layers (bip125 absolute
fee) with pre-signed time-sensitive transactions arises from a world where=
=20
there is (a) an asynchronicity of mempools and (b) one
cannot guess feerates at block + 1 (-- let's say in a deterministic fashion=
=20
as understood by traditional cryptographic litterature
when doing cryptanalysis). Better RBF policies won't solve that, including=
=20
RBFr.

> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.

On my personal perspective, and after careful considerations of all the=20
technical points you've raised. I still think TRUC
has a lot of problems. RBRFr too has technical problems. About TRUC I think=
=20
it's an acceptable temporary solution to minimize
the pinning surface of lightning implementations, pending for the design of=
=20
a better solution (more likely at the consensus-level,
here consistently as I pointed out 3 years ago). Though we shall be honest=
=20
with ourselves and not engage in overdue security theater
about TRUC properties.

To finish, I'll re-assert what is my appreciation. Currently, I don't think=
=20
the bitcoin core folks handling the security list has
necessarily the proven level of competency to fully evaluate the issues=20
reported by Peter, however I don't believe in the present
case they have done anything wrong infosec ethically-wise.

Best,
Antoine
ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e7a3d65b256caa7

Le samedi 20 juillet 2024 =C3=A0 07:45:24 UTC+1, David A. Harding a =C3=A9c=
rit :

> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
>
> They do. Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions. New proposals
> are evaluated for their potential to create new permanent free relay
> vectors. The discovery of free relay is almost always reason enough to
> reject a proposal.
>
> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).
>
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
>
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
>
> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.
>
> > I believe the authors of that BIP are fully aware of the fact that
> > "free" relay is an unavoidable problem, making their rational for
> > TRUC/V3 bogus
>
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want). Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]
>
> A currently unsolved problem is not necessarily an unavoidable problem
> and it seems reasonable to me for devs to be skeptical of proposals like
> RBFr that add to the list of things that enable free relay.
>
> > I believe the authors of [BIP431...] don't want to admit that they've
> > wasted a large amount of engineering time on a bad proposal.
>
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future. If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?
>
> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child. Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
>
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
>
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.
>
> As you've shown[2], the main downside of TRUC transactions (if we're
> going to depend on CPFP-style fee bumping anyway) is that users of TRUC
> transactions who have a malicious counterparty might need to pay a
> slightly higher onchain feerate than they would need to pay under the
> same situation with CPFP carve-out. However, the increase is small
> enough that most honest parties should be able to afford it, so there's
> no incentive for a counterparty to do it. I don't think we need to be
> overly concerned about large numbers of LN users suddenly performing a
> malicious action that does not benefit them and does not put the network
> at risk.
>
> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr). This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful. However, it's downsides are:
>
> 1. It fundamentally enables a significant amount of free relay. I'll
> sketch a super basic attack at the end of this email that costs 0.55
> BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
> relay nodes. I'm sure more efficient attacks are possible.
>
> An attacker who is able to consume an excessive amount of relay node
> bandwidth at relatively low cost may be able to create both
> short-term and long-term problems for all Bitcoin users. If the
> created problems result in a rapid increase in user feerates, then
> free relay attacks become cheaper due to low feerate transactions
> being automatically evicted from the bottom of the mempool.
>
> 2. It may allow empting the mempool at relatively low cost. An attacker
> sending just 750 transactions at the top mempool feerate can
> guarantee eviction of every honest user's transactions. The attacker
> can then replace 300 MB of transactions with a single 43,179 vbyte
> transaction. Even if the replacement transaction pays 100
> sats/vbyte, when you compare that to the 1,000,000 vbytes of
> next-block transactions each miner lost, the miner is only earning an
> effective feerate of 4.3 sats/vbyte.
>
> Further, it's easy to imagine situations where evicting
> time-sensitive transactions from mempools might allow theft of funds
> in excess of a few thousand dollars (my immediate thoughts go to
> situations involving watchtowers).
>
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
>
> To me, TRUC seems like an excellent approach. It's something that can
> be evaluated independently of cluster mempool but which can help allow
> that deployment to proceed (in addition to the other previously
> described benefits that TRUC brings).
>
> There have already been multiple public discussions about how improved
> RBF policies can be implemented once cluster mempool is available, many
> of which bring us closer to something like RBFr in a way that's easier
> to prove won't enable free relay, and perusing that seems to me like a
> productive outlet if you are interested.
>
> > this is quite an odd case of Core politics
>
> I began writing this reply to force me to examine your claims for
> myself. You have a long history of noticing things other people missed.
> I was worried that some compelling point of yours was being ignored as
> the result of past controversies.
>
> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.
>
> Thanks,
>
> -Dave
>
> [1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805
> [2]=20
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
211.html
> [3]=20
>
> https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by=
-feerate-to-escape-pinning
>
> ---
> A simple free relay attack using RBFr
>
> ## Constants
>
> 100,000 vbytes =3D=3D ~400,000 bytes
> A 1-input, 1-output P2TR scriptpath spend with the maximum amount
> of witness data allowed by Bitcoin Core defaults
>
> 111 vbytes =3D=3D 162 bytes
> A 1-input, 1-output P2TR keypath spend
>
> ## Attack
>
> - Attacker obtains 500,000 UTXOs
>
> - For each UTXO
>
> - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
> byte) transacton.
>
> - Waits for it to propagate.
>
> - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
> that is 111 vbytes (162 bytes).
>
> ## Analysis
>
> - At 162 bytes each, 500,000 transactions is 81 MB. I think that will
> fit in a default-sized mempool.
>
> - The total amount of transaction data relayed is 500_000 * (400_000 +
> 162), or about 200 GB.
>
> - The typical daily bandwidth requirement of a blocks-only node is
> roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
> node is about the same due to compact blocks, but realistically, it's
> a small multiple of that. Call it 2 GB per day.
>
> - This implies the attack push each RBFr relay node to use 100x a
> non-RBFr relay node.
>
> - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
> my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
> or 0.55 BTC (about $37,000 USD).
>
> - This analysis ignores the cost of obtaining the UTXOs and possibly
> later consolidating them, but it also ignores some easy optimizations
> such as batching the replacements.
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com.

------=_Part_507423_1098517225.1721527853625
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br />Hi Dave,<br /><br />Thanks for your thoughtful answer (even if its wa=
sn't addressed to me primarly).<br /><br />&gt; I cannot imagine what would=
 make you think that protocol developers are<br />&gt; not concerned about =
attacks that could drive large numbers of relay<br />&gt; nodes off the net=
work for a cost easily affordable to any well-funded<br />&gt; adversary.<b=
r /><br />From my experience code reviewing the wallet / mempool re-broadca=
st of few<br />years ago, free tx-relay / bandwidth waste attacks were far =
to be understood <br />or plainly weighted by some contributors of a newer =
generations, including by<br />the own champion of the proposal. The propos=
al was finally abandonned when a<br />more senior dev came up with quantita=
tive analysis of code changes [0].<br /><br />[0] https://github.com/bitcoi=
n/bitcoin/pull/21061#issuecomment-851563105<br /><br />&gt; In this case, y=
ou've found a specific instance (full-RBF vs signaled<br />&gt; RBF) of a w=
ell-known general problem (optional policies leading to<br />&gt; mempool i=
nconsistencies, allowing free relay) and appear to be arguing<br />&gt; tha=
t devs don't care about free relay because they refused to reverse a<br />&=
gt; previous decision (to not change the RBF configuration default) that ha=
s<br />&gt; been hotly debated multiple times.<br /><br />I think what is m=
ore interesting and noteworhty in the whole line of reaosning<br />of Peter=
 with the present disclosure is how much the adversial effect is favor<br /=
>by the supermajority of miners running `mempoolfullrbf` [1].<br /><br />[1=
] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316<br /><br /=
>That Peter's sample calls for empirical measures of their own by other con=
tributors <br />that can only make the whole review process and consensus-b=
uilding towards a change<br />or the status quo better. Being able to empir=
ically measure how bitcoin full-node<br />software is practically used by e=
nd-users, be it miners, second-layers nodes, simple<br />coins wallet users=
, exchanges, and making that a protocol development standard I believe<br /=
>that how we progress as an ecosystem.<br /><br />&gt; An alternative inter=
pretation is that they (1) do care about free relay,<br />&gt; (2) recogniz=
e that solving free relay is a hard problem that requires<br />&gt; researc=
h and development, and (3) refuse to be forced into restarting<br />&gt; de=
bate on an already overdiscussed issue that gets nobody closer to<br />&gt;=
 fundamental solutions.<br /><br />The strong statement we have from the bi=
tcoin core about attacks and vulnerabilities<br />mitigation, which probabl=
y represents the viewpoint of many generation of<br />contributors is the f=
ollowing as old than few weeks ago:<br /><br />"The project has historicall=
y done a poor job at publicly disclosing security-critical bugs,<br />wheth=
er externally reported or found by contributors. This has led to a situatio=
n where a lot<br />of users perceive Bitcoin Core as never having bugs. Thi=
s perception is dangerous and, <br />unfortunately, not accurate."<br /><br=
 />[2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w<br /><br />Unde=
r those conditions, where it took 9 years for the bitcoin core project to d=
isclosre<br />some vulnerabilitires, personally I'm more likely to understa=
nd that the bitcoin core project<br />is under-staffed is competent experts=
 to keep public disclosure in reasonable timeframe (-- at<br />least equiva=
lent to the kernel world), and as corollorary to fully evaluate technical p=
roposal<br />with all its strength and weaknesses.<br /><br />Saying an "al=
ready overdiscussed issues that gets nobody closer to fundamental solutions=
" is<br />insulting for Peter, honestly.<br /><br />&gt; Many protocol deve=
lopers have attempted to address the problem over the years, most recently =
just<br />&gt; a few months ago with an updated proposal for using weak blo=
cks as a first step to address<br />&gt; "diverging mempool policies".[1]<b=
r /><br />With all my respect for the developers involved in the design of =
this proposal who are skilled bitcoin<br />engineers in themsleves, I think=
 betting on the "weak blocks" idea is a dead end in itself as in relying<br=
 />on the slow convergence idea, that it's at the heart of the ghost, block=
 dag and other ideas we've seen<br />10 years ago to make mining income "mo=
re fair" among geographically distributed mining pools.<br /><br />I conjec=
ture, it's a dead end as you will more or less have to re-build a secondary=
 consensus algorithm<br />in the block-relay stack or in the mining stack, =
which is going to run intou its own mempool convergence<br />issues again, =
in a recursive fashion.<br /><br />I believe such proposal is more an insta=
nce of the ill-managed conflict of interest blockstream-style<br />syndrom =
that bitcoin protocol devs, who ever they care can be affected with. In the=
 present instance:<br /><br />"My employer has gained a commercial interest=
 in mining business recently so now let's advocate a very<br />complex bitc=
oin p2p protocol changes, rather than humbly realize that mining economic u=
nits are more akin<br />to a traditional energy company which not really in=
 the less than 2-decades corporate DNA of said employer,<br />and why actua=
lly the economic units results of our mining division are floppy and now we=
 engage in bitcoin<br />core changes at our advantage" (in my own reasonabl=
e view -- though I can only invite the "weak block" employer<br />company c=
orporate board to comment here if they diverge on my analysis).<br /><br />=
From a more pure technical viewpoint, I think bitcoin core compact blocks b=
lock-relay handling code, after<br />7 years of having been merged in bitco=
in core has still `TODO` left in the codebase, and it could be an area<br /=
>worhty of more testing / cleaning refactoring, I'm just saying by the way.=
<br /><br />&gt; You've previously argued against designing contract protoc=
ols to depend <br />&gt; CPFP-style fee bumping for their offchain transact=
ions, however that is <br />&gt; what is widely used by LN today and it app=
ears to be what LN and other <br />&gt; offchain protocol developers want t=
o use in the future. If we accept <br />&gt; that, at least for the purpose=
s of argument, what can we do to improve <br />&gt; CPFP fee bumping for LN=
? <br /><br />As an offchain protocol developers which has been involved in=
 the majority of technical conversations,<br />implementations and deployme=
nt of the "anchor output" upgrade, I believe on the long-term CPFP-style fe=
e-bumping<br />of contract protocol, including lighting, is not the most ro=
bust technical solutions. I think anyone can check<br />in the bitcoin opte=
ch anchor output glossary the numerous vulnerabilities that have plagued th=
is fee-bumping <br />solutions over the past years.<br /><br />Pursuing on =
that trend will more only probably lead to a current state of what we have =
with DNS / BGP at the<br />internet-stack level, which are still constantly=
 the sources of new security vulnerabilitiies and single-point<br />of-fail=
ure securiyt solutions like X509 certificates management (do we wish bitcoi=
n to be plagued by crowdstyle<br />technical incident 15 years from now ? I=
'm not so sure).<br /><br />&gt; All we really need at this point is to ena=
ble package relay so that <br />&gt; parent transactions are no longer subj=
ect to a dynamic mempool minimum <br />&gt; when they're bundled with a hig=
h-feerate child. Preliminary support for <br />&gt; that should be released=
 in the next major version of Bitcoin Core, with <br />&gt; improved suppor=
t being worked on for later releases. <br />&gt; <br />&gt; Package relay i=
s the only thing we need at this point because the <br />&gt; existing LN p=
rotocol makes use of CPFP carve-out, which minimizes <br />&gt; transaction=
 pinning issues. <br /><br />I don't disagree on package relay deployment a=
t this stage, with the some degree of technical skeptiscism<br />that shall=
 accomaphny all p2p proposals. Let's remember things that have been rollbac=
k or slowly rollout like<br />bip37 or `MEMPOOL` p2p message.<br /><br />&g=
t; However, another substantial Bitcoin Core improvement, cluster mempool, =
<br />&gt; is incompatible with CPFP carve-out. TRUC is an alternative to C=
PFP <br />&gt; carve-out that is easy to reason about, easy to use, more ge=
neral in <br />&gt; nature (good news for newer contract protocols), and wh=
ich can possibly <br />&gt; be automatically applied to existing LN onchain=
 transactions, allowing <br />&gt; cluster mempool to be deployed ASAP with=
out requiring any significant <br />&gt; changes to anyone else's software.=
 <br /><br />If you or anoyone think TRUC as an alternative to the CPFP as =
a transsction pinning mitigation as argued<br />in its merged BIP is easy t=
o reason on, thanks to communicate your lightning node pubkey, with TRUC pa=
tch<br />applied and a GPG-signed message authorizing me to demonstrate the=
 security properties of this solutions have<br />not been submitted to a fu=
lly contradictory evaluation.<br /><br />I pointed out few years ago that r=
elying on mempool-policy changes as a fully hardening solution was very<br =
/>likely limited to mitigate econommical-based pinnings (i.e bip125 absolut=
e fee rule), and this was before<br />the discovery of new transaction-rela=
y jamming vector (a terminology catched by your himself in some<br />privat=
e conversation if my memory is correct) like replacement cycling attacks [4=
].<br /><br />[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
021-June/019084.html "high-half" in this post<br />corresponds to what roug=
hly is bip331 today.<br /><br />&gt; I don't think we need to be overly con=
cerned about large numbers of LN users suddenly performing a malicious<br /=
>&gt; action that does not benefit them and does not put the network at ris=
k.<br /><br />Have a look on base-layer based exploitation description that=
 could provoke a large number of LN users, without<br />their own involveme=
nt, that could put the base-network at risk [5].<br /><br />[5] https://git=
hub.com/jamesob/mempool.work?tab=3Dreadme-ov-file#failure-one-mempool-to-ru=
le-them-all<br /><br />&gt; The alternative to TRUC that you've proposed is=
 replace-by-feerate <br />&gt; (RBFr). This is also compatible with existin=
g LN transactions and it's <br />&gt; conceptually super simple (I assume t=
he code is too), which is <br />&gt; wonderful. However, it's downsides are=
: <br /><br />About replace-by-feerate, I think it's a solution that have d=
ownside on its own, especially for<br />second-layers like lightning. I nev=
er took time to write a canonical post as infosec ethics would ask<br />me =
to notice lightning maininters to do first, even if the vulnerability idea =
has been vaguely sketched<br />out to few years ago.<br /><br />On all your=
 replace-by-feerate analysis, I think it deserves a thread on its own, as s=
omehow the issue<br />can have interactions with degree of fulfillness of m=
iner block templates, a conversation we had when V3<br />was proposed as so=
lution [6].<br /><br />[6] https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2022-January/019817.html and following answers<br /><br />&gt; but =
the deployment of cluster mempool requires removal of CPFP carve-out, and r=
emoval of CPFP carve-out requires<br />&gt; either the upgrade of thousands=
 of LN nodes and channels or a drop-in solution (ideally one that can be an=
alyzed <br />&gt; independently from cluster mempool, like TRUC)<br /><br /=
>And as I observed on one of the V3 PR threads and corresponding conversati=
ons, the CPFP carve-out do not provide<br />security to lightning implement=
ation as (a) old revoked commitment transactions can be used to fail the CP=
FP bump,<br />V3 or not V3 and (b) there is no base-layer p2p protocol disc=
overy of txids [6]. And I won't observe that when I looked<br />on lightnin=
g implementations code, only Eclair have minimal correct implementation of =
remote valid commitment transactions<br />broadcast, not the other one as i=
t's not even in the bolt spec.<br /><br />[6] https://github.com/bitcoin/bi=
tcoin/pull/28948<br /><br />So unless someone argued to the contrary, sayin=
g TRUC was needed to then deploy cluster mempool is an intellectual<br />fa=
llacy, of which the origin could likely arises from the back macket of PR r=
eviews trading happening in the bitcoin core<br />project for people to adv=
ance their own pet projects. At the very least, from my own code review of =
the folks bitcoin<br />core PR related to this line of deployment you're ex=
posing, I'm not sure they're understanding so well cross-layers issues [7].=
<br /><br />[7] https://github.com/bitcoin/bitcoin/pull/29427<br /><br />I =
think you're rather making the points that the current group of most active=
 bitcoin core contributors, are indeed<br />skilled bitcoin engineers, vett=
ed with project-management know-how and informed about bitcoin technical hi=
story and know<br />how to stay polite and civil (most of the time) to crea=
te a fruitful technical conversation atmosphere. They're not necessarily<br=
 />the most astute and adversarial minds to spot on the flight the weakness=
 of new technical proposals, neither with the character<br />to say so _at =
the cost_ of sometimes being rude and negative in the communication tone. A=
nd this in line with my point above<br />recalling that the bitcoin core gr=
oup of people themselves estimate themsleves they don't do a good job in te=
rm of security<br />vulnerabilties handling.<br /><br />&gt; There have alr=
eady been multiple public discussions about how improved <br />&gt; RBF pol=
icies can be implemented once cluster mempool is available, many <br />&gt;=
 of which bring us closer to something like RBFr in a way that's easier <br=
 />&gt; to prove won't enable free relay, and perusing that seems to me lik=
e a <br />&gt; productive outlet if you are interested. <br /><br />I alrea=
dy reviewed some parts of cluster mempool. Fundamentally, economical mempoo=
l pinnings for second-layers (bip125 absolute<br />fee) with pre-signed tim=
e-sensitive transactions arises from a world where there is (a) an asynchro=
nicity of mempools and (b) one<br />cannot guess feerates at block + 1 (-- =
let's say in a deterministic fashion as understood by traditional cryptogra=
phic litterature<br />when doing cryptanalysis). Better RBF policies won't =
solve that, including RBFr.<br /><br />&gt; After several hours of writing =
and thinking, I don't see any problems<br />&gt; with the current approach =
using TRUC or with the general lack of<br />&gt; interest in RBFr solutions=
 at this time. I've tried to explain how I<br />&gt; arrived at my conclusi=
ons at each step and I welcome any corrections.<br /><br />On my personal p=
erspective, and after careful considerations of all the technical points yo=
u've raised. I still think TRUC<br />has a lot of problems. RBRFr too has t=
echnical problems. About TRUC I think it's an acceptable temporary solution=
 to minimize<br />the pinning surface of lightning implementations, pending=
 for the design of a better solution (more likely at the consensus-level,<b=
r />here consistently as I pointed out 3 years ago). Though we shall be hon=
est with ourselves and not engage in overdue security theater<br />about TR=
UC properties.<br /><br />To finish, I'll re-assert what is my appreciation=
. Currently, I don't think the bitcoin core folks handling the security lis=
t has<br />necessarily the proven level of competency to fully evaluate the=
 issues reported by Peter, however I don't believe in the present<br />case=
 they have done anything wrong infosec ethically-wise.<br /><br />Best,<br =
/>Antoine<br />ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e=
7a3d65b256caa7<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" clas=
s=3D"gmail_attr">Le samedi 20 juillet 2024 =C3=A0 07:45:24 UTC+1, David A. =
Harding a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">On 2024-07-18 05:56, Peter Todd wrote:
<br>&gt; I disclosed it to the bitcoin-security mailing list as a test: doe=
s
<br>&gt; Bitcoin Core actually care about free relay attacks?
<br>
<br>They do.  Several free relay attacks that were present in earlier
<br>versions of Bitcoin were eliminated in later versions.  New proposals
<br>are evaluated for their potential to create new permanent free relay
<br>vectors.  The discovery of free relay is almost always reason enough to
<br>reject a proposal.
<br>
<br>The free relay attack you describe in your email and the type of free
<br>relay enabled by your replace-by-feerate (RBFr) proposal can allow an
<br>attacker to 10x to 100x the amount of bandwidth used network wide by
<br>relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
<br>effectively for free if they were going to send a bunch of transactions
<br>anyway).
<br>
<br>I cannot imagine what would make you think that protocol developers are
<br>not concerned about attacks that could drive large numbers of relay
<br>nodes off the network for a cost easily affordable to any well-funded
<br>adversary.
<br>
<br>In this case, you&#39;ve found a specific instance (full-RBF vs signale=
d
<br>RBF) of a well-known general problem (optional policies leading to
<br>mempool inconsistencies, allowing free relay) and appear to be arguing
<br>that devs don&#39;t care about free relay because they refused to rever=
se a
<br>previous decision (to not change the RBF configuration default) that ha=
s
<br>been hotly debated multiple times.
<br>
<br>An alternative interpretation is that they (1) do care about free relay=
,
<br>(2) recognize that solving free relay is a hard problem that requires
<br>research and development, and (3) refuse to be forced into restarting
<br>debate on an already overdiscussed issue that gets nobody closer to
<br>fundamental solutions.
<br>
<br>&gt; I believe the authors of that BIP are fully aware of the fact that
<br>&gt; &quot;free&quot; relay is an unavoidable problem, making their rat=
ional for
<br>&gt; TRUC/V3 bogus
<br>
<br>Differences in node policy leading to mempool inconsistencies (which
<br>allows free relay) is a well known problem that&#39;s the result of Bit=
coin
<br>being an open protocol based on free/libre software (two things I think
<br>we all want).  Many protocol developers have attempted to address the
<br>problem over the years, most recently just a few months ago with an
<br>updated proposal for using weak blocks as a first step to address
<br>&quot;diverging mempool policies&quot;.[1]
<br>
<br>A currently unsolved problem is not necessarily an unavoidable problem
<br>and it seems reasonable to me for devs to be skeptical of proposals lik=
e
<br>RBFr that add to the list of things that enable free relay.
<br>
<br>&gt; I believe the authors of [BIP431...] don&#39;t want to admit that =
they&#39;ve
<br>&gt; wasted a large amount of engineering time on a bad proposal.
<br>
<br>You&#39;ve previously argued against designing contract protocols to de=
pend
<br>CPFP-style fee bumping for their offchain transactions, however that is
<br>what is widely used by LN today and it appears to be what LN and other
<br>offchain protocol developers want to use in the future.  If we accept
<br>that, at least for the purposes of argument, what can we do to improve
<br>CPFP fee bumping for LN?
<br>
<br>All we really need at this point is to enable package relay so that
<br>parent transactions are no longer subject to a dynamic mempool minimum
<br>when they&#39;re bundled with a high-feerate child.  Preliminary suppor=
t for
<br>that should be released in the next major version of Bitcoin Core, with
<br>improved support being worked on for later releases.
<br>
<br>Package relay is the only thing we need at this point because the
<br>existing LN protocol makes use of CPFP carve-out, which minimizes
<br>transaction pinning issues.
<br>
<br>However, another substantial Bitcoin Core improvement, cluster mempool,
<br>is incompatible with CPFP carve-out.  TRUC is an alternative to CPFP
<br>carve-out that is easy to reason about, easy to use, more general in
<br>nature (good news for newer contract protocols), and which can possibly
<br>be automatically applied to existing LN onchain transactions, allowing
<br>cluster mempool to be deployed ASAP without requiring any significant
<br>changes to anyone else&#39;s software.
<br>
<br>As you&#39;ve shown[2], the main downside of TRUC transactions (if we&#=
39;re
<br>going to depend on CPFP-style fee bumping anyway) is that users of TRUC
<br>transactions who have a malicious counterparty might need to pay a
<br>slightly higher onchain feerate than they would need to pay under the
<br>same situation with CPFP carve-out.  However, the increase is small
<br>enough that most honest parties should be able to afford it, so there&#=
39;s
<br>no incentive for a counterparty to do it.  I don&#39;t think we need to=
 be
<br>overly concerned about large numbers of LN users suddenly performing a
<br>malicious action that does not benefit them and does not put the networ=
k
<br>at risk.
<br>
<br>The alternative to TRUC that you&#39;ve proposed is replace-by-feerate
<br>(RBFr).  This is also compatible with existing LN transactions and it&#=
39;s
<br>conceptually super simple (I assume the code is too), which is
<br>wonderful.  However, it&#39;s downsides are:
<br>
<br>1. It fundamentally enables a significant amount of free relay.  I&#39;=
ll
<br>    sketch a super basic attack at the end of this email that costs 0.5=
5
<br>    BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
<br>    relay nodes.  I&#39;m sure more efficient attacks are possible.
<br>
<br>    An attacker who is able to consume an excessive amount of relay nod=
e
<br>    bandwidth at relatively low cost may be able to create both
<br>    short-term and long-term problems for all Bitcoin users.  If the
<br>    created problems result in a rapid increase in user feerates, then
<br>    free relay attacks become cheaper due to low feerate transactions
<br>    being automatically evicted from the bottom of the mempool.
<br>
<br>2. It may allow empting the mempool at relatively low cost.  An attacke=
r
<br>    sending just 750 transactions at the top mempool feerate can
<br>    guarantee eviction of every honest user&#39;s transactions.  The at=
tacker
<br>    can then replace 300 MB of transactions with a single 43,179 vbyte
<br>    transaction.  Even if the replacement transaction pays 100
<br>    sats/vbyte, when you compare that to the 1,000,000 vbytes of
<br>    next-block transactions each miner lost, the miner is only earning =
an
<br>    effective feerate of 4.3 sats/vbyte.
<br>
<br>    Further, it&#39;s easy to imagine situations where evicting
<br>    time-sensitive transactions from mempools might allow theft of fund=
s
<br>    in excess of a few thousand dollars (my immediate thoughts go to
<br>    situations involving watchtowers).
<br>
<br>3. Limiting the worst-case free relay and excessive mempool eviction
<br>    requires additional rules (e.g. one-shot RBFr) that are challenging
<br>    to implement and analyze at present, as several devs have noted[3].
<br>    Both implementation and analysis should become much easier if clust=
er
<br>    mempool is deployed (also noted by devs), but the deployment of
<br>    cluster mempool requires removal of CPFP carve-out, and removal of
<br>    CPFP carve-out requires either the upgrade of thousands of LN nodes
<br>    and channels or a drop-in solution (ideally one that can be analyze=
d
<br>    independently from cluster mempool, like TRUC).
<br>
<br>To me, TRUC seems like an excellent approach.  It&#39;s something that =
can
<br>be evaluated independently of cluster mempool but which can help allow
<br>that deployment to proceed (in addition to the other previously
<br>described benefits that TRUC brings).
<br>
<br>There have already been multiple public discussions about how improved
<br>RBF policies can be implemented once cluster mempool is available, many
<br>of which bring us closer to something like RBFr in a way that&#39;s eas=
ier
<br>to prove won&#39;t enable free relay, and perusing that seems to me lik=
e a
<br>productive outlet if you are interested.
<br>
<br>&gt; this is quite an odd case of Core politics
<br>
<br>I began writing this reply to force me to examine your claims for
<br>myself.  You have a long history of noticing things other people missed=
.
<br>I was worried that some compelling point of yours was being ignored as
<br>the result of past controversies.
<br>
<br>After several hours of writing and thinking, I don&#39;t see any proble=
ms
<br>with the current approach using TRUC or with the general lack of
<br>interest in RBFr solutions at this time.  I&#39;ve tried to explain how=
 I
<br>arrived at my conclusions at each step and I welcome any corrections.
<br>
<br>Thanks,
<br>
<br>-Dave
<br>
<br>[1] <a href=3D"https://delvingbitcoin.org/t/second-look-at-weak-blocks/=
805" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www=
.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t/second-look-at=
-weak-blocks/805&amp;source=3Dgmail&amp;ust=3D1721614010714000&amp;usg=3DAO=
vVaw0Zgwc6HPrKMC8CE0duzKvn">https://delvingbitcoin.org/t/second-look-at-wea=
k-blocks/805</a>
<br>[2]=20
<br><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023=
-December/022211.html" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2023-December/022211.html&amp;source=3Dgmail=
&amp;ust=3D1721614010714000&amp;usg=3DAOvVaw34tSpQCKLafVaJ_EPkBCZC">https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html<=
/a>
<br>[3]=20
<br><a href=3D"https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-f=
or-replace-by-feerate-to-escape-pinning" target=3D"_blank" rel=3D"nofollow"=
 data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps:/=
/bitcoinops.org/en/newsletters/2024/02/07/%23proposal-for-replace-by-feerat=
e-to-escape-pinning&amp;source=3Dgmail&amp;ust=3D1721614010714000&amp;usg=
=3DAOvVaw1Z4QiVNxM74EW7ea77_uPD">https://bitcoinops.org/en/newsletters/2024=
/02/07/#proposal-for-replace-by-feerate-to-escape-pinning</a>
<br>
<br>---
<br>A simple free relay attack using RBFr
<br>
<br>## Constants
<br>
<br>100,000 vbytes =3D=3D ~400,000 bytes
<br>   A 1-input, 1-output P2TR scriptpath spend with the maximum amount
<br>   of witness data allowed by Bitcoin Core defaults
<br>
<br>111 vbytes =3D=3D 162 bytes
<br>   A 1-input, 1-output P2TR keypath spend
<br>
<br>## Attack
<br>
<br>- Attacker obtains 500,000 UTXOs
<br>
<br>- For each UTXO
<br>
<br>   - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,00=
0
<br>     byte) transacton.
<br>
<br>   - Waits for it to propagate.
<br>
<br>   - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacemen=
t
<br>     that is 111 vbytes (162 bytes).
<br>
<br>## Analysis
<br>
<br>- At 162 bytes each, 500,000 transactions is 81 MB.  I think that will
<br>   fit in a default-sized mempool.
<br>
<br>- The total amount of transaction data relayed is 500_000 * (400_000 +
<br>   162), or about 200 GB.
<br>
<br>- The typical daily bandwidth requirement of a blocks-only node is
<br>   roughly 2.5 MB * 144, or about 0.36 GB per day.  Ideally a relaying
<br>   node is about the same due to compact blocks, but realistically, it&=
#39;s
<br>   a small multiple of that.  Call it 2 GB per day.
<br>
<br>   - This implies the attack push each RBFr relay node to use 100x a
<br>     non-RBFr relay node.
<br>
<br>- At 111 vbytes each, 500,000 transactions is 55.5 million vbytes.  At
<br>   my nodes current mempoolminfee (1 sat/vb), that&#39;s 55.5 million s=
ats,
<br>   or 0.55 BTC (about $37,000 USD).
<br>
<br>- This analysis ignores the cost of obtaining the UTXOs and possibly
<br>   later consolidating them, but it also ignores some easy optimization=
s
<br>   such as batching the replacements.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com</a>.=
<br />

------=_Part_507423_1098517225.1721527853625--

------=_Part_507422_1310615009.1721527853625--