On 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote: > >> Indeed, that is what I’m suggesting > > Gotcha, if this is indeed what you're suggesting (all HTLC spends are now > 2-of-2 multi-sig), then I think the modifications to the state machine I > sketched out in an earlier email are required. An exact construction which > achieves the requirements of "you can't broadcast until you have a secret > which I can obtain from the htlc sig for your commitment transaction, and my > secret is revealed with another swap", appears to be an open problem, atm.
Hmm, indeed, it does seem to require a change to the state machine, but I don't think a very interesting one. Because B providing A an HTLC signature spending a commitment transaction B will broadcast does not allow A to actually broadcast said HTLC transaction, B can be rather liberal with it. Indeed, however, it would require that B provide such a signature before A can send the commitment_signed that exists today. > Even if they're restricted in this fashion (must be a 1-in-1 out, > sighashall, fees are pre agreed upon), they can still spend that with a CPFP > (while still unconfirmed in the mempool) and create another heavy tree, > which puts us right back at the same bidding war scenario? Right, you'd have to use anchor outputs just like we do on the commitment transaction :). >> There are a bunch of ways of doing pinning - just opting into RBF isn’t >> even close to enough. > > Mhmm, there're other ways of doing pinning. But with anchors as is defined > in that spec PR, they're forced to spend with an RBF-replaceable > transaction, which means the party wishing to time things out can enter into > a bidding war. If the party trying to impeded things participates in this > progressive absolute fee increase, it's likely that the war terminates > with _one_ of them getting into the block, which seems to resolve > everything? No? Even if we assume there are no tricks that you can play with, eg, the package limits duri eviction, which I'd be surprised about, the "absolute fee/feerate" thing still screws you. The attacker here gets to hold something at the bottom of the mempool and the poor honest party is going to have to pay an absurd (likely more than the HTLC value) fee just to get it unstuck, whereas the attacker never would have had to pay said fee. > -- Laolung > > > On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo <lf-li...@mattcorallo.com > <mailto:lf-li...@mattcorallo.com>> wrote: > > > >> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laol...@gmail.com >> <mailto:laol...@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-li...@mattcorallo.com >> <mailto:lf-li...@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 >> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
