From: Matt Corallo <lf-lists@mattcorallo•com>
To: Olaoluwa Osuntokun <laolu32@gmail•com>
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
Date: Wed, 22 Apr 2020 16:20:03 -0700 [thread overview]
Message-ID: <9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com> (raw)
In-Reply-To: <CAO3Pvs8Dx8ATXfQRA3p7DzzHcYZz1nF4g=+ZHvSukL0jMbxAOw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8813 bytes --]
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32@gmail•com> 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 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.
Indeed, that is what I’m suggesting. Anchor output and all. One thing we could think about is only turning it on over a certain threshold, and having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” 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 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 please re-read the intro email. There are a bunch of ways of doing pinning - just opting into RBF isn’t even close to enough.
> [1]: https://github.com/bitcoin/bitcoin/pull/18191
>
>
>> 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 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 <insert something something
>> > 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
[-- Attachment #2: Type: text/html, Size: 10180 bytes --]
next prev parent reply other threads:[~2020-04-22 23:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 2:43 Matt Corallo
2020-04-22 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-04-22 4:18 ` Olaoluwa Osuntokun
2020-04-22 6:08 ` ZmnSCPxj
2020-04-22 8:01 ` Antoine Riard
2020-04-22 8:55 ` Bastien TEINTURIER
2020-04-22 23:05 ` Olaoluwa Osuntokun
2020-04-22 23:11 ` Olaoluwa Osuntokun
2020-04-22 16:56 ` Matt Corallo
2020-04-22 4:13 ` [bitcoin-dev] " Olaoluwa Osuntokun
2020-04-22 11:51 ` David A. Harding
2020-04-27 21:26 ` Rusty Russell
2020-04-22 16:50 ` Matt Corallo
2020-04-22 23:13 ` Olaoluwa Osuntokun
2020-04-22 23:20 ` Matt Corallo [this message]
2020-04-22 23:27 ` Olaoluwa Osuntokun
2020-04-23 1:10 ` Matt Corallo
2020-04-23 4:50 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-04-23 6:21 ` Matt Corallo
2020-04-23 12:46 ` ZmnSCPxj
2020-04-23 22:47 ` Matt Corallo
2020-06-19 7:44 ` Bastien TEINTURIER
2020-06-19 19:58 ` David A. Harding
2020-06-19 20:52 ` David A. Harding
2020-06-20 8:54 ` Bastien TEINTURIER
2020-06-20 10:36 ` David A. Harding
2020-06-20 16:01 ` ZmnSCPxj
2020-06-21 2:10 ` ZmnSCPxj
2020-06-22 7:35 ` Bastien TEINTURIER
2020-06-22 8:15 ` ZmnSCPxj
2020-06-22 8:25 ` Bastien TEINTURIER
2020-06-24 8:32 ` Matt Corallo
2020-04-23 1:18 ` [bitcoin-dev] " Jeremy
2020-04-22 18:24 ` David A. Harding
2020-04-22 19:03 ` Antoine Riard
2020-04-22 20:28 ` David A. Harding
2020-04-22 22:53 Matt Corallo
2020-04-23 9:59 ` David A. Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9F7F7A00-FFA5-48E8-9BA3-8D71A55B2659@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox