From rusty at rustcorp.com.au Tue May 4 04:50:40 2021 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 04 May 2021 14:20:40 +0930 Subject: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation In-Reply-To: <693fd43d-3b31-9aed-970b-e35f7266580c@mattcorallo.com> References: <87zgxocjkk.fsf@rustcorp.com.au> <87mttkco8p.fsf@rustcorp.com.au> <87o8dzbehn.fsf@rustcorp.com.au> <693fd43d-3b31-9aed-970b-e35f7266580c@mattcorallo.com> Message-ID: <878s4v85lr.fsf@rustcorp.com.au> Matt Corallo writes: > On 4/27/21 17:32, Rusty Russell wrote: >> OK, draft is up: >> >> https://github.com/lightningnetwork/lightning-rfc/pull/867 >> >> I have to actually implement it now (though the real win comes from >> making it compulsory, but that's a fair way away). >> >> Notably, I added the requirement that update_fee messages be on their >> own. This means there's no debate on the state of the channel when >> this is being applied. > > I do have to admit *that* part I like :). > > If we don't do turns for splicing, I wonder if we can take the rules around splicing pausing other HTLC updates, make > them generic for future use, and then also use them for update_fee in a simpler-to-make-compulsory change :). Yes, it is similar to the close requirement, except that requires all HTLCs be absent. Cheers, Rusty.