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 91165C0175; Wed, 22 Apr 2020 23:28:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 7CBB186B04; Wed, 22 Apr 2020 23:28:11 +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 jD5F9QrHsiV7; Wed, 22 Apr 2020 23:28:09 +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-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 9D341868C5; Wed, 22 Apr 2020 23:28:09 +0000 (UTC) Received: by mail-qk1-f173.google.com with SMTP id t3so4513163qkg.1; Wed, 22 Apr 2020 16:28:09 -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=kG0r6W3xsOTeepQNsI052Rm2d52jnHO7frmRw+AFDuk=; b=NMOx2O1Hu6W392cXQD92B9xdJGUArH8LtNBWrSKwieYANTXfrC7XG8ZpdrCtuHVWwu AXKSjTY3tc+N7AuN0UjF+/lpVG3aBMZ6haQXGS6JekfckvC4lFSTlaJdf2i5nQcJm1f3 UmfAUw9EZoK3WMx0c9sXpQ0AYayhJWlUhC9cXaw1331FoxBaVz5SeoTypQT5XDenYYWC QVp6xxbKk/un7s7Wjz5HbyaHgSxcujk7qoUTeFdbZzedjm5HVtPm8xj5HX7lXdHxb0SB ntaN5tLc2XhO77/z97GawPZG1AP4/VTLMJ1sNoxYA2+vA2wNRwN9xvtjHIpZnBGFmnHh Onpg== 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=kG0r6W3xsOTeepQNsI052Rm2d52jnHO7frmRw+AFDuk=; b=dllQlk6yvC6yHHAkAYtbuMWiFuTIYLWS5pj/kKJJPoZq58FXj+ZheT4fQmTW2LrGFH 7Xtd1/SQSJIHtXEPkYHS5d1N3aujRffTLM/gtwsPOcjkNBvYKmvi/8G1GbBzde6GSMhP evSOnqCko5S5N6wqjGNLC2EivJiyybMyndu/j6mkQcOozsM8kF8G328qyeffUlcNDiUG Kk8IJPfol5xA+5T2z9w9NUr7jLyrqPKCoAIjvm6W0DF15BCj4ZnTuFc2sb5PxQ4Bl3+n q1WxTcNO1AYbeESdYOkgQ8666NzHAihtyWdlcF2lINqOKmCHA2NtSeGgukmhkj7vknkY vMjA== X-Gm-Message-State: AGi0PuYDSiEGLLUVzECrVC1bYVn8X7R6L35MIytP4N6y72Ouefw4455s aQFk92imtaUwKdWmQck3PrRIwfWhK1r8Yh/3Hwc= X-Google-Smtp-Source: APiQypKoHENAri6v/oo+vskm5uPFZ5h1Qt86BdrbAuUbBi1kfYnZOx7inig3HEZ+coyVEltSunkM5NqSHim6Uf+8ZIY= X-Received: by 2002:a37:b3c1:: with SMTP id c184mr843544qkf.194.1587598088467; Wed, 22 Apr 2020 16:28:08 -0700 (PDT) MIME-Version: 1.0 References: <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com> In-Reply-To: <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com> From: Olaoluwa Osuntokun Date: Wed, 22 Apr 2020 16:27:49 -0700 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="0000000000001bf94a05a3e97c32" 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:28:11 -0000 --0000000000001bf94a05a3e97c32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Indeed, that is what I=E2=80=99m suggesting Gotcha, if this is indeed what you're suggesting (all HTLC spends are now 2-of-2 multi-sig), then I think the modifications to the state machine I sketched out in an earlier email are required. An exact construction which achieves the requirements of "you can't broadcast until you have a secret which I can obtain from the htlc sig for your commitment transaction, and m= y secret is revealed with another swap", appears to be an open problem, atm. Even if they're restricted in this fashion (must be a 1-in-1 out, sighashall, fees are pre agreed upon), they can still spend that with a CPF= P (while still unconfirmed in the mempool) and create another heavy tree, which puts us right back at the same bidding war scenario? > There are a bunch of ways of doing pinning - just opting into RBF isn=E2= =80=99t > even close to enough. Mhmm, there're other ways of doing pinning. But with anchors as is defined in that spec PR, they're forced to spend with an RBF-replaceable transaction, which means the party wishing to time things out can enter int= o a bidding war. If the party trying to impeded things participates in this progressive absolute fee increase, it's likely that the war terminates with _one_ of them getting into the block, which seems to resolve everything? -- Laolu On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo wrote: > > > On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote: > > > > 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 i= s > > 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-s= ig > 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. > > > Indeed, that is what I=E2=80=99m suggesting. Anchor output and all. One t= hing 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. > > 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 winnin= g. > 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 > please re-read the intro email. There are a bunch of ways of doing pinnin= g > - just opting into RBF isn=E2=80=99t even close to enough. > > [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 fro= m >> a >> > miner's perspective. Why would one prefer a higher absolute fee packag= e >> > (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 s= o >> > 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 lightnin= g >> >> 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 priva= te >> > 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 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 >> 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 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 >> less 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 other >> >> direction - all HTLC output spends need to be pre-signed. >> > >> > I'm not sure this is actually immediately workable (need to think abou= t >> it >> > more). To see why, remember that the commit_sig message includes HTLC >> > signatures for the _remote_ party's commitment transaction, so they ca= n >> > 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 >> signatures) >> > allowing us to spend HTLCs on _their_ version of the commitment, then = if >> > they broadcast that commitment (without revoking), then we're unable t= o >> > redeem any of those HTLCs at all, possibly losing money. >> >> 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. 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, the= y >> 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 conclusio= n, >> > gives the commitment proposer valid HTLC signatures, and gives the >> responder >> > 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/pull/3821 >> > --0000000000001bf94a05a3e97c32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Indeed, th= at is what I=E2=80=99m suggesting

