path: root/38/e0a073ac5bf733e0f5cef067aa2bfa2a28e169

Delivery-date: Fri, 19 Jul 2024 23:45:31 -0700
Received: from mail-oi1-f191.google.com ([209.85.167.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDZ3NVEJ5UFBBAV25W2AMGQEPSPLCWQ@googlegroups.com>)
	id 1sV3qU-0003FW-Ld
	for bitcoindev@gnusha.org; Fri, 19 Jul 2024 23:45:31 -0700
Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-3daa1679e0csf2530899b6e.2
        for <bitcoindev@gnusha.org>; Fri, 19 Jul 2024 23:45:30 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721457924; cv=pass;
        d=google.com; s=arc-20160816;
        b=HfGtR7oJ44BCyqrQ1yzEVsl49EX+COkppm2PYrBV9ofQ8t5cDoYYTDxzQYKso8WdeD
         dUQW1cs5IIjcQtJA6MD/MVGB+/CzSaL5JGg311127x98IvNnE1bxw3A49EWae928/66f
         gj222r8LVaKYQwI6yqYJVRWoI8c97hDI74FJlMBQYjRoZfCwh9lkdrA1dWN7Y1foxPiL
         fMB0biSswPiFJ5mTOuzykfbmPY5Y+uznYzwmI+RxA+ywLg6W6rpof02Fr1Cm5qA+QOHg
         atyUO6jN/M7Rc6gt8IKHL0YbGAXr0aG/VQvivzq2wzwmwvwx6bRQ9KJsMHHiKwctpIFA
         3IDA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:message-id:references:in-reply-to
         :subject:cc:to:from:date:mime-version:sender:dkim-signature;
        bh=gv1vdwNlO6NsnOMB30CnhTVifNkwddDetDpiveJZkS0=;
        fh=e4R02oisoFE1Bc7fKcuSa4V7RaEKS6uvFrMBVx553KE=;
        b=sPkmD+Rv2m8XoHCQFOaGgryE7FmSzjgrgO2FPo2tzRRthrcuvQJtPStBDkD1SC3BMh
         qizuJWRXl1S2Eedc2V+4IfavQ+XbekB1deYOfrxO2n2sl1+mmQ+eNOIhfEv4Ew1N9Tfk
         +23FhImPsx2YTAtERYM5XkKsKsvs20P1dkG5ELCygTAkR3Kk3gPL5W6ot5vC2bTRpVfV
         ZV2u7V/K2wmKpJFqo72jA8HBzKwcthGbnxonqaGKlpsYIQ3TeqATPvYcqqghsXjWclvV
         M5u8vUr0J47xUKgIxRpzN3D5xeRiAL0ZTGBTf0/25L/tdnxwLQE7qMq9UrX+xl2RNzNR
         t+Gg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721457924; x=1722062724; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:message-id:references:in-reply-to:subject:cc:to
         :from:date:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gv1vdwNlO6NsnOMB30CnhTVifNkwddDetDpiveJZkS0=;
        b=nN/Ct9gKPfWl0qf1a9i1PQ8xFtWwggvMkCJs3cU+JZJn7NxEUBVAxd/PDYyjlQsgtG
         +atWMPxHPJKwL7b5rW4fxhBVyl46wVEmiaX9NNAa7ThOUfht+gdgMOaTa+k7jaiQiweX
         wKQyzBGqaSQG/03gdWqn1mJqzreeNS97yjUutNam1QALBs5D6c9aBVek3s1fpo1NMySx
         b9pbnzIWfP6jetSCuVa7tZbphnvFkohq7oyD4oHDVDCjE9iTIFydIoFosrZwvJk49S4B
         qQOJu2nwvVM5iwkdK2b4GGrS39STYHd80aQRFJa80Tzvyv1gjfLsesO8OlbhwlDmzPm2
         mCKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721457924; x=1722062724;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:message-id:references:in-reply-to:subject:cc:to
         :from:date:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=gv1vdwNlO6NsnOMB30CnhTVifNkwddDetDpiveJZkS0=;
        b=msPlPRQJLQycWH50hUR1ZsKXdWC0yL7kCTNUPM3SIb4/6GldcQRg56gafTNxrREFCA
         4bTKJenghgcSRpenIE8+LXYR+cGH4uicBBin4l5BHM5cLcSNAvbC/jCB9m1n2DM2W6GR
         K6ekgcqlh9BYquiEZ29SbfXI5qMmClfxVZgTQp9m7KjzJCma6i3EKFYBJdCelkJt++lE
         9mhk2adt6LvV1oPReoRGkkLGWvmwNhYOrqo9lWTHmJoBQklZqYSgSUwvWDsKcijkmz4u
         U9Ajmdqv4Ww1aVqJazuY3KX47nDEExGgTi07bwQVUbQPyemRVahjDws3p7BlCLnwxcxJ
         uj0Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXnfxLN99eN7pn9VxDGo+yf0ILAgxZsByg4OMtEAN+NYb+GA8sgu5iZJcZPqMqyGrWyYnD9Wz+BYh+k/MrOxU0hLkfa4cw=
X-Gm-Message-State: AOJu0YytKOLyZWE9h0ScYDezwYNh/JmVIPlH2LAA74hNvDO+zaLoue8C
	HzlLfEIzlfyj+hCGYrYRgfcR47a1w9alwo4nUHLYF7O6CbvOOYsN
X-Google-Smtp-Source: AGHT+IFvKRct3Xvx7lMejKcVQx7wYPoBR4cNNQRVaIZ5tVrX6XSnCEugoW9kT92ekyp3R+XvT1SMAQ==
X-Received: by 2002:a05:6871:5c9:b0:254:9501:db80 with SMTP id 586e51a60fabf-261213938eamr1674066fac.14.1721457923955;
        Fri, 19 Jul 2024 23:45:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6870:9f0d:b0:254:7203:f69f with SMTP id
 586e51a60fabf-260ec4e9db3ls3307002fac.2.-pod-prod-05-us; Fri, 19 Jul 2024
 23:45:22 -0700 (PDT)
X-Received: by 2002:a05:6871:e2d6:b0:261:a04:2ab2 with SMTP id 586e51a60fabf-261212d7c33mr109777fac.1.1721457922236;
        Fri, 19 Jul 2024 23:45:22 -0700 (PDT)
Received: by 2002:a05:6808:a09:b0:3d9:2ea5:e56e with SMTP id 5614622812f47-3dadf32f947msb6e;
        Fri, 19 Jul 2024 23:41:13 -0700 (PDT)
X-Received: by 2002:a05:6602:6c1c:b0:807:c17e:2e26 with SMTP id ca18e2360f4ac-81b34881bc7mr76807139f.11.1721457672889;
        Fri, 19 Jul 2024 23:41:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721457672; cv=none;
        d=google.com; s=arc-20160816;
        b=NQDW9hQ2QnrPCD/NqKKJu81NsrltjE7sD+5M3ToSU7/SAaXd3BfSFRDl43l2S7aDFx
         8cc8BfqAIBuHwxYqj88MZm+/0mKJmP8puS0rfCL5I7UEPGy+t5/YCin234/AfoP3LSUk
         +S8kSzT/aLnG/365OcbPFltg0671BQAequyP+N1gxZ8X5AMcTx/QtSFp6dDT8FmnvPt0
         rB+wfpvX53G8JaPFYKxDMlDv2qOcNftTAIKgY7+Gs2047nTmxOg7fNt9H3vLifMWa0N6
         CrSY0O+X8gYEVadASY5WHJyuMMUyxhg7UYE1KQm6kM+paZ08uJUhI9bB31YMGt+Kk7UI
         tjQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:references:in-reply-to:subject
         :cc:to:from:date:mime-version;
        bh=n1/diYZHuO4zetnLJdEedoa4L+/XPKmp1xIvOHV6fVM=;
        fh=psWP3UCtCzzPEOUoUzVM9ZZK8adYsTeWDAKCd6L5Zok=;
        b=AV7Ym88y+kvKlSXiCKLXDniig1vEHVeW1X0AcjAN7K6JZ5MuvjMk7ww9SULNJTLnNw
         yygPpcGF1YcK0nZB/9Ti0ZLHK4hKn9RlZ8mERcsN9i/oRfwuXKuVUQTxFmCVIYLhVXKB
         pLqbSqO/y/qZ+O36JoYVwd5086Xqrln/Pa0PSKqfXEXsMFMjJadxrpGU+Vrm+RU/TlLH
         KbcNmSjl2tjGWkV2zmphojg1MZ31fTFktSCqw6DA9qgMOQsRQC2p/dlxrkgsiyuiiB0r
         v+f8uWA3TNHgw3/sPkIO/SPjEeM3Vk/NJkB6mFTA/gmNvT/+urrttOfdymh40UwseS1S
         yNkg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us. [2607:fe70:0:3::d])
        by gmr-mx.google.com with ESMTPS id ca18e2360f4ac-819adb0f5fcsi13116239f.1.2024.07.19.23.41.12
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 19 Jul 2024 23:41:12 -0700 (PDT)
Received-SPF: pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) client-ip=2607:fe70:0:3::d;
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
	by smtpauth.rollernet.us (Postfix) with ESMTP id 77FDF280085E;
	Fri, 19 Jul 2024 23:41:08 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	by smtpauth.rollernet.us (Postfix) with ESMTPSA;
	Fri, 19 Jul 2024 23:41:07 -0700 (PDT)
MIME-Version: 1.0
Date: Fri, 19 Jul 2024 20:41:07 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
In-Reply-To: <Zpk7EYgmlgPP3Y9D@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
Message-ID: <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset="UTF-8"; format=flowed
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 2f17.669b5c03.d8fff.0
X-Original-Sender: dave@dtrt.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted
 sender) smtp.mailfrom=dave@dtrt.org
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.2 (+)

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] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html
[3] 
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 == ~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 == 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.

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/c6593662694f9d4a4fe999dd432f87ff%40dtrt.org.