path: root/30/fc66118f9dc0e2fc726fe14a3c0e843aaf62ff

Delivery-date: Mon, 29 Jul 2024 22:48:27 -0700
Received: from mail-oa1-f57.google.com ([209.85.160.57])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDZ3NVEJ5UFBBIP5UG2QMGQEPW27QPA@googlegroups.com>)
	id 1sYfik-0005HO-9P
	for bitcoindev@gnusha.org; Mon, 29 Jul 2024 22:48:27 -0700
Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-260e8c635afsf4705585fac.0
        for <bitcoindev@gnusha.org>; Mon, 29 Jul 2024 22:48:25 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1722318500; cv=pass;
        d=google.com; s=arc-20160816;
        b=Xc0CfAxVjkfnJxnTfAissIyLAwNXxsiR7ywaITGVFR/n0sysc6qoJkmYaXk0pM5veK
         isJL+OodoxRasD0BwkQb9LKVF0AvWlVPkF5GyT28zPXMKEY++Rapd72RARm8ZBXuetaU
         CHReqvUkCv4M8NTorBSHbrIUQ+5rCCDeLB8RSVEvQ2MLYMOypC/Lqrj+LGM2FGpa9Wo+
         HPyq8esZN3sSHCTEdKtq7xE6TNljzyX7LGj3MOzwq88O+J/8i1KBbivmoSv7DDzRxnee
         +jRolS1qNXo4b8brFyBJq4HWc2xKleGYrKyBYOA6r1/EluPkSoexH05Hu75gSmFSyv1G
         7Jgg==
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=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=;
        fh=+y4ZrTrtvsB1s3wu/k3znc8ORdegBvqbnDXDzZu3Ec0=;
        b=S1TO618Yno/vsiAw0mO1dIQxzqgSiVrSPUwcH/uf4oGYGFXDnzAZncMGdZKXniGfUx
         68GbV4+zu7ISZ6PRS1aITNNXyyt/lP/hOce4ZjhL9uVD9Rve1/3ZVam6mfyUlXuCKe7N
         OyO9RdUxN8qAa3DMqPf5dq0pKVhNLsfg0mZV0RmI+620Q+5fOOOMe7oeytWImI4eXLpb
         3E+yAkEA1lnNKJG3PLqYJ+GOGMh7Df6nFpwPFQ5xvQIh0n1osslAd8rtEz8kWSj64e6A
         JyrFHjfD3WEnQWvt4TsCTGv5y4HNS3CmQJbVV55DJZGipyl7MflyL7dFf3zJremDPAeJ
         cJsQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) smtp.mailfrom=dave@dtrt.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1722318500; x=1722923300; 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=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=;
        b=Tf6AK8peKfY7yPOUPdbZI2ylLf/Q37WYquhXDx7NLnA4bPUk5IN9x5Sfc4zJsHLdoq
         TgganN/pndrfFciKmKo0kAla80Z/pPQda1kmYzZC+zjDfh9AufXe30ABX+Cn1842R5fC
         ve/n9JUpW+yf4sxUOtMfcZ2MpW5KXSvfUF+9AkuZH17ukdQorrMuk8HXLV9z++KDRcuN
         7PMrbdNnd2TiAK88nBNv3JsOGUamFlX62+2RvnC95jkpBl3g/FvKScz/GQODBSwMLpPM
         Mf2KT6zo6zMLKNrHYYCFJdVpkKnf8B2TAsZMv7I8yrTqx/MysHlef8uA1/s5B3p+7WkA
         KhHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1722318500; x=1722923300;
        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=jY7jSMO0tANQEXmcwwRYlNgLnHP+314OK8EQwYmNDfw=;
        b=iRkSH61usCrn6LDBEKlV5jerpSMUxrYVm6jLdXmwRQxO8zNFsXtCZCyYXnHaVydFcu
         kzlMjnqnaA5A54EqhmQwTyopQl3JZoBLw0dDtqbtLgcappKgsMRJb3iRM76DDfFWlrjF
         BuB+f6sLz7ff374coP+CAU1cCq9Bm8JvjfJ9P9E+86ZLytSql6Owx6arX8vbrmlC3tPr
         3srUHg8hBiOtbASeVlc7Z4ABPDt+Jrf+gmu5mBIafJ0DmW7etTxYiKEkvm+Oe8mJWXcz
         KAlp22Q/C2GFFF3/CIo+XXSv72cHnsAhShc30Fdz8L1Ly3uRfrUdFXqiZ0S+9F6PazPO
         5HjQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUfPbXQqdRopz4V9BamgwmnKP9YhQJ1cCjPJxAhgHNgukW+BgxIyv1Y17jMDyB0vNcceK0GWl4z460unKli3NAntnUcgWY=
