path: root/5e/4e073047f51d2a7481bfdcee6dd8d13d1befe6

Return-Path: <lf-lists@mattcorallo.com>
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 <lf-lists@mattcorallo.com>
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: <CAO3Pvs8Dx8ATXfQRA3p7DzzHcYZz1nF4g=+ZHvSukL0jMbxAOw@mail.gmail.com>
In-Reply-To: <CAO3Pvs8Dx8ATXfQRA3p7DzzHcYZz1nF4g=+ZHvSukL0jMbxAOw@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
X-Mailer: iPhone Mail (17E262)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <laolu32@gmail.com> 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 <lf-lists@mattcorallo.com> 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 <insert something something
>> > 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
><br><blockquote type=3D"cite">On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun=
 &lt;laolu32@gmail.com&gt; wrote:<br></blockquote></div><blockquote type=3D"=
cite"><div dir=3D"ltr"><div dir=3D"ltr"><br>&gt; Hmm, maybe the proposal was=
n't clear. The idea isn't to add signatures to<br>&gt; braodcasted transacti=
ons, but instead to CPFP a maybe-broadcasted<br>&gt; transaction by sending a=
 transaction which spends it and seeing if it is<br>&gt; accepted<br><br>Sor=
ry I still don't follow. By "we clearly need to go the other direction -<br>=
all HTLC output spends need to be pre-signed.", you don't mean that the HTLC=
<br>spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-=
sig<br>covenant? If the other party isn't restricted w.r.t _how_ they can sp=
end the<br>output (non-rbf'd, ect), then I don't see how that addresses anyt=
hing.<br></div></div></blockquote><div><br></div><div>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.</div><br><=
blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr">Also see my mail e=
lsewhere in the thread that the other party is actually<br>forced to spend t=
heir HTLC output using an RBF-replaceable transaction. With<br>that, I think=
 we're all good here? In the end both sides have the ability to<br>raise the=
 fee rate of their spending transactions with the highest winning.<br>As lon=
g as one of them confirms within the CLTV-delta, then everyone is<br>made wh=
ole.<br></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div dir=3D"ltr">[1]: <a href=3D"https://github.com/bitcoin/bitcoin/pu=
ll/18191">https://github.com/bitcoin/bitcoin/pull/18191</a><br><br></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Ap=
r 22, 2020 at 9:50 AM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorall=
o.com">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">A few replies inline.<br>
<br>
On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:<br>
&gt; Hi Matt,<br>
&gt; <br>
&gt; <br>
&gt;&gt; While this is somewhat unintuitive, there are any number of good an=
ti-DoS<br>
&gt;&gt; reasons for this, eg:<br>
&gt; <br>
&gt; None of these really strikes me as "good" reasons for this limitation, w=
hich<br>
&gt; is at the root of this issue, and will also plague any more complex Bit=
coin<br>
&gt; contracts which rely on nested trees of transaction to confirm (CTV, Du=
plex,<br>
&gt; channel factories, etc). Regarding the various (seemingly arbitrary) pa=
ckage<br>
&gt; limits it's likely the case that any issues w.r.t computational complex=
ity<br>
&gt; that may arise when trying to calculate evictions can be ameliorated wi=
th<br>
&gt; better choice of internal data structures.<br>
&gt; <br>
&gt; In the end, the simplest heuristic (accept the higher fee rate package)=
 side<br>
&gt; steps all these issues and is also the most economically rationale from=
 a<br>
&gt; miner's perspective. Why would one prefer a higher absolute fee package=
<br>
&gt; (which could be very large) over another package with a higher total _f=
ee<br>
&gt; rate_?<br>
<br>
This seems like a somewhat unnecessary drive-by insult of a project you don'=
t contribute to, but feel free to start with<br>
a concrete suggestion here :).<br>
<br>
&gt;&gt; You'll note that B would be just fine if they had a way to safely m=
onitor the<br>
&gt;&gt; global mempool, and while this seems like a prudent mitigation for<=
br>
&gt;&gt; lightning implementations to deploy today, it is itself a quagmire o=
f<br>
&gt;&gt; complexity<br>
&gt; <br>
&gt; Is it really all that complex? Assuming we're talking about just watchi=
ng<br>
&gt; for a certain script template (the HTLC scipt) in the mempool to be abl=
e to<br>
&gt; pull a pre-image as soon as possible. Early versions of lnd used the me=
mpool<br>
&gt; for commitment broadcast detection (which turned out to be a bad idea s=
o we<br>
&gt; removed it), but at a glance I don't see why watching the mempool is so=
<br>
&gt; complex.<br>
<br>
Because watching your own mempool is not guaranteed to work, and during upgr=
ade cycles that include changes to the<br>
policy rules an attacker could exploit your upgraded/non-upgraded status to p=
erform the same attack.<br>
<br>
&gt;&gt; Further, this is a really obnoxious assumption to hoist onto lightn=
ing<br>
&gt;&gt; nodes - having an active full node with an in-sync mempool is a lot=
 more<br>
&gt;&gt; CPU, bandwidth, and complexity than most lightning users were expec=
ting to<br>
&gt;&gt; face.<br>
&gt; <br>
&gt; This would only be a requirement for Lightning nodes that seek to be a p=
art<br>
&gt; of the public routing network with a desire to _forward_ HTLCs. This is=
n't<br>
&gt; doesn't affect laptops or mobile phones which likely mostly have privat=
e<br>
&gt; channels and don't participate in HTLC forwarding. I think it's pretty<=
br>
&gt; reasonable to expect a "proper" routing node on the network to be backe=
d by<br>
&gt; a full-node. The bandwidth concern is valid, but we'd need concrete num=
bers<br>
&gt; that compare the bandwidth over head of mempool awareness (assuming the=
<br>
&gt; latest and greatest mempool syncing) compared with the overhead of the<=
br>
&gt; channel update gossip and gossip queries over head which LN nodes face t=
oday<br>
&gt; as is to see how much worse off they really would be.<br>
<br>
If mempool-watching were practical, maybe, though there are a number of folk=
s who are talking about designing<br>
partially-offline local lightning hubs which would be rendered impractical.<=
br>
<br>
&gt; As detailed a bit below, if nodes watch the mempool, then this class of=
<br>
&gt; attack assuming the anchor output format as described in the open<br>
&gt; lightning-rfc PR is mitigated. At a glance, watching the mempool seems l=
ike<br>
&gt; a far less involved process compared to modifying the state machine as i=
ts<br>
&gt; defined today. By watching the mempool and implementing the changes in<=
br>
&gt; #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10<=
br>
&gt; doesn't yet watch the mempool (but does include anchors [1]), but unles=
s I'm<br>
&gt; missing something it should be pretty straight forward to add which mor=
 or less<br>
&gt; resolves this issue all together.<br>
&gt; <br>
&gt;&gt; not fixing this issue seems to render the whole exercise somewhat u=
seless<br>
&gt; <br>
&gt; Depends on if one considers watching the mempool a fix. But even with t=
hat a<br>
&gt; base version of anchors still resolves a number of issues including:<br=
>
&gt; eliminating the commitment fee guessing game, allowing users to pay les=
s on<br>
&gt; force close, being able to coalesce 2nd level HTLC transactions with th=
e<br>
&gt; same CLTV expiry, and actually being able to reliably enforce multi-hop=
 HTLC<br>
&gt; resolution.<br>
&gt; <br>
&gt;&gt; Instead of making the HTLC output spending more free-form with<br>
&gt;&gt; SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the oth=
er<br>
&gt;&gt; direction - all HTLC output spends need to be pre-signed.<br>
&gt; <br>
&gt; I'm not sure this is actually immediately workable (need to think about=
 it<br>
&gt; more). To see why, remember that the commit_sig message includes HTLC<b=
r>
&gt; signatures for the _remote_ party's commitment transaction, so they can=
<br>
&gt; spend the HTLCs if they broadcast their version of the commitment (forc=
e<br>
&gt; close). If we don't somehow also _gain_ signatures (our new HTLC signat=
ures)<br>
&gt; allowing us to spend HTLCs on _their_ version of the commitment, then i=
f<br>
&gt; they broadcast that commitment (without revoking), then we're unable to=
<br>
&gt; redeem any of those HTLCs at all, possibly losing money.<br>
<br>
Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to br=
aodcasted transactions, but instead to CPFP<br>
a maybe-broadcasted transaction by sending a transaction which spends it and=
 seeing if it is accepted. You only need to<br>
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<br>
don't have to actually *have* the fully-signed transaction (and you don't).<=
br>
<br>
&gt; In an attempt to counteract this, we might say ok, the revoke message a=
lso<br>
&gt; now includes HTLC signatures for their new commitment allowing us to sp=
end<br>
&gt; our HTLCs. This resolves things in a weaker security model, but doesn't=
<br>
&gt; address the issue generally, as after they receive the commit_sig, they=
 can<br>
&gt; broadcast immediately, again leaving us without a way to redeem our HTL=
Cs.<br>
&gt; <br>
&gt; I'd need to think about it more, but it seems that following this path w=
ould<br>
&gt; require an overhaul in the channel state machine to make presenting a n=
ew<br>
&gt; commitment actually take at least _two phases_ (at least a full round t=
rip).<br>
&gt; The first phase would tender the commitment, but render them unable to<=
br>
&gt; broadcast it. The second phase would then &lt;insert something somethin=
g<br>
&gt; scriptless scripts here&gt; enter a new sub-protocol which upon conclus=
ion,<br>
&gt; gives the commitment proposer valid HTLC signatures, and gives the resp=
onder<br>
&gt; what they need to be able to broadcast their commitment and claim their=
<br>
&gt; HTCLs in an atomic manner.<br>
&gt; <br>
&gt; -- Laolu<br>
&gt; <br>
&gt; [1]: <a href=3D"https://github.com/lightningnetwork/lnd/pull/3821" rel=3D=
"noreferrer" target=3D"_blank">https://github.com/lightningnetwork/lnd/pull/=
3821</a><br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-6229AF91-4DAE-4C71-893F-AD85DA932CD4--