From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BDD9C0175; Wed, 22 Apr 2020 23:20:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6A5A4884DE; Wed, 22 Apr 2020 23:20:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2V3lOUzxnZI; Wed, 22 Apr 2020 23:20:06 +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 hemlock.osuosl.org (Postfix) with ESMTPS id A88CD884A9; Wed, 22 Apr 2020 23:20:06 +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 DE3A62331CE; Wed, 22 Apr 2020 23:20:04 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-6229AF91-4DAE-4C71-893F-AD85DA932CD4 Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Wed, 22 Apr 2020 16:20:03 -0700 Message-Id: <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com> References: In-Reply-To: To: Olaoluwa Osuntokun X-Mailer: iPhone Mail (17E262) 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:20:08 -0000 --Apple-Mail-6229AF91-4DAE-4C71-893F-AD85DA932CD4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote: >=20 > > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures t= o > > braodcasted transactions, but instead to CPFP a maybe-broadcasted > > transaction by sending a transaction which spends it and seeing if it is= > > accepted >=20 > 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 HT= LC > spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-si= g > covenant? If the other party isn't restricted w.r.t _how_ they can spend t= he > output (non-rbf'd, ect), then I don't see how that addresses anything. Indeed, that is what I=E2=80=99m suggesting. Anchor output and all. One thin= g we could think about is only turning it on over a certain threshold, and h= aving a separate =E2=80=9Conly-kinda-enforceable-on-chain-HTLC-in-flight=E2=80= =9D limit. > 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. Wi= th > that, I think we're all good here? In the end both sides have the ability t= o > 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. It does seem like my cached recollection of RBF opt-in was incorrect but ple= ase re-read the intro email. There are a bunch of ways of doing pinning - ju= st opting into RBF isn=E2=80=99t even close to enough. > [1]: https://github.com/bitcoin/bitcoin/pull/18191 >=20 >=20 >> On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo w= rote: >> A few replies inline. >>=20 >> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: >> > Hi Matt, >> >=20 >> >=20 >> >> While this is somewhat unintuitive, there are any number of good anti-= DoS >> >> reasons for this, eg: >> >=20 >> > None of these really strikes me as "good" reasons for this limitation, w= hich >> > is at the root of this issue, and will also plague any more complex Bit= coin >> > contracts which rely on nested trees of transaction to confirm (CTV, Du= plex, >> > channel factories, etc). Regarding the various (seemingly arbitrary) pa= ckage >> > limits it's likely the case that any issues w.r.t computational complex= ity >> > that may arise when trying to calculate evictions can be ameliorated wi= th >> > better choice of internal data structures. >> >=20 >> > 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 _f= ee >> > rate_? >>=20 >> This seems like a somewhat unnecessary drive-by insult of a project you d= on't contribute to, but feel free to start with >> a concrete suggestion here :). >>=20 >> >> You'll note that B would be just fine if they had a way to safely moni= tor the >> >> global mempool, and while this seems like a prudent mitigation for >> >> lightning implementations to deploy today, it is itself a quagmire of >> >> complexity >> >=20 >> > Is it really all that complex? Assuming we're talking about just watchi= ng >> > for a certain script template (the HTLC scipt) in the mempool to be abl= e to >> > pull a pre-image as soon as possible. Early versions of lnd used the me= mpool >> > for commitment broadcast detection (which turned out to be a bad idea s= o we >> > removed it), but at a glance I don't see why watching the mempool is so= >> > complex. >>=20 >> Because watching your own mempool is not guaranteed to work, and during u= pgrade cycles that include changes to the >> policy rules an attacker could exploit your upgraded/non-upgraded status t= o perform the same attack. >>=20 >> >> 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 mo= re >> >> CPU, bandwidth, and complexity than most lightning users were expectin= g to >> >> face. >> >=20 >> > This would only be a requirement for Lightning nodes that seek to be a p= art >> > of the public routing network with a desire to _forward_ HTLCs. This is= n't >> > doesn't affect laptops or mobile phones which likely mostly have privat= e >> > 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 backe= d by >> > a full-node. The bandwidth concern is valid, but we'd need concrete num= bers >> > 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 t= oday >> > as is to see how much worse off they really would be. >>=20 >> If mempool-watching were practical, maybe, though there are a number of f= olks who are talking about designing >> partially-offline local lightning hubs which would be rendered impractica= l. >>=20 >> > 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 l= ike >> > a far less involved process compared to modifying the state machine as i= ts >> > 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 unles= s I'm >> > missing something it should be pretty straight forward to add which mor= or less >> > resolves this issue all together. >> >=20 >> >> not fixing this issue seems to render the whole exercise somewhat usel= ess >> >=20 >> > Depends on if one considers watching the mempool a fix. But even with t= hat a >> > base version of anchors still resolves a number of issues including: >> > eliminating the commitment fee guessing game, allowing users to pay les= s on >> > force close, being able to coalesce 2nd level HTLC transactions with th= e >> > same CLTV expiry, and actually being able to reliably enforce multi-hop= HTLC >> > resolution. >> >=20 >> >> 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. >> >=20 >> > 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 (forc= e >> > close). If we don't somehow also _gain_ signatures (our new HTLC signat= ures) >> > allowing us to spend HTLCs on _their_ version of the commitment, then i= f >> > they broadcast that commitment (without revoking), then we're unable to= >> > redeem any of those HTLCs at all, possibly losing money. >>=20 >> 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 a= nd 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= ). >>=20 >> > In an attempt to counteract this, we might say ok, the revoke message a= lso >> > now includes HTLC signatures for their new commitment allowing us to sp= end >> > 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 HTL= Cs. >> >=20 >> > I'd need to think about it more, but it seems that following this path w= ould >> > require an overhaul in the channel state machine to make presenting a n= ew >> > commitment actually take at least _two phases_ (at least a full round t= rip). >> > 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 resp= onder >> > what they need to be able to broadcast their commitment and claim their= >> > HTCLs in an atomic manner. >> >=20 >> > -- Laolu >> >=20 >> > [1]: https://github.com/lightningnetwork/lnd/pull/3821 --Apple-Mail-6229AF91-4DAE-4C71-893F-AD85DA932CD4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun= <laolu32@gmail.com> wrote:

> Hmm, maybe the proposal was= n't clear. The idea isn't to add signatures to
> braodcasted transacti= ons, but instead to CPFP a maybe-broadcasted
> transaction by sending a= transaction which spends it and seeing if it is
> accepted

Sor= ry 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 sp= end the
output (non-rbf'd, ect), then I don't see how that addresses anyt= hing.

Indeed, that is what I= =E2=80=99m suggesting. Anchor output and all. One thing we could think about= is only turning it on over a certain threshold, and having a separate =E2=80= =9Conly-kinda-enforceable-on-chain-HTLC-in-flight=E2=80=9D limit.

<= blockquote type=3D"cite">
Also see my mail e= lsewhere in the thread that the other party is actually
forced to spend t= heir 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 lon= g as one of them confirms within the CLTV-delta, then everyone is
made wh= ole.

It does seem like my ca= ched recollection of RBF opt-in was incorrect but please re-read the intro e= mail. There are a bunch of ways of doing pinning - just opting into RBF isn=E2= =80=99t even close to enough.

On Wed, Ap= r 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 an= ti-DoS
>> reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this limitation, w= hich
> is at the root of this issue, and will also plague any more complex Bit= coin
> contracts which rely on nested trees of transaction to confirm (CTV, Du= plex,
> channel factories, etc). Regarding the various (seemingly arbitrary) pa= ckage
> limits it's likely the case that any issues w.r.t computational complex= ity
> that may arise when trying to calculate evictions can be ameliorated wi= th
> 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 _f= ee
> 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 m= onitor the
>> global mempool, and while this seems like a prudent mitigation for<= br> >> lightning implementations to deploy today, it is itself a quagmire o= f
>> complexity
>
> Is it really all that complex? Assuming we're talking about just watchi= ng
> for a certain script template (the HTLC scipt) in the mempool to be abl= e to
> pull a pre-image as soon as possible. Early versions of lnd used the me= mpool
> for commitment broadcast detection (which turned out to be a bad idea s= o 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 upgr= ade cycles that include changes to the
policy rules an attacker could exploit your upgraded/non-upgraded status to p= erform the same attack.

>> Further, this is a really obnoxious assumption to hoist onto lightn= ing
>> nodes - having an active full node with an in-sync mempool is a lot= more
>> CPU, bandwidth, and complexity than most lightning users were expec= ting to
>> face.
>
> This would only be a requirement for Lightning nodes that seek to be a p= art
> of the public routing network with a desire to _forward_ HTLCs. This is= n't
> doesn't affect laptops or mobile phones which likely mostly have privat= e
> channels and don't participate in HTLC forwarding. I think it's pretty<= br> > reasonable to expect a "proper" routing node on the network to be backe= d by
> a full-node. The bandwidth concern is valid, but we'd need concrete num= bers
> that compare the bandwidth over head of mempool awareness (assuming the=
> latest and greatest mempool syncing) compared with the overhead of the<= br> > channel update gossip and gossip queries over head which LN nodes face t= oday
> as is to see how much worse off they really would be.

If mempool-watching were practical, maybe, though there are a number of folk= s who are talking about designing
partially-offline local lightning hubs which would be rendered impractical.<= br>
> 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 l= ike
> a far less involved process compared to modifying the state machine as i= ts
> defined today. By watching the mempool and implementing the changes in<= br> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10<= br> > doesn't yet watch the mempool (but does include anchors [1]), but unles= s 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 u= seless
>
> Depends on if one considers watching the mempool a fix. But even with t= hat a
> base version of anchors still resolves a number of issues including: > eliminating the commitment fee guessing game, allowing users to pay les= s on
> force close, being able to coalesce 2nd level HTLC transactions with th= e
> 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 oth= er
>> 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 (forc= e
> close). If we don't somehow also _gain_ signatures (our new HTLC signat= ures)
> allowing us to spend HTLCs on _their_ version of the commitment, then i= f
> 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 br= aodcasted 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 s= ignature for it long ago) to do this, you
don't have to actually *have* the fully-signed transaction (and you don't).<= br>
> In an attempt to counteract this, we might say ok, the revoke message a= lso
> now includes HTLC signatures for their new commitment allowing us to sp= end
> 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 HTL= Cs.
>
> I'd need to think about it more, but it seems that following this path w= ould
> require an overhaul in the channel state machine to make presenting a n= ew
> commitment actually take at least _two phases_ (at least a full round t= rip).
> The first phase would tender the commitment, but render them unable to<= br> > broadcast it. The second phase would then <insert something somethin= g
> scriptless scripts here> enter a new sub-protocol which upon conclus= ion,
> gives the commitment proposer valid HTLC signatures, and gives the resp= onder
> 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
= --Apple-Mail-6229AF91-4DAE-4C71-893F-AD85DA932CD4--