{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-04-22\n📝 Original message:\nHi Matt,\n\n\n\u003e While this is somewhat unintuitive, there are any number of good anti-DoS\n\u003e reasons for this, eg:\n\nNone of these really strikes me as \"good\" reasons for this limitation, which\nis at the root of this issue, and will also plague any more complex Bitcoin\ncontracts which rely on nested trees of transaction to confirm (CTV, Duplex,\nchannel factories, etc). Regarding the various (seemingly arbitrary) package\nlimits it's likely the case that any issues w.r.t computational complexity\nthat may arise when trying to calculate evictions can be ameliorated with\nbetter choice of internal data structures.\n\nIn the end, the simplest heuristic (accept the higher fee rate package) side\nsteps all these issues and is also the most economically rationale from a\nminer's perspective. Why would one prefer a higher absolute fee package\n(which could be very large) over another package with a higher total _fee\nrate_?\n\n\u003e You'll note that B would be just fine if they had a way to safely monitor\nthe\n\u003e global mempool, and while this seems like a prudent mitigation for\n\u003e lightning implementations to deploy today, it is itself a quagmire of\n\u003e complexity\n\nIs it really all that complex? Assuming we're talking about just watching\nfor a certain script template (the HTLC scipt) in the mempool to be able to\npull a pre-image as soon as possible. Early versions of lnd used the mempool\nfor commitment broadcast detection (which turned out to be a bad idea so we\nremoved it), but at a glance I don't see why watching the mempool is so\ncomplex.\n\n\u003e Further, this is a really obnoxious assumption to hoist onto lightning\n\u003e nodes - having an active full node with an in-sync mempool is a lot more\n\u003e CPU, bandwidth, and complexity than most lightning users were expecting to\n\u003e face.\n\nThis would only be a requirement for Lightning nodes that seek to be a part\nof the public routing network with a desire to _forward_ HTLCs. This isn't\ndoesn't affect laptops or mobile phones which likely mostly have private\nchannels and don't participate in HTLC forwarding. I think it's pretty\nreasonable to expect a \"proper\" routing node on the network to be backed by\na full-node. The bandwidth concern is valid, but we'd need concrete numbers\nthat compare the bandwidth over head of mempool awareness (assuming the\nlatest and greatest mempool syncing) compared with the overhead of the\nchannel update gossip and gossip queries over head which LN nodes face today\nas is to see how much worse off they really would be.\n\nAs detailed a bit below, if nodes watch the mempool, then this class of\nattack assuming the anchor output format as described in the open\nlightning-rfc PR is mitigated. At a glance, watching the mempool seems like\na far less involved process compared to modifying the state machine as its\ndefined today. By watching the mempool and implementing the changes in\n#lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10\ndoesn't yet watch the mempool (but does include anchors [1]), but unless I'm\nmissing something it should be pretty straight forward to add which mor or\nless\nresolves this issue all together.\n\n\u003e not fixing this issue seems to render the whole exercise somewhat useless\n\nDepends on if one considers watching the mempool a fix. But even with that a\nbase version of anchors still resolves a number of issues including:\neliminating the commitment fee guessing game, allowing users to pay less on\nforce close, being able to coalesce 2nd level HTLC transactions with the\nsame CLTV expiry, and actually being able to reliably enforce multi-hop HTLC\nresolution.\n\n\u003e Instead of making the HTLC output spending more free-form with\n\u003e SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other\n\u003e direction - all HTLC output spends need to be pre-signed.\n\nI'm not sure this is actually immediately workable (need to think about it\nmore). To see why, remember that the commit_sig message includes HTLC\nsignatures for the _remote_ party's commitment transaction, so they can\nspend the HTLCs if they broadcast their version of the commitment (force\nclose). If we don't somehow also _gain_ signatures (our new HTLC signatures)\nallowing us to spend HTLCs on _their_ version of the commitment, then if\nthey broadcast that commitment (without revoking), then we're unable to\nredeem any of those HTLCs at all, possibly losing money.\n\nIn an attempt to counteract this, we might say ok, the revoke message also\nnow includes HTLC signatures for their new commitment allowing us to spend\nour HTLCs. This resolves things in a weaker security model, but doesn't\naddress the issue generally, as after they receive the commit_sig, they can\nbroadcast immediately, again leaving us without a way to redeem our HTLCs.\n\nI'd need to think about it more, but it seems that following this path would\nrequire an overhaul in the channel state machine to make presenting a new\ncommitment actually take at least _two phases_ (at least a full round trip).\nThe first phase would tender the commitment, but render them unable to\nbroadcast it. The second phase would then \u003cinsert something something\nscriptless scripts here\u003e enter a new sub-protocol which upon conclusion,\ngives the commitment proposer valid HTLC signatures, and gives the responder\nwhat they need to be able to broadcast their commitment and claim their\nHTCLs in an atomic manner.\n\n-- Laolu\n\n[1]: https://github.com/lightningnetwork/lnd/pull/3821\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200421/6cae2a06/attachment.html\u003e"}