From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 In-Reply-To: Date: Wed, 22 Apr 2020 23:21:50 -0700 Message-Id: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> References: To: ZmnSCPxj X-Mailer: iPhone Mail (17E262) Cc: Bitcoin Protocol Discussion , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.