public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 12:50:46 -0400	[thread overview]
Message-ID: <10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com> (raw)
In-Reply-To: <CAO3Pvs-SbA+6b2c3Pg-ohvovVtTenx8ve1BZWGgCiLAcSZNNVw@mail.gmail.com>

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


  parent reply	other threads:[~2020-04-22 16:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  2:43 [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest 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 [this message]
2020-04-22 23:13     ` Olaoluwa Osuntokun
2020-04-22 23:20       ` Matt Corallo
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=10406f38-fc9d-ac0b-cfd2-0b507d8ec573@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=laolu32@gmail.com \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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