path: root/e0/39a3073e75dcf14aea49cb605bc3ea1980df46

Return-Path: <lf-lists@mattcorallo.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 09F77C0175;
 Thu, 23 Apr 2020 06:21:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 032F787DA8;
 Thu, 23 Apr 2020 06:21:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id sgugEthWgTq5; Thu, 23 Apr 2020 06:21:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by whitealder.osuosl.org (Postfix) with ESMTPS id DF6CB87DA6;
 Thu, 23 Apr 2020 06:21:53 +0000 (UTC)
Received: from [IPv6:2620:6e:a007:235::1] (unknown [IPv6:2620:6e:a007:235::1])
 by mail.as397444.net (Postfix) with ESMTPSA id A656A2338DE;
 Thu, 23 Apr 2020 06:21:51 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
Date: Wed, 22 Apr 2020 23:21:50 -0700
Message-Id: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
X-Mailer: iPhone Mail (17E262)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 06:21:55 -0000

Great summary, a few notes inline.

> On Apr 22, 2020, at 21:50, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> =EF=BB=BFGood morning lists et al,
>=20
> Let me try to summarize things a little:
>=20
> * Suppose we have a forwarding payment A->B->C.
> * Suppose B does not want to maintain a mempool and is running in `blockso=
nly` mode to reduce operational costs.

Quick point of clarification, due to the mempool lacking a consensus system (=
that=E2=80=99s the whole point, after all :p), there are several reasons to t=
hat just running a full node/having a mempool isn=E2=80=99t sufficient.

> * C triggers B somehow dropping the B<->C channel, such as by sending an `=
error` message, which will usually cause the other side to drop the channel o=
nchain using its commitment transaction.
> * The dropped B<->C channel has an HTLC (that was set up during the A->B->=
C forwarding).
> * The HTLC, being used in a Poon-Dryja channel, actually has the following=
 contract text:
