From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19B86C0175; Thu, 23 Apr 2020 04:50:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0AC7B86C23; Thu, 23 Apr 2020 04:50:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua6tWmfwFGlJ; Thu, 23 Apr 2020 04:50:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 8828386C1B; Thu, 23 Apr 2020 04:50:18 +0000 (UTC) Date: Thu, 23 Apr 2020 04:50:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587617416; bh=vOtlaP1Y9u47LG2VL70vssjtpfll83QFol+d9quFANg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=dXLA7je24/55fF3q5YCk2WeIiGmN7fm2SPoFAQsJzp+r2rkt8whsN1BWDCvu8z+m4 ME1WSsVefSqJX6cWDy2Lwar/Rd9E0fK1EaF2DndiZ0QM9rDoHrUQGz71ywNnEInM84 8LjZNiv8/qaCqLdRUdhJ5g74tZ+Gft6Cjz46eB3A= To: Matt Corallo From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <4def6907-d380-c053-d361-5a7f12202b34@mattcorallo.com> References: <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com> <4def6907-d380-c053-d361-5a7f12202b34@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 04:50:36 -0000 Good morning lists et al, Let me try to summarize things a little: * Suppose we have a forwarding payment A->B->C. * Suppose B does not want to maintain a mempool and is running in `blockson= ly` mode to reduce operational costs. * C triggers B somehow dropping the B<->C channel, such as by sending an `e= rror` message, which will usually cause the other side to drop the channel = onchain 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 HTLC= , for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIF= Y`. * 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 cr= eating a large fee, low fee-rate (tree of) transactions. * As it is a low fee-rate, miners have no incentive to put this in a bloc= k, especially if unrelated higher-fee-rate transactions exist that would ea= rn them more money. * Even in a full RBF universe, because of the anti-DoS mempool rules, B c= annot evict this pinned transaction by just bidding up the feerate. * A replacing transaction cannot evict alternatives unless its absolute= fee is greater than the absolute fee of the alternative. * The pinning transaction has a high fee, but is blockspace-wasteful, s= o it 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 = transaction with an alternative that is much smaller and has a low fee, but= much better feerate. * Miners, being economically rational, accept this proposal and include t= his in a block. The proposal by Matt is then: * The hashlock branch should instead be: * B and C must agree, and show the preimage of some hash H (hashlock bran= ch). * Then B and C agree that B provides a signature spending the hashlock bran= ch, 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 queries the peer for this transaction, extracting the preimage and claimi= ng the A->B HTLC. Is that a fair summary? -- 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 unde= sirable transaction (tree) into the mempool: * Undesirable to mine (low fee-rate). * Difficult to evict (high fee). 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. The reason (as I understand it) eviction is purposely made difficult here i= s to prevent certain DoS attacks on Bitcoin nodes, specifically: 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 roo= t. 3. Attacker sends a slightly higher fee-rate alternative to the root, evict= ing the above tree of txes. 4. Attacker sends thousands of low fee-rate tx that build off the latest ro= ot. 5. GOTO 3. However, it seems to me, naively, that "an ounce of prevention is worth a p= ound of cure". As I understand it, the mempool is organized already into "packages" of tra= nsactions, 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 pack= ages 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. 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. As well, as I understand it, this merely tightens the mempool acceptance ru= les, 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-r= ate package is prevented from reaching a large size. Would that be workable as a general solution to solve (what I think is) the= root cause of this problem? (This assumes full RBF, I suppose.) Regards, ZmnSCPxj