{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-04-22\n📝 Original message:\nOn 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote:\n\u003e \n\u003e\u003e Indeed, that is what I’m suggesting\n\u003e \n\u003e Gotcha, if this is indeed what you're suggesting (all HTLC spends are now\n\u003e 2-of-2 multi-sig), then I think the modifications to the state machine I\n\u003e sketched out in an earlier email are required. An exact construction which\n\u003e achieves the requirements of \"you can't broadcast until you have a secret\n\u003e which I can obtain from the htlc sig for your commitment transaction, and my\n\u003e secret is revealed with another swap\", appears to be an open problem, atm.\n\nHmm, indeed, it does seem to require a change to the state machine, but I don't think a very interesting one. Because B\nproviding A an HTLC signature spending a commitment transaction B will broadcast does not allow A to actually broadcast\nsaid HTLC transaction, B can be rather liberal with it. Indeed, however, it would require that B provide such a\nsignature before A can send the commitment_signed that exists today.\n\n\u003e Even if they're restricted in this fashion (must be a 1-in-1 out,\n\u003e sighashall, fees are pre agreed upon), they can still spend that with a CPFP\n\u003e (while still unconfirmed in the mempool) and create another heavy tree,\n\u003e which puts us right back at the same bidding war scenario?\n\nRight, you'd have to use anchor outputs just like we do on the commitment transaction :).\n\n\u003e\u003e There are a bunch of ways of doing pinning - just opting into RBF isn’t\n\u003e\u003e even close to enough.\n\u003e \n\u003e Mhmm, there're other ways of doing pinning. But with anchors as is defined\n\u003e in that spec PR, they're forced to spend with an RBF-replaceable\n\u003e transaction, which means the party wishing to time things out can enter into\n\u003e a bidding war. If the party trying to impeded things participates in this\n\u003e progressive absolute fee increase, it's likely that the war terminates\n\u003e with _one_ of them getting into the block, which seems to resolve\n\u003e everything?\n\nNo? Even if we assume there are no tricks that you can play with, eg, the package limits duri eviction, which I'd be\nsurprised about, the \"absolute fee/feerate\" thing still screws you. The attacker here gets to hold something at the\nbottom of the mempool and the poor honest party is going to have to pay an absurd (likely more than the HTLC value) fee\njust to get it unstuck, whereas the attacker never would have had to pay said fee.\n\n\u003e -- Laolung\n\u003e \n\u003e \n\u003e On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo \u003clf-lists at mattcorallo.com \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e \n\u003e \n\u003e \n\u003e\u003e     On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun \u003claolu32 at gmail.com \u003cmailto:laolu32 at gmail.com\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e     \u003e Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to\n\u003e\u003e     \u003e braodcasted transactions, but instead to CPFP a maybe-broadcasted\n\u003e\u003e     \u003e transaction by sending a transaction which spends it and seeing if it is\n\u003e\u003e     \u003e accepted\n\u003e\u003e\n\u003e\u003e     Sorry I still don't follow. By \"we clearly need to go the other direction -\n\u003e\u003e     all HTLC output spends need to be pre-signed.\", you don't mean that the HTLC\n\u003e\u003e     spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig\n\u003e\u003e     covenant? If the other party isn't restricted w.r.t _how_ they can spend the\n\u003e\u003e     output (non-rbf'd, ect), then I don't see how that addresses anything.\n\u003e \n\u003e     Indeed, that is what I’m suggesting. Anchor output and all. One thing we could think about is only turning it on\n\u003e     over a certain threshold, and having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” limit.\n\u003e \n\u003e\u003e     Also see my mail elsewhere in the thread that the other party is actually\n\u003e\u003e     forced to spend their HTLC output using an RBF-replaceable transaction. With\n\u003e\u003e     that, I think we're all good here? In the end both sides have the ability to\n\u003e\u003e     raise the fee rate of their spending transactions with the highest winning.\n\u003e\u003e     As long as one of them confirms within the CLTV-delta, then everyone is\n\u003e\u003e     made whole.\n\u003e \n\u003e     It does seem like my cached recollection of RBF opt-in was incorrect but please re-read the intro email. There are a\n\u003e     bunch of ways of doing pinning - just opting into RBF isn’t even close to enough.\n\u003e \n\u003e\u003e     [1]: https://github.com/bitcoin/bitcoin/pull/18191\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e     On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo \u003clf-lists at mattcorallo.com \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e         A few replies inline.\n\u003e\u003e\n\u003e\u003e         On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:\n\u003e\u003e         \u003e Hi Matt,\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e\u003e While this is somewhat unintuitive, there are any number of good anti-DoS\n\u003e\u003e         \u003e\u003e reasons for this, eg:\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e None of these really strikes me as \"good\" reasons for this limitation, which\n\u003e\u003e         \u003e is at the root of this issue, and will also plague any more complex Bitcoin\n\u003e\u003e         \u003e contracts which rely on nested trees of transaction to confirm (CTV, Duplex,\n\u003e\u003e         \u003e channel factories, etc). Regarding the various (seemingly arbitrary) package\n\u003e\u003e         \u003e limits it's likely the case that any issues w.r.t computational complexity\n\u003e\u003e         \u003e that may arise when trying to calculate evictions can be ameliorated with\n\u003e\u003e         \u003e better choice of internal data structures.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e In the end, the simplest heuristic (accept the higher fee rate package) side\n\u003e\u003e         \u003e steps all these issues and is also the most economically rationale from a\n\u003e\u003e         \u003e miner's perspective. Why would one prefer a higher absolute fee package\n\u003e\u003e         \u003e (which could be very large) over another package with a higher total _fee\n\u003e\u003e         \u003e rate_?\n\u003e\u003e\n\u003e\u003e         This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to\n\u003e\u003e         start with\n\u003e\u003e         a concrete suggestion here :).\n\u003e\u003e\n\u003e\u003e         \u003e\u003e You'll note that B would be just fine if they had a way to safely monitor the\n\u003e\u003e         \u003e\u003e global mempool, and while this seems like a prudent mitigation for\n\u003e\u003e         \u003e\u003e lightning implementations to deploy today, it is itself a quagmire of\n\u003e\u003e         \u003e\u003e complexity\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e Is it really all that complex? Assuming we're talking about just watching\n\u003e\u003e         \u003e for a certain script template (the HTLC scipt) in the mempool to be able to\n\u003e\u003e         \u003e pull a pre-image as soon as possible. Early versions of lnd used the mempool\n\u003e\u003e         \u003e for commitment broadcast detection (which turned out to be a bad idea so we\n\u003e\u003e         \u003e removed it), but at a glance I don't see why watching the mempool is so\n\u003e\u003e         \u003e complex.\n\u003e\u003e\n\u003e\u003e         Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the\n\u003e\u003e         policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack.\n\u003e\u003e\n\u003e\u003e         \u003e\u003e Further, this is a really obnoxious assumption to hoist onto lightning\n\u003e\u003e         \u003e\u003e nodes - having an active full node with an in-sync mempool is a lot more\n\u003e\u003e         \u003e\u003e CPU, bandwidth, and complexity than most lightning users were expecting to\n\u003e\u003e         \u003e\u003e face.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e This would only be a requirement for Lightning nodes that seek to be a part\n\u003e\u003e         \u003e of the public routing network with a desire to _forward_ HTLCs. This isn't\n\u003e\u003e         \u003e doesn't affect laptops or mobile phones which likely mostly have private\n\u003e\u003e         \u003e channels and don't participate in HTLC forwarding. I think it's pretty\n\u003e\u003e         \u003e reasonable to expect a \"proper\" routing node on the network to be backed by\n\u003e\u003e         \u003e a full-node. The bandwidth concern is valid, but we'd need concrete numbers\n\u003e\u003e         \u003e that compare the bandwidth over head of mempool awareness (assuming the\n\u003e\u003e         \u003e latest and greatest mempool syncing) compared with the overhead of the\n\u003e\u003e         \u003e channel update gossip and gossip queries over head which LN nodes face today\n\u003e\u003e         \u003e as is to see how much worse off they really would be.\n\u003e\u003e\n\u003e\u003e         If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing\n\u003e\u003e         partially-offline local lightning hubs which would be rendered impractical.\n\u003e\u003e\n\u003e\u003e         \u003e As detailed a bit below, if nodes watch the mempool, then this class of\n\u003e\u003e         \u003e attack assuming the anchor output format as described in the open\n\u003e\u003e         \u003e lightning-rfc PR is mitigated. At a glance, watching the mempool seems like\n\u003e\u003e         \u003e a far less involved process compared to modifying the state machine as its\n\u003e\u003e         \u003e defined today. By watching the mempool and implementing the changes in\n\u003e\u003e         \u003e #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10\n\u003e\u003e         \u003e doesn't yet watch the mempool (but does include anchors [1]), but unless I'm\n\u003e\u003e         \u003e missing something it should be pretty straight forward to add which mor or less\n\u003e\u003e         \u003e resolves this issue all together.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e\u003e not fixing this issue seems to render the whole exercise somewhat useless\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e Depends on if one considers watching the mempool a fix. But even with that a\n\u003e\u003e         \u003e base version of anchors still resolves a number of issues including:\n\u003e\u003e         \u003e eliminating the commitment fee guessing game, allowing users to pay less on\n\u003e\u003e         \u003e force close, being able to coalesce 2nd level HTLC transactions with the\n\u003e\u003e         \u003e same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC\n\u003e\u003e         \u003e resolution.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e\u003e Instead of making the HTLC output spending more free-form with\n\u003e\u003e         \u003e\u003e SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other\n\u003e\u003e         \u003e\u003e direction - all HTLC output spends need to be pre-signed.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e I'm not sure this is actually immediately workable (need to think about it\n\u003e\u003e         \u003e more). To see why, remember that the commit_sig message includes HTLC\n\u003e\u003e         \u003e signatures for the _remote_ party's commitment transaction, so they can\n\u003e\u003e         \u003e spend the HTLCs if they broadcast their version of the commitment (force\n\u003e\u003e         \u003e close). If we don't somehow also _gain_ signatures (our new HTLC signatures)\n\u003e\u003e         \u003e allowing us to spend HTLCs on _their_ version of the commitment, then if\n\u003e\u003e         \u003e they broadcast that commitment (without revoking), then we're unable to\n\u003e\u003e         \u003e redeem any of those HTLCs at all, possibly losing money.\n\u003e\u003e\n\u003e\u003e         Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but\n\u003e\u003e         instead to CPFP\n\u003e\u003e         a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You\n\u003e\u003e         only need to\n\u003e\u003e         know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do\n\u003e\u003e         this, you\n\u003e\u003e         don't have to actually *have* the fully-signed transaction (and you don't).\n\u003e\u003e\n\u003e\u003e         \u003e In an attempt to counteract this, we might say ok, the revoke message also\n\u003e\u003e         \u003e now includes HTLC signatures for their new commitment allowing us to spend\n\u003e\u003e         \u003e our HTLCs. This resolves things in a weaker security model, but doesn't\n\u003e\u003e         \u003e address the issue generally, as after they receive the commit_sig, they can\n\u003e\u003e         \u003e broadcast immediately, again leaving us without a way to redeem our HTLCs.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e I'd need to think about it more, but it seems that following this path would\n\u003e\u003e         \u003e require an overhaul in the channel state machine to make presenting a new\n\u003e\u003e         \u003e commitment actually take at least _two phases_ (at least a full round trip).\n\u003e\u003e         \u003e The first phase would tender the commitment, but render them unable to\n\u003e\u003e         \u003e broadcast it. The second phase would then \u003cinsert something something\n\u003e\u003e         \u003e scriptless scripts here\u003e enter a new sub-protocol which upon conclusion,\n\u003e\u003e         \u003e gives the commitment proposer valid HTLC signatures, and gives the responder\n\u003e\u003e         \u003e what they need to be able to broadcast their commitment and claim their\n\u003e\u003e         \u003e HTCLs in an atomic manner.\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e -- Laolu\n\u003e\u003e         \u003e\n\u003e\u003e         \u003e [1]: https://github.com/lightningnetwork/lnd/pull/3821\n\u003e\u003e"}