X-Gm-Message-State: AOJu0Yy+UoHndN60SR0mZ/t5mVY+Da6ER3lm4X/g+MA/nRxB1kdbr5Ek
	EQyecizVArSLsFqbXFjwX813wziS+sTptCWyRynvNKvJhglSxP3V
X-Google-Smtp-Source: AGHT+IEuG6QH2FpIfOE9lUrXpu0fRmnIW/CiTRfS4yZVLv5j3VuIjc6uoLgzdXLoBTlda8ZIhARraw==
X-Received: by 2002:a05:6870:164c:b0:261:21e9:1f19 with SMTP id 586e51a60fabf-267d4f03474mr11318736fac.35.1722318499341;
        Mon, 29 Jul 2024 22:48:19 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6871:a00d:b0:250:a95c:3b4d with SMTP id
 586e51a60fabf-2649fcb66a8ls6697884fac.1.-pod-prod-03-us; Mon, 29 Jul 2024
 22:48:17 -0700 (PDT)
X-Received: by 2002:a05:6871:e282:b0:254:a233:3d28 with SMTP id 586e51a60fabf-267d4cd0f03mr21947fac.1.1722318497403;
        Mon, 29 Jul 2024 22:48:17 -0700 (PDT)
Received: by 2002:a05:6808:d2:b0:3d9:3291:87dc with SMTP id 5614622812f47-3db1accbc20msb6e;
        Mon, 29 Jul 2024 21:57:23 -0700 (PDT)
X-Received: by 2002:a05:6808:1b06:b0:3d9:da81:6d59 with SMTP id 5614622812f47-3db23ced37dmr14072274b6e.34.1722315441824;
        Mon, 29 Jul 2024 21:57:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1722315441; cv=none;
        d=google.com; s=arc-20160816;
        b=ArK+AL3RP3eprJRz2750VuCmxy54ENu2+F/VtgG/sjSUJOxORUXQmixTTgoLWvBxPN
         WAP6voeK+dFcpnmrx0goTWzdqtifRbKMPzp5/sVaBFoGbJi6wn45hW2R4Zwy/xxWZV8R
         5zgFbqey90eyYK7ntC7KnyvVCtYsmY1e/oh5f8UluFmzHmoZAl0d1nwcK+tGB4QHv+nB
         wC4akShK1ggku3FqFMw4Exf05af4zB5Zn1r8/lKW9/OA8SuYZoP1ftTcWdB69Olq/HiP
         JEh4qzbGbReyLPO1PaSzB4wxWBNqss+rAej3IOHHHxj8DmQKRt5Z/CykEeKlbrpiQR1I
         NoWQ==
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=P9JqHWD2n5OjRqonIPwKK++Wvqc2FP4FY3y8trTAtMw=;
        fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=;
        b=Jx8mpw3p/UUJX/iRkb3H1L7Gd5dofxSw5RORF27I7hIqayuvvjpjGqEe6lqoY/f4J+
         gAx5i/RIr1Q1R3ndeD4svYGVocIWsBggfJWquTYUEUXn6DxX8dz1Yq6c4XgPkzJ4vplN
         YjHjKw07D7R3xt+BC/39yZ70z1HPUWC1zZIIXJfnfTUHb+rzzQ5BIxVUZDOc4MJqdC7L
         CBzYDWB8GjlZasJkv+gAdudT+1Uxoixx5Z0DtTGfyBSki5wggH1tQVU2544+ZYYH3kK+
         d7tQ6hBoulZw8dpiWNzATyPMSpewBczDWqBwuGIDu1/wHp0axmZpXAd4izc9WkQ+OFdz
         fZMw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) smtp.mailfrom=dave@dtrt.org
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us. [208.79.240.5])
        by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-7a9f5f2d1absi641948a12.1.2024.07.29.21.57.21
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 29 Jul 2024 21:57:21 -0700 (PDT)
Received-SPF: pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) client-ip=208.79.240.5;
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
	by smtpauth.rollernet.us (Postfix) with ESMTP id 5F9F82800095;
	Mon, 29 Jul 2024 21:57:18 -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;
	Mon, 29 Jul 2024 21:57:18 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 29 Jul 2024 18:57:17 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
In-Reply-To: <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
Message-ID: <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset="UTF-8"; format=flowed
X-Rollernet-Abuse: mailto:abuse@rollernet.us https://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 5b64.66a872ae.68c0.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 208.79.240.5 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: -0.8 (/)

On 2024-07-20 16:10, Antoine Riard wrote:
> If you or anoyone think TRUC as an alternative to the CPFP as a
> transaction pinning mitigation as argued in its merged BIP is easy to
> reason on [...]

Before I address your full point, I think there are two separate things
we want to reason about when considering a proposal like TRUC:

- How does it affect operators of full nodes, including miners and
   volunteer relay node operators?

- How does it affect existing and future protocol users?

By "easy to reason about", I'm mainly referring to how TRUC will affect
operators of full nodes.  IMO, it's critical to get that part right.  In
comparing TRUC to RBFR, it seems to me that it's much easier to reason
about TRUC's effect on relay behavior and mining profitability.

When it comes to reasoning about pinning attacks against LN, this is
almost fundamentally difficult owing to the difficulty of reasoning
about any complex state protocol, especially one that interacts with
multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
Bitcoin consensus).  Whether we're talking about CPFP, CPFP-CO, opt-in
RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
anything else, reasoning about the full implications of a change for LN
users will be difficult.

IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
TRUC, it is not their responsibility to ensure that it is perfectly safe
for downstream projects.  That onus falls on the downstream developers
(e.g., LN devs).  Of course, Bitcoin Core devs want to produce useful
tools and that incentivizes them to produce actual safety improvements;
however, it's unreasonable IMO to expect Bitcoin Core devs to understand
a downstream protocol as well as the devs who work directly on that
protocol.

For something like imbued TRUC, it probably shouldn't be used to replace
an existing mechanism that downstream devs depend on (see subsequent
arguments) unless the downstream devs agree (or there's another very
compelling reason).  Again, the onus falls on the downstream developers
to audit the mechanism's safety because they're the ones with
theoretical and operational experience using the downstream protocol.

Now on to your full point:

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

How would that work?  AFAIK, there's no LN software using TRUC, very few
relay nodes are using it (since it isn't yet enabled by default in a
release version), and no miners are using it (again, since it hasn't
been released).  I'm willing to put money at stake to settle a
disagreement that can't be settled with words, but I want to at least
learn something from the process.

My guess is that you're referring to the type of pinning attack you've
called "loophole pinning"[1], which I don't entirely understand, so I'll
do my best to describe it below and hopefully you can correct me on any
errors:

- Mallory guesses that, for the next 144 blocks, transactions in the
   mempool with a feerate of _x_ sats/vb will neither be confirmed nor
   evicted.  If Mallory guesses wrong, the attack will fail.

- Mallory controls a confirmed UTXO that she will spend in 10 different
   fee bumping transactions, making all of those transactions conflict.

- Mallory has 10 channels.  It doesn't matter whether these are all with
   the same counterparty, different counterparties, or a mix of
   counterparties.

- In each channel:

   - Mallory causes the channel to contain the maximum number of
     in-flight HTLCs the counterparty will allow, creating state _A_.
     Each in-flight HTLC inflates the size of the commitment transaction
     about ~40 vbytes.

     The specification maximum for in-flight HTLCs is 2*483, but many
     implementations default to a lower value due to risks from other
     known attacks.

   - Mallory causes all of the in-flight HTLCs to be settled honestly,
     revoking state _A_ that contained them.

   - Mallory causes a single HTLC to be sent through the channel.  Its
     satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
     1000), where _x_ is Mallory non-confirming-non-expiring feerate,
     vsize(A) is the size of the revoked commitment transaction, and
     1,000 is the maximum size of a TRUC fee-bumping child.

     For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC
     value is 60,000 sat.

   - Although Mallory knows the preimage necessary to resolve the HTLC,
     she doesn't send it to her counterparty offchain.  This will
     eventually force the counterparty to go onchain.

   - Mallory goes onchain first by broadcasting a package that consists
     of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
     that pays a total fee equal to the pending HTLC value (e.g. 60,000
     sat).