> * The fund may be claimed by either of these clauses:
> * C can claim, if C shows the preimage of some hash H (hashlock branch).
> * B and C must agree, and claim after time L (timelock branch).
> * B holds a signature from C that can claim the timelock branch of the HTL=
C, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIFY=
`.
> * The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate.
> * C can "pin" the HTLC output by spending using the hashlock branch, and c=
reating a large fee, low fee-rate (tree of) transactions.

Another: this is the simplest example. There are also games around the packa=
ge size limits if I recall correctly.

> * As it is a low fee-rate, miners have no incentive to put this in a block=
, especially if unrelated higher-fee-rate transactions exist that would earn=
 them more money.
> * Even in a full RBF universe, because of the anti-DoS mempool rules, B ca=
nnot evict this pinned transaction by just bidding up the feerate.
> * A replacing transaction cannot evict alternatives unless its absolute fe=
e is greater than the absolute fee of the alternative.
> * The pinning transaction has a high fee, but is blockspace-wasteful, so i=
t is:
>   * Undesirable to mine (low feerate).
>   * Difficult to evict (high fee).
> * Thus, B is unable to get its timelock-branch transaction in the mempools=
 of miners.
> * C waits until the A->B HTLC times out, then:
> * C directly contacts miners with an out-of-band proposal to replace its t=
ransaction with an alternative that is much smaller and has a low fee, but m=
uch better feerate.

Or they can just wait. For example in today=E2=80=99s mempool it would not b=
e strange for a transaction at 1 sat/vbyte to wait a day but eventually conf=
irm.

> * Miners, being economically rational, accept this proposal and include th=
is in a block.
>=20
> The proposal by Matt is then:
>=20
> * The hashlock branch should instead be:
> * B and C must agree, and show the preimage of some hash H (hashlock branc=
h).
> * Then B and C agree that B provides a signature spending the hashlock bra=
nch, to a transaction with the outputs:
> * Normal payment to C.
> * Hook output to B, which B can use to CPFP this transaction.
> * Hook output to C, which C can use to CPFP this transaction.
> * B can still (somehow) not maintain a mempool, by:
> * B broadcasts its timelock transaction.
> * B tries to CPFP the above hashlock transaction.
> * If CPFP succeeds, it means the above hashlock transaction exists and B q=
ueries the peer for this transaction, extracting the preimage and claiming t=
he A->B HTLC.

Note that no query is required. The problem has been solved and the preimage=
-containing transaction should now confirm just fine.

> Is that a fair summary?

Yep!

> --
>=20
> Naively, and remembering I am completely ignorant of the exact details of t=
he mempool rules, it seems to me quite strange that we are allowing an undes=
irable transaction (tree) into the mempool:
>=20
> * Undesirable to mine (low fee-rate).
> * Difficult to evict (high fee).

As noted, such transactions today are profit in 10 hours. Just because they=E2=
=80=99re big doesn=E2=80=99t mean they don=E2=80=99t pay.

> Miners are not interested in low fee-rate transactions, as long as higher f=
ee-rate transactions exist.
> And being difficult to evict means miners cannot get alternatives that are=
 more lucrative for them.
>=20
> The reason (as I understand it) eviction is purposely made difficult here i=
s to prevent certain DoS attacks on Bitcoin nodes, specifically:
>=20
> 1. Attacker sends a low fee-rate tx as a "root" transaction.
> 2  Attacker sends thousands of low fee-rate tx that build off the above ro=
ot.

I believe the limit is 25, though the point stands, mostly from a total-size=
 perspective.

> 3. Attacker sends a slightly higher fee-rate alternative to the root, evic=
ting the above tree of txes.
> 4. Attacker sends thousands of low fee-rate tx that build off the latest r=
oot.
> 5. GOTO 3.
>=20
> However, it seems to me, naively, that "an ounce of prevention is worth a p=
ound of cure".

Sadly, it=E2=80=99s very very easy for this to be a huge amount of CPU + ban=
dwidth.

> As I understand it, the mempool is organized already into "packages" of tr=
ansactions, and adding a transaction into the mempool involves extending and=
 merging packages.
> Perhaps the size of a package with low fee-rate (relative to the other pac=
kages in the mempool) can be limited, so that mempools drop incoming txes th=
at extend a low-fee-rate tree of transactions.
> This means an attacker cannot send thousands of low fee-rate tx that build=
 off some low fee-rate root tx in the first place, so it can still be evicte=
d easily later without much impact.

There have been several proposals before around considering a transactions p=
osition in the mempool for various similar criteria. The extreme version bei=
ng simply heavily rate-limiting transaction relay at low feerates and allowi=
ng much more liberal replacement of such packages. It isn=E2=80=99t quite pe=
rfect for this issue, though, as it may be easy for the attacker to just fil=
l that rate-limit bucket.

> Naively, it seems to me to prevent the DoS attack as well, as at step 2 it=
 would be prevented from sending thousands of low fee-rate tx building off t=
he root.
>=20
> As well, as I understand it, this merely tightens the mempool acceptance r=
ules, preventing low fee-rate packages from growing (analogous to a consensu=
s-layer softfork).
> The "cannot evict high absolute fee" rule can be retained, as the low-fee-=
rate package is prevented from reaching a large size.
>=20
> Would that be workable as a general solution to solve (what I think is) th=
e root cause of this problem?

It=E2=80=99s not clear to me that tightening the acceptance rules wouldn=E2=80=
=99t break other existing uses. Historically the 25 package size limit has p=
roven to be an issue for users doing (somewhat na=C3=AFve) centralized walle=
t withdraws. Sadly many users want that =E2=80=9Cpayment pending=E2=80=9D no=
tification instantly, even if we know it to be somewhat lacking in security.=
 Wallets which have over-compacted their UTXOs are thus stuck making long ch=
ains.

To revive an old discussion, on the original thread proposing the CPFP Carve=
-Out, I said this:

> As an alternative proposal, at various points there have been discussions a=
round solving the "RBF-pinning" problem by allowing transactors to mark thei=
r transactions as "likely-to-be-RBF'ed", which could enable a relay policy w=
here children of such transactions would be rejected unless the resulting pa=
ckage would be "near the top of the mempool". This would theoretically imply=
 such attacks are not possible to pull off consistently, as any "transaction=
-delaying" channel participant will have to place the package containing A a=
t an effective feerate which makes confirmation to occur soon with some like=
lihood. It is, however, possible to pull off this attack with low probabilit=
y in case of feerate spikes right after broadcast.

To which Rusty responded (and I may be paraphrasing here): =E2=80=9CFuck Yea=
=E2=80=9D. I=E2=80=99m still not much of a fan of this idea as it introduces=
 too many constants (what is =E2=80=9Cthe top of the mempool=E2=80=9D, anywa=
y?), and it=E2=80=99s unclear to me what you do as the mempool prevailing fe=
erate changes, but it seems more along the lines or what you=E2=80=99re look=
ing for here.