Olaoluwa Osuntokun <laol...@gmail.com> writes: > Hi Rusty, > > Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other > alternatives for a few years now, and none of them seems to resolve the > series of routing related incentive issues that prepaid HTLCs would. > >> Since both Offers and Joost's WhatSat are looking at sending messages, >> it's time to float actual proposals. > > IMO both should just be done over HORNET, so we don't need introduce a new > set of internal protocol level messages whenever we have some new > control/signalling need. Instead, we'd have a control/signal channel (give > me > routes, invoices, sign this, etc), and a payment channel (HTLCs as used > today).
I'm not so sure, as I don't think we're going to actually use each one more than once or twice? I mean, we could stream movies through LN, but I think that's an added service, which would be best done by HORNET. >> 2. Adding an HTLC causes a *push* of a number of msat on commitment_signed >> (new field), and a hash. > > The prepay amount should be signalled in the update add message instead. > This lets HTLCs carry a heterogeneous set of prepay amounts. In addition, we > need a new onion field as well to signal the incoming amount the node > _should_ have received (allows them to detect deviations in the sender's > intended route). Sorry, brain fart: it's a new field in the update_add_htlc of course. I just, um, added that to make sure you were all reading carefully! :_ >> 3. Failing/succeeding an HTLC returns some of those msat, and a count and >> preimage (new fields). > > Failing shouldn't return the prepay amount, otherwise extending long lived > HTLCs then cancelling them at the last minute is still costless. This > costlessness of _adding_ an HTLC to a _remote_ commitment is IMO, the > biggest incentive flaw that exists today in the greater routing network. No, that's type (liquidity) 3 spam, which needs a completely different solution. Definitely needs fixing, but up-front fees don't do it (except in the case where you might want to indicate you're *going* to have a long-held HTLC, where you'd pay additional up-front, but that's future work). >> You get to keep 50 msat[1] per preimage you present[2]. > > We should avoid introducing any new constants to the protocol, as they're > typically dreamed up independent of any empirical lessons learned from > deployment. OTOH, we should avoid creating more complex knobs for users, since the complexity of the protocol is becoming unmanagable. I think we did this too much with v1, so instead of getting empirical data we got defaults which in practice are unspecified specifications. I like a flat value to start, since it's easy to implement and deploy. > On the topic of the prepay cost, the channel update message should be > extended to allow nodes to signal prepay costs similar to the way we handle > regular payment success fees. In order to eliminate a number of costless > attacks possible today on the routing network, nodes should also be able to > signal a new coefficient used to _scale_ the prepay fee as a function of the > CLTV value of the incoming HTLC. ... and HTLC amount, surely? That becomes a pretty complex tuning parameter. I think we should directly target type 3 spam through a separate mechanism (as discussed previously). This is just to prevent quantity of messages. > With this addition, senders need to pay to > _add_ an HTLC to a remote commitment transaction (fixed base cost), then > also need to pay a variable rate that scales with the duration of the > proposed outgoing CLTV value (senders ofc don't prepay to themselves). Once > we introduce this, loop attacks and the like are no longer free to launch, > and nodes can dynamically respond to congestion in the network by raising > their prepay prices. I disagree; you should signal with normal fees, not prepay. Otherwise we're increasing fees at a time that success rates are lowering, which makes the incentive misalightment far more promiment :( Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