- Notably, Mallory is doing this in 10 channels simultaneously with the
   fee bump for each spending the same UTXO, so all of those fee bumps
   conflict with each other.  If Mallory broadcasts each package of
   revoked commitment transaction and fee bump to different nodes across
   the network, each particular package will only exist in the mempools
   of about 10% of nodes.

   - In some cases, Mallory's channel counterparty will receive the 
revoked
     commitment transaction via their own mempool monitoring code.

     - If they realize the feerate is below the amount necessary to get 
the
       transaction confirmed within the next 144 blocks, they will be 
able
       to CPFP fee bump the transaction themselves---but they will need
       to pay more than the 60,000 sat in fees that Mallory is offering.
       However, the pending HTLC is only worth 60,000 sat to them, so it
       may not make sense for them to fee bump.

   - In other cases, Mallory's channel counterparty will receive one of 
the
     conflicting packages.  They will not know that a revoked commitment
     transaction has been broadcast.

     - When Mallory hasn't settled the HTLC fast enough, they will
       broadcast a package of their own commitment transaction and their
       own CPFP fee bump child.  This will pay a higher feerate than
       Mallory paid (which is possible to do under the 60,000 sat budget
       because they're using much smaller transactions).

     - Their high feerate package will propagate until it encounters 
relay
       nodes that have their channel's revoked commitment transaction.
       Although the counterparty's transaction pays a higher feerate, it
       pays less absolute fees than Mallory's transaction and will be
       rejected by that relay node.

- In any cases where the pinning prevents confirmation within 144
   blocks, the HTLC's upstream node can claim a refund and Mallory can
   then use her preimage to steal the HTLC value from her counterparty,
   completing the attack successfully.

   - To settle the HTLC with its preimage, Mallory needs to pay more
     absolute fees to remove her pin, but because she pinned 10 channels
     with a single UTXO, paying to remove the pin from one channel and
     getting that spend confirmed will automatically remove the pin from
     all other channels.  In other words, her cost per channel is roughly
     10% what her honest counterparties would've had to pay to remove the
     pin.

     - However, once Mallory's pin is removed, all the counterparties
       should still broadcast spends of the HTLC-Failure transaction
       paying the HTLC's full value to fees in order to deprive Mallory
       of any profit.

Given the first point and the last point, I'm not sure how viable the
attack is (but, as I said, I'm not sure I understand it).  Estimating or
manipulating feerates correctly for over 144 blocks in a row sounds
difficult.  Counterparties being able to deprive Mallory of profit seems
like a major weakness.

Looking at other proposed improvements: one-shot RBFR with its
requirement that fee bumps enter the top portion of the mempool may
avoid this type of pinning; ideas for expanded versions of TRUC that
also require entering the top portion of the mempool may also avoid this
type of pinning, e.g. "TRUC v3.0.5".[2]

> About replace-by-feerate, I think it's a solution that have downside
> on its own, especially for second-layers like lightning.

If it looked like RBFR was going to be widely deployed, I think its
effect on LN would definitely warrant more research.

> And as I observed on one of the V3 PR threads and corresponding
> conversations, the CPFP carve-out do not provide
> security to lightning implementation
> [...]
> So unless someone argued to the contrary, saying TRUC was needed to
> then deploy cluster mempool is an intellectual fallacy

You described several attacks against anchor outputs using CPFP-CO, some
of which sound quite plausible to me, but none of them is certain to
succeed in any particular instance.  By comparison, disabling CPFP-CO
would leave all users of anchor outputs immediately vulnerable to the
original pinning attack that has an expected ~100% success rate and
barely any cost if executed against multiple channels simultaneously.

Given that, it makes no sense to disable CPFP-CO until a successor is
available.

> On my personal perspective, and after careful considerations of all
> the technical points you've raised. I still think TRUC has a lot of
> problems. RBRFr too has technical problems. About TRUC I think it's an
> acceptable temporary solution to minimize the pinning surface of
> lightning implementations, pending for the design of a better solution
> (more likely at the consensus-level [...])

Thank you for your opinion.  I too think TRUC is a good solution until
we find something better, and any significant improvements may indeed
require consensus changes.

-Dave

[1] 
https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830
[2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523

-- 
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/4e959cdbe70b1a3b9f1adb37fe3b986e%40dtrt.org.