rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2020-04-22 📝 Original message: > On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32 at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/428e7a28/attachment.html>