From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98197C1D7D; Wed, 22 Apr 2020 16:50:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 839741FDFB; Wed, 22 Apr 2020 16:50:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AiBkcMHUHsx; Wed, 22 Apr 2020 16:50:51 +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 silver.osuosl.org (Postfix) with ESMTPS id 1CED31FD16; Wed, 22 Apr 2020 16:50:51 +0000 (UTC) Received: from [IPv6:2620:6e:a007:233::100] (unknown [IPv6:2620:6e:a007:233::100]) by mail.as397444.net (Postfix) with ESMTPSA id 6CA9B2325D3; Wed, 22 Apr 2020 16:50:48 +0000 (UTC) To: Olaoluwa Osuntokun References: From: Matt Corallo Message-ID: <10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com> Date: Wed, 22 Apr 2020 12:50:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-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: Wed, 22 Apr 2020 16:50:52 -0000 A few replies inline. On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: > Hi Matt, > > >> While this is somewhat unintuitive, there are any number of good anti-DoS >> reasons for this, eg: > > None of these really strikes me as "good" reasons for this limitation, which > is at the root of this issue, and will also plague any more complex Bitcoin > contracts which rely on nested trees of transaction to confirm (CTV, Duplex, > channel factories, etc). Regarding the various (seemingly arbitrary) package > limits it's likely the case that any issues w.r.t computational complexity > that may arise when trying to calculate evictions can be ameliorated with > better choice of internal data structures. > > In the end, the simplest heuristic (accept the higher fee rate package) side > steps all these issues and is also the most economically rationale from a > miner's perspective. Why would one prefer a higher absolute fee package > (which could be very large) over another package with a higher total _fee > rate_? This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to start with a concrete suggestion here :). >> You'll note that B would be just fine if they had a way to safely monitor the >> global mempool, and while this seems like a prudent mitigation for >> lightning implementations to deploy today, it is itself a quagmire of >> complexity > > Is it really all that complex? Assuming we're talking about just watching > for a certain script template (the HTLC scipt) in the mempool to be able to > pull a pre-image as soon as possible. Early versions of lnd used the mempool > for commitment broadcast detection (which turned out to be a bad idea so we > removed it), but at a glance I don't see why watching the mempool is so > complex. Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack. >> Further, this is a really obnoxious assumption to hoist onto lightning >> nodes - having an active full node with an in-sync mempool is a lot more >> CPU, bandwidth, and complexity than most lightning users were expecting to >> face. > > This would only be a requirement for Lightning nodes that seek to be a part > of the public routing network with a desire to _forward_ HTLCs. This isn't > doesn't affect laptops or mobile phones which likely mostly have private > channels and don't participate in HTLC forwarding. I think it's pretty > reasonable to expect a "proper" routing node on the network to be backed by > a full-node. The bandwidth concern is valid, but we'd need concrete numbers > that compare the bandwidth over head of mempool awareness (assuming the > latest and greatest mempool syncing) compared with the overhead of the > channel update gossip and gossip queries over head which LN nodes face today > as is to see how much worse off they really would be. If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing partially-offline local lightning hubs which would be rendered impractical. > As detailed a bit below, if nodes watch the mempool, then this class of > attack assuming the anchor output format as described in the open > lightning-rfc PR is mitigated. At a glance, watching the mempool seems like > a far less involved process compared to modifying the state machine as its > defined today. By watching the mempool and implementing the changes in > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 > doesn't yet watch the mempool (but does include anchors [1]), but unless I'm > missing something it should be pretty straight forward to add which mor or less > resolves this issue all together. > >> not fixing this issue seems to render the whole exercise somewhat useless > > Depends on if one considers watching the mempool a fix. But even with that a > base version of anchors still resolves a number of issues including: > eliminating the commitment fee guessing game, allowing users to pay less on > force close, being able to coalesce 2nd level HTLC transactions with the > same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC > resolution. > >> Instead of making the HTLC output spending more free-form with >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other >> direction - all HTLC output spends need to be pre-signed. > > I'm not sure this is actually immediately workable (need to think about it > more). To see why, remember that the commit_sig message includes HTLC > signatures for the _remote_ party's commitment transaction, so they can > spend the HTLCs if they broadcast their version of the commitment (force > close). If we don't somehow also _gain_ signatures (our new HTLC signatures) > allowing us to spend HTLCs on _their_ version of the commitment, then if > they broadcast that commitment (without revoking), then we're unable to > redeem any of those HTLCs at all, possibly losing money. Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but instead to CPFP a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You only need to know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do this, you don't have to actually *have* the fully-signed transaction (and you don't). > In an attempt to counteract this, we might say ok, the revoke message also > now includes HTLC signatures for their new commitment allowing us to spend > our HTLCs. This resolves things in a weaker security model, but doesn't > address the issue generally, as after they receive the commit_sig, they can > broadcast immediately, again leaving us without a way to redeem our HTLCs. > > I'd need to think about it more, but it seems that following this path would > require an overhaul in the channel state machine to make presenting a new > commitment actually take at least _two phases_ (at least a full round trip). > The first phase would tender the commitment, but render them unable to > broadcast it. The second phase would then scriptless scripts here> enter a new sub-protocol which upon conclusion, > gives the commitment proposer valid HTLC signatures, and gives the responder > what they need to be able to broadcast their commitment and claim their > HTCLs in an atomic manner. > > -- Laolu > > [1]: https://github.com/lightningnetwork/lnd/pull/3821