Gotcha, if this is indeed what you= 're suggesting (all HTLC spends are now
2-of-2 multi-sig), then I th= ink the modifications to the state machine I
sketched out in an earlier = email are required. An exact construction which
achieves the requirement= s of "you can't broadcast until you have a secret
which I can o= btain from the htlc sig for your commitment transaction, and my
secret i= s revealed with another swap", appears to be an open problem, atm.
=
Even if they're restricted in this fashion (must be a 1-in-1 out,sighashall, fees are pre agreed upon), they can still spend that with a C= PFP
(while still unconfirmed in the mempool) and create another heavy tr= ee,
which puts us right back at the same bidding war scenario?

&g= t; There are a bunch of ways of doing pinning - just opting into RBF isn=E2= =80=99t
> even close to enough.

Mhmm, there're other ways = of doing pinning. But with anchors as is defined
in that spec PR, they&#= 39;re forced to spend with an RBF-replaceable
transaction, which means t= he party wishing to time things out can enter into
a bidding war. If the= party trying to impeded things participates in this
progressive absolut= e fee increase, it's likely that the war terminates
with _one_ of th= em getting into the block, which seems to resolve
everything?

-- = Laolu


On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo= <lf-lists@mattcorallo.com> wrote:


> Hmm, maybe the proposal wasn't clear. The idea isn&#= 39;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= 9;t follow. By "we clearly need to go the other direction -
all HTL= C output spends need to be pre-signed.", you don't mean that the H= TLC
spends of the non-broadcaster also need to be an off-chain 2-of-2 mu= lti-sig
covenant? If the other party isn't restricted w.r.t _how_ th= ey can spend the
output (non-rbf'd, ect), then I don't see how t= hat addresses anything.

Ind= eed, 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 ha= ving 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 a= ctually
forced to spend their HTLC output using an RBF-replaceable trans= action. With
that, I think we're all good here? In the end both side= s 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 CLT= V-delta, then everyone is
made whole.
<= br>
It does seem like my cached recollection of RBF opt-in was in= correct but please re-read the intro email. There are a bunch of ways of do= ing pinning - just opting into RBF isn=E2=80=99t even close to enough.

On 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
--0000000000001bf94a05a3e97c32--