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 D1EB9C0175; Wed, 22 Apr 2020 23:13:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id C072186B11; Wed, 22 Apr 2020 23:13:23 +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 gHGstaMtjS_J; Wed, 22 Apr 2020 23:13:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 082E186B04; Wed, 22 Apr 2020 23:13:22 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id o10so3325586qtr.6; Wed, 22 Apr 2020 16:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WnxhXZVA6i2g4hzIatdy1ctAiA1i8w2id3StzX4XwWI=; b=Ex8ogS5NDLOZ8/0gpH04Z0SZ4qluVF0QKDLijwQOQiGQH+k/3ve4H23rUbd/zruW1V io5LNayJh0D7hoDNJwocN9etwuWU4xIfpvQe9Qbhf2cV0o8nbEnyzYwugOEdehVvE0HY xfw1hCMAYmsWyXnzeEd1VZff69VFvl5A0hCMzDdBBdzZ4RWQE/dhQU3c7xAwVMpqHhV7 tU8Ujd9hAaSIYXhMQsDOFux6+199kqeOmo4N+FWMBIqP0lINFpb788rf32jdS/71YiP4 NBQ7eatvLax8QfXNG90LMj2csBwRX/j6vuSHiQ8uUHcsw8PzMYRd3R+TLnV6MNxaVOOA D8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WnxhXZVA6i2g4hzIatdy1ctAiA1i8w2id3StzX4XwWI=; b=gbRL4w4A2j6DOBdiZ91tETtW4qC9FmN8EuHma7LJMgKXUjMZamkvd9DUOlHavVDh6O h/DZ4Wv2Hx2CrEW/C+CtUT3NtQ2X8EMnvziU8IDWq1D7arMda73UvxZD578yHCpy/uzk 338KnIAZwazwyF/E7Wp2fn8DQLUUkvjsvFrDmcjbGj9yS6h5lVYjkVXGAn8xDndxUffd dIU2kcgyToPVdiMEOdTRFW+JNhRyKWZeVkZz+3s9AIaaP0YbRfu2lSSTQdPclhNVWLLU ZZWZVby6scM2W/fRdqZUoGSfdC8fG0hytoKIGZHwgC72VtLsLuCDaNI9ZlY48vNgwXtQ lPjg== X-Gm-Message-State: AGi0PuZ5d/uJmgoTztwcwctLTD5imJrgT2Cr+Nw+YOCN3CVun1/jvhGk SpDW9cg5d4MVIzSIC3CoO8+7Asuo7lcBI95rR8k= X-Google-Smtp-Source: APiQypKmOxnbctUd3VWLzhJVys/ZmvIJO5mO27FzSDQgWyixujEif/j4v3eaVVwZ3dNEiCfS55yLmb4rIZlHOaLmYvc= X-Received: by 2002:ac8:6e8c:: with SMTP id c12mr1197269qtv.374.1587597200944; Wed, 22 Apr 2020 16:13:20 -0700 (PDT) MIME-Version: 1.0 References: <10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com> In-Reply-To: <10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com> From: Olaoluwa Osuntokun Date: Wed, 22 Apr 2020 16:13:01 -0700 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="00000000000035720105a3e947ea" 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 23:13:24 -0000 --00000000000035720105a3e947ea Content-Type: text/plain; charset="UTF-8" > 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 :). This wasn't intended as an insult at all. I'm simply saying if there's concern about worst case eviction/replacement, optimizations likely exist. Other developers that are interested in more complex multi-transaction contracts have realized this as well, and there're various open PRs that attempt to propose such optimizations [1]. > 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 Sorry I still don't follow. By "we clearly need to go the other direction - all HTLC output spends need to be pre-signed.", you don't mean that the HTLC spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig covenant? If the other party isn't restricted w.r.t _how_ they can spend the output (non-rbf'd, ect), then I don't see how that addresses anything. Also see my mail elsewhere in the thread that the other party is actually forced to spend their HTLC output using an RBF-replaceable transaction. With that, I think we're all good here? In the end both sides have the ability to raise the fee rate of their spending transactions with the highest winning. As long as one of them confirms within the CLTV-delta, then everyone is made whole. [1]: https://github.com/bitcoin/bitcoin/pull/18191 On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo wrote: > 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 > --00000000000035720105a3e947ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This seems like a somewhat unnecessary drive-by insul= t of a project you
> don't contribute to, but feel free to start = with a concrete suggestion
> here :).

This wasn't intended= as an insult at all. I'm simply saying if there's
concern about= worst case eviction/replacement, optimizations likely exist.
Other deve= lopers that are interested in more complex multi-transaction
contracts h= ave realized this as well, and there're various open PRs that
attemp= t to propose such optimizations [1].

> Hmm, maybe the proposal wa= sn'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
> accept= ed

Sorry I still don't follow. By "we clearly need to go th= e other direction -
all HTLC output spends need to be pre-signed.",= you don't mean that the HTLC
spends of the non-broadcaster also nee= d to be an off-chain 2-of-2 multi-sig
covenant? If the other party isn&#= 39;t restricted w.r.t _how_ they can spend the
output (non-rbf'd, ec= t), then I don't see how that addresses anything.

Also see my ma= il elsewhere in the thread that the other party is actually
forced to sp= end their HTLC output using an RBF-replaceable transaction. With
that, I= think we're all good here? In the end both sides have the ability toraise the fee rate of their spending transactions with the highest winnin= g.
As long as one of them confirms within the CLTV-delta, then everyone = is
made whole.


[1]: https://github.com/bitcoin/bitcoin/pull/18191

<= /div>
O= n Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists@mattcorallo.com> wrote:
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 a= nti-DoS
>> reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this l= imitation, which
> is at the root of this issue, and will also plague any more complex Bi= tcoin
> contracts which rely on nested trees of transaction to confirm (CTV, D= uplex,
> channel factories, etc). Regarding the various (seemingly arbitrary) p= ackage
> limits it's likely the case that any issues w.r.t computational co= mplexity
> that may arise when trying to calculate evictions can be ameliorated w= ith
> 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 fro= m a
> miner's perspective. Why would one prefer a higher absolute fee pa= ckage
> (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 saf= ely 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 w= atching
> for a certain script template (the HTLC scipt) in the mempool to be ab= le to
> pull a pre-image as soon as possible. Early versions of lnd used the m= empool
> 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 upg= rade 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 light= ning
>> nodes - having an active full node with an in-sync mempool is a lo= t more
>> CPU, bandwidth, and complexity than most lightning users were expe= cting 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 i= sn't
> doesn't affect laptops or mobile phones which likely mostly have p= rivate
> 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 concret= e numbers
> that compare the bandwidth over head of mempool awareness (assuming th= e
> 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 fol= ks 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 o= f
> 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 mo= r 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 le= ss on
> force close, being able to coalesce 2nd level HTLC transactions with t= he
> same CLTV expiry, and actually being able to reliably enforce multi-ho= p HTLC
> resolution.
>
>> Instead of making the HTLC output spending more free-form with
>> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the ot= her
>> 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<= br> > signatures for the _remote_ party's commitment transaction, so the= y can
> spend the HTLCs if they broadcast their version of the commitment (for= ce
> close). If we don't somehow also _gain_ signatures (our new HTLC s= ignatures)
> allowing us to spend HTLCs on _their_ version of the commitment, then = if
> they broadcast that commitment (without revoking), then we're unab= le to
> redeem any of those HTLCs at all, possibly losing money.

Hmm, maybe the proposal wasn't clear. The idea isn't to add signatu= res to braodcasted transactions, but instead to CPFP
a maybe-broadcasted transaction by sending a transaction which spends it an= d seeing if it is accepted. You only need to
know the transaction's exact format (ie txid, which we do, since we sen= t 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 s= pend
> our HTLCs. This resolves things in a weaker security model, but doesn&= #39;t
> address the issue generally, as after they receive the commit_sig, the= y can
> broadcast immediately, again leaving us without a way to redeem our HT= LCs.
>
> 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 <insert something somethi= ng
> scriptless scripts here> enter a new sub-protocol which upon conclu= sion,
> gives the commitment proposer valid HTLC signatures, and gives the res= ponder
> what they need to be able to broadcast their commitment and claim thei= r
> HTCLs in an atomic manner.
>
> -- Laolu
>
> [1]: https://github.com/lightningnetwork/lnd/p= ull/3821
--00000000000035720105a3e947ea--