Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lightning Specification Meeting 2021/02/15 #840

Closed
10 of 23 tasks
t-bast opened this issue Feb 9, 2021 · 2 comments
Closed
10 of 23 tasks

Lightning Specification Meeting 2021/02/15 #840

t-bast opened this issue Feb 9, 2021 · 2 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented Feb 9, 2021 •
edited
Loading

The meeting will take place on Monday 2021/02/15 at 7pm UTC on IRC #lightning-dev. It is open to the public.

Pending from last meetings

Pull Request Review

Issues

Long Term Updates

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

Post-Meeting notes:

Action items
@t-bast
Copy link
Collaborator Author

t-bast commented Feb 9, 2021

As usual, feel free to add other topics to discuss.

@t-bast t-bast pinned this issue Feb 9, 2021
@t-bast
Copy link
Collaborator Author

t-bast commented Feb 15, 2021 

<t-bast> #startmeeting
<lndbot> <johanth> hi evbody
<t-bast> #topic Additional tx test vectors
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/539
<t-bast> Hey johanth!
<rusty> Oops, I will do this today, thanks for reminder (and sorry!)
<t-bast> Cool this is quick one then ;)
<t-bast> Thanks, let's report back on github then, jkczyz you integrated this in RL without issues, right?
<jkczyz> t-bast: yeah, already merged :)
<t-bast> Cool, then it's just pending another validation and we can merge, let's follow up on the PR
<t-bast> #topic sync complete field
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/826
<t-bast> We've merged the change for that in eclair, lnd already does it, what about other implementations?
<BlueMatt> we merged the change
<t-bast> :+1:
<rusty> Will implement!  (As an aside, have switched us to use warnings, not errors when we get upset with gossip now anyway, so incompatibilities are less of an issue!)
<rusty> But will be in our next release, scheduled ~ 1 month from now.
<t-bast> Great, shall we merge the spec PR or shall we wait?
<cdecker> Should be good to merge imho, it's been discussed and implemented extensively
<rusty> Yes, please merge!
<t-bast> #action merge #826
<t-bast> #topic opt_shutdown_anysegwit
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/672
<bitconner> hi all!
<t-bast> hey bitconner
<cdecker> Heya bitconner ^^
<BlueMatt> several questions came up in review while we were reviewing a pr on our end.
<t-bast> this one is still a bit low on our priority for eclair, don't know when we'll implement but it's an ACK for us if RL tests interop with c-lightning
<bitconner> lnd has always accepted any segwit addr iirc
<BlueMatt> bitconner: uhmmmm, that was at some point a serious dos vulnerability.
<BlueMatt> I commented and people generally agrees, and ariard noted that you could end up in a screwy state where you negotiate the feature, open a channel and lock yourself into any segwit address, then reconnect *without* the feature and, uhhhmmmm
<bitconner> BlutMatt: since upfront shutdown script was added?
<BlueMatt> bitconner: since you used to not be able to broadcast such transactions
<t-bast> BlueMatt: you mean you have an issue if you use it in combination with upfront_shutdown_script and then want to downgrade?
<BlueMatt> t-bast: correct.
<ariard> hello
<BlueMatt> hi
<t-bast> I think that in this case, it was validated when the channel was setup and upfront_shutdown_script set, so you should not re-validate and reject it afterwards. Is that an issue?
<BlueMatt> its a useless edge-case, it just should be documented in the spec change that if you negotiate it on open, it still applies
<t-bast> gotcha
<BlueMatt> hmm, the way i read the spec you would be supposed to
<BlueMatt> but i think the correct fix is to just note it and say "dont reject later"
<rusty> Hmm, I don't think it actually matters, TBH.
<rusty> I'm quite happy to leave it undefined.  And if you manage to do this, meh, unilaterally close and go thwack yourself for being an idiot?
<BlueMatt> I dunno, its a +/- 2 word diff, and it clarifies it :)
<rusty> No, it's implementation complexity, too, in a subtle way.
<ariard> to me it was that kind of edge case, if implementations don't agree you might have costly unilateral which could have been avoided
<cdecker> How can one downgrade the upfront shutdown script if you can only specify it at channel creation? 
<BlueMatt> cdecker: it would be downgrading the "anysegwit" part
<BlueMatt> rusty: yea, ok, I see your point. I dont feel incredibly strongly, I guess, but should probably clarify the other note that was on the pr just for clarity
<ariard> so when you check again at closing the committed upfront script isn't accepted anymore
<rusty> ariard: in which case it's fine to be undefined.  Maybe they'll take it, maybe they won't.
<cdecker> I see, thanks BlueMatt, I didn't consider the full scope 👍
<rusty> Spec implies they won't, but if they want to, cool.
<ariard> BlueMatt: maybe we should commit the features set in our persistence module to minimize risks of users loading node with old config and thus triggering that behavior
<rusty> Note that we check these two things in completely separate places, so it's actual real work for us to allow this
<BlueMatt> ariard: we already have version numbers for that to enforce it.
<rusty> ariard: seriously, they have to (1) negotiate the new feature, (2) use a future segwit address, and (3) downgrade.  But by the time the future sw address is used, everyone will have upgraded, so this is silly.
<BlueMatt> rusty: is it no problem to allow later opt-in to anysegwit if you didnt have an upfront script set?
<BlueMatt> for y'all
<ariard> rusty: yeah let's move on
<t-bast> BlueMatt: I believe yes
<rusty> BlueMatt: absolutely.
<BlueMatt> cool, alright, sounds like merge? are there two implementations?
<t-bast> if there's RL and c-lightning and you tested interop, we can merge
* BlueMatt would prefer the above was clarified in the text, but it doesnt matter much
<BlueMatt> we havent tested interop, no. i thought maybe y'all had.
<BlueMatt> alright, then blocked on interop, lets move on.
<rusty> BlueMatt: I will implement, test with lnd; it's pretty trivial (on testnet, ofc).
<t-bast> #action do interop test and merge if everything goes well
<t-bast> #topic 0-fee anchor output htlc txs
<rusty> I'll also add a note that technically turning the feature off when you've used it for upfront-shutdown lets you break yourself.
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/824
<t-bast> Has anyone completed the 0-fee htlc feature (apart from lnd)?
<t-bast> (otherwise we'll keep it as pending interop)
<ariard> no changes on our side since last time
<cdecker> Nope, we still fire-and-forget atm
<t-bast> ok, let's keep it as pending interop then
<t-bast> #topic Compression algorithms in `init`
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/825
<t-bast> As agreed during the previous meeting, I slightly updated the PR to make the uncompressed case explicit
<rusty> Will implement for interop, but not enable (I'm looking at rewriting our tx handling to enable such things, but writing a bitcoin wallet is still Hard and I'm procrastinating!)
<t-bast> rusty: I feel for you, I'm in that place right now for eclair :D
<rusty> t-bast: we should compare notes!  I'm wondering how ambitious I should be...
<BlueMatt> 10x easier if you ignore unconfirmeds :p
<t-bast> rusty: sure, let's sync offline on the scope we're each targeting, I think it will be a good learning experience
<rusty> Anyway, to catch up.  I really think zlib is trivial enough to JFDI.  But I know others want this...
<t-bast> BlueMatt: clearly a lot less headaches, but a lot more utxos to reserve in case hell breaks loose!
<rusty> Technically, this is a bitmap of *de*compression the node supports.
<t-bast> true
<t-bast> do you often support decompression without compression though? :D
<rusty> And why is there a feature bit for this?  Surely being an odd TLV is enough?
<t-bast> There was a reason, let me find it again
<rusty> Might have been left-over from previous proposals?
<cdecker> Yeah, lost that battle twice already re zlib :-)
<t-bast> The rationale is that a feature bit lets you find nodes that support this through node_announcement to ensure you don't do the `init` dance just to see if they'll advertize the compression algorithms
<t-bast> But I'm not sure it's really worth a feature bit, we could drop it. BlueMatt and ariard, what are your thoughts on that?
<BlueMatt> cdecker: zlib has had a mixed security history, like most compression libs. leaving it out is not unreasonable in a money-holding context....
<BlueMatt> t-bast: I don't feel strongly, honestly.
<BlueMatt> I kinda figure why not, cause it doesnt cost anything, really.
<BlueMatt> especially if its already there in init.
<rusty> BlueMatt: meh, it's pretty rock solid now, but understood.
<cdecker> BlueMatt: I meant re-adding zlib as an explicit opt-in after it has been implicitly enabled all the time, not whether zlib should be there at all
<BlueMatt> rusty: probably is, though I wouldnt say the same for its memory dos resistance in particularly-constrained environments.
<cdecker> Oh and uncompressed imho is no encoding, and MUST be supported by everyone.
<t-bast> I don't feel strongly either, maybe just to avoid "wasting" a feature bit slot
<BlueMatt> I meannnn...
<BlueMatt> we have unlimited, lets not be stingy
<t-bast> rusty: why do you want to remove the feature bit?
<rusty> t-bast: bit bloat!  They actually start expanding gossip msgs after a while.
<rusty> (You know we're going to have  Rollup Bit one day which implies old bits so we can reuse them.  I plan to retire on that day, FWIW)
<bitconner> i'd be in favor of keeping the feature bit, making the things explict, etc
<BlueMatt> yea, its fair, but if we want to use them to figure out who to connect to, this is somewhat important.
<rusty> Well, I think it'll roll out so fast it's not important.  It' not like it's hard to implement...
<BlueMatt> which, iiuc, is kinda the point of the node features.
<BlueMatt> thats true.
<BlueMatt> anyway, I dont feel strongly, I'm happy if rusty does :p
<rusty> I'd be convinced if I felt this was a significant feature which future things may reasonably opt out of.  But I don't want to block it, OTOH.
* jonatack_ has quit (Remote host closed the connection)
<rusty> (BTW, I was right!  This bit creates a new byte in the msg!  Boo!  Boo!) :)
<t-bast> haha
<bitconner> if feature bit bloat really becomes an issue we can recycle them once they're more or less required by all implementations
<rusty> bitconner: indeed, see rollup bit above...
<bitconner> but even before that we could look into more optimal encodings that aren't O(highest bit set)
<BlueMatt> bitconner: like...zlib </troll>
<t-bast> I'm leaning towards keeping that feature bit, any strong opion against that? If not, we'll move that PR to the pending interop phase
<rusty> BlueMatt: lol
<bitconner> 👀
<rusty> OK, I concede.  Ack.
<t-bast> thanks :)
<t-bast> #action implement and test interop
<t-bast> #topic Warning messages
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/834
<rusty> (Somehow I ended up with 4 things on my "implement today" list.... my fault for being absent so much recently)
<rusty> OK, so I have actually implemented this, since it really is kinda harmless.  Was good to audit our code and try to see "what is actually fatal, and what could theoretically be recovered".
<t-bast> rusty: if one of these 4 is "implement a bitcoin wallet from scratch for anchor outputs" good luck, we won't see you in a while xD
<bitconner> utACK
<BlueMatt> concept ack. I'd need to go reread the full spec to make sure the usage of "close connection" vs "fail channel" is consistent
<rusty> e.g. if they update_fee out of bounds, we now send a warning and close the connection.  They can't really do anything (since they're committed to that state), but in theory our own side might come into alignment with fees later and allow it.
* jonatack ([email protected]) has joined
<bitconner> lol, link copying went to PR 83, not 834. ignore 
<carlakc> I think I'm missing a bit of real life context for this one, why do we need a new message rather than using a zero channel ID for a warning type message?
<rusty> Main issue is that older nodes won't log the warning msg, so if there's a problem they'll just see disconnects.
<carlakc> difficult to figure out the difference between what the spec says, and what everybody is doing
<rusty> carlakc: that technically means "CLOSE ALL CHANNELS".
<BlueMatt> rusty: I'm ok with that.
<cdecker> carlakc: zero channel_id basically means "kill all channels".
<t-bast> the big red button
<carlakc> ah :| did anybody actually implement that?
<BlueMatt> yes.
<rusty> carlakc: context for this is that the original text was very much "if something goes wrong, kill channel".  That's cute for alpha testing, but increasingly ignored IRL.
<cdecker> Yep, c-lightning got a lot of flak for it....
<rusty> carlakc: yeah, and *worse* we would send such msgs if we didn't like your gossip!
<t-bast> yep eclair implements this as well
<cdecker> Since some implementations were using "soft-errors", that we'd interpret as emergencies 
<rusty> So, c-lightning currently pretends those are warnings when it receives them.
<rusty> Doesn't help much if the other side actually kills our channels, ofc.
<carlakc> rusty: right, but hasn't always done so, so would still be an issue for older nodes. got it. 
<carlakc> definitely going to be helpful to get a message before disconnect, debugging a
<carlakc> an EOF on disconnect is tricky
<t-bast> I think these warning messages make sense, definitely worth having IMO, so concept ACK until we implement
<BlueMatt> anyway, sounds like general agreement on strong concept ack, but I assume everyone else also wants to read all the cases?
<BlueMatt> and implement
<t-bast> BlueMatt: ACK
<rusty> Great, I did a sweep of the spec but may have missed some non-conformant wording.
<bitconner> sgtm
<t-bast> #action everyone sweeps the spec for inconsistencies and start implementing
<BlueMatt> cool
<t-bast> #topic Remove obsolete requirement on addresses
<cdecker> In case others are wondering which former errors are now warnings in c-lightning: https://github.com/ElementsProject/lightning/pull/4364
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/842
<rusty> (Note that this kind of implies you should have some timeout based shutdown if channels are soft-failing for long enough.  c-lightning does not have that currently)
<t-bast> thanks cdecker, it's going to be helpful
<rusty> OK, no, this is broken BlueMatt!
<t-bast> You're going to mention re-encoding and signing?
<rusty> We can absolutely allow duplicates, but we don't have explicit lengths, so you have to stop parsing when you see a number we don't understand.
<rusty> If you put your new i2p addresses first, I won't parse the IPv4 address at the end!
<BlueMatt> I mean the current gossip has violations of this live
<bitconner> OP_ADDR_SUCCESS
<BlueMatt> so its not being enforced and you have to support that already today, rusty.
<BlueMatt> assuming you want to fetch the full routing graph.
<rusty> BlueMatt: you literally cannot implement that.
<BlueMatt> if you dont support it, that is correct.
<rusty> BlueMatt: if we add a new address format, you cannot parse it.
<BlueMatt> if you do support all the encodings used, then you can read them fine
<t-bast> that's a good point, I hadn't thought of that
<rusty> what implementation is out of order?  It needs to be fixed.
<BlueMatt> we currently enforce this on reading gossip messages and get very angry very fast.
<BlueMatt> I didnt check into where they came from.
<rusty> I know some do duplicates.
<BlueMatt> right, we dont enforce that. only the order limits
<rusty> Well, c-lightning explicitly sorts them.  We even disallow duplicates, but that can be relaxed.
<BlueMatt> I get the sense the only way to ever have a limit like this is if people enforce it on the gossip-receive end
<rusty> BlueMatt: well, when we add a new format ppl will fix their code pretty fast.  We just haven't done that yet.
<BlueMatt> I dunno, good chance people just get yelled at to upgrade
<t-bast> Hum I'm not sure eclair sorts them correctly, but I can fix that
<cdecker> Consensus by shouting match as it were
<BlueMatt> this is why we enforce it at the message end, but....we still need to be able to connect to people
<BlueMatt> so, anyway, we're gonna stop enforcing this. sadly its somewhat difficult for us to serialize when sending but not when receiving/sending from our own graph.
<rusty> BlueMatt: absolutely, and thanks for bringing it to our attention!  If we'd had TLV ofc, this wouldn't be an issue.
<bitconner> i'm not sure lnd sorts either, i can check
<BlueMatt> so we're gonna be out of spec on this.
<rusty> (You already have that problem with multiples, since their order is undefined)
* bnger93 (8ff43034@gateway/web/cgi-irc/kiwiirc.com/ip.143.244.48.52) has joined
<rusty> (We could force a lex sort now, if you wanted BlueMatt?)
<BlueMatt> rusty: hmm? I dont think we can force any sort unless its also done on decode.
<rusty> Actually, that won't help.  You can't unmarshall unknown fields, so you really need to preserve this as a blob.
<BlueMatt> I mean *can*, but its a good chunk more code.
* bnger93 has quit (Client Quit)
<BlueMatt> in a related note - since we now do not enforce single address anymore, should we have an analygous "if you have > 10 addresses, dont relay" to the "if there is unknown unparsable data, dont relay" requirement
<t-bast> #action implementations should check their code and ensure addresses are ordered (duplicates are ok though)
<BlueMatt> I dont think that makes sense
* bnger79 (4273a52a@gateway/web/cgi-irc/kiwiirc.com/ip.66.115.165.42) has joined
<BlueMatt> it already exists, in practice, live
<BlueMatt> you cant just start enforcing on the sending end and consider it fixed
<BlueMatt> we need to allow any order for currently-defined addresses, and enforce order for not-yet-defined ones.
<BlueMatt> well, i mean i guess we already do enforce such an order, by accident
<t-bast> But it's a good first step to fix the sending side
<t-bast> That means in X months/years it can be considered fixed on the whole network
<rusty> BlueMatt: I took t-bast to mean "... on the sending side"?
* bnger has quit (Ping timeout: 240 seconds)
<t-bast> yes that's what I meant, sorry if that was unclear
<BlueMatt> right, note that I dont think we're realistically going to enfoce it on thse sending side if we cannot enforce it on the receiving end
<BlueMatt> and we cannot enforce it on the receiving end.
<t-bast> true, but a first step is to fix the sending side at least
<BlueMatt> sure, maybe doesnt matter much, but I think we should just give up for current address formats
<rusty> BlueMatt: we should probably have always had something about "MAY not relay if size is excessive"?
<BlueMatt> we've already lost
<rusty> BlueMatt: heh, next CVE everyone upgrades and we win again :)
<BlueMatt> rusty: well originally it was "only one address per type", which solves that :p
<BlueMatt> rusty: lol, k, #action someone find a big cross-implementation CVE
<rusty> BlueMatt: not well, we could have LOTS of types.
<BlueMatt> sure, but for now we have 4 so it originally limited it pretty tightly. now there is no limit for the size of relayed gossip messages
<BlueMatt> of course most folks didnt *implement* the limit, but the spec had it
<t-bast> We're already past 1 hour, shall we do a last PR, a free/open discussion, or stop there?
<rusty> TBH I'm not sure what a "reasonable limit" for gossip msgs is, so hard to spec.  Hmm... OK, anyway, let's move on?
<BlueMatt> discuss on the pr.
<BlueMatt> and I'll open an issue limiting it to 10 for now
<BlueMatt> cause, whatever, we can change it later.
<rusty> BlueMatt: but you can't count them (unknown addr formats).  Suggest a byte limit instead?
<BlueMatt> rusty: you are already not supposed to relay if there are any unknown, iirc
<BlueMatt> or, at least, we dont.
<rusty> BlueMatt: I think that was removed from the spec a while ago.  We used to not relay unknown msgs, but it splits the network and is a Bad Idad.
<BlueMatt> right
<rusty> commit 6502e30e8f1052371dc3c6791328d218f4c1cde3
<rusty> Author: Rusty Russell <[email protected]>
<rusty> Date:   Tue Sep 17 14:55:10 2019 +0930
<rusty>     BOLT 7: always propagate announcements with unknown features.
<rusty>  
<BlueMatt> not just features
<cdecker> That's a great way to create a network partition BlueMatt
<BlueMatt> extra bytes
<rusty> Yeah, I think that was previously implied, but no longer is.
<BlueMatt> right, anyway, lets move on
<ariard> cdecker: not relaying different from closing connections?
<t-bast> Let's do a last PR quickly
<t-bast> #topic funding expiry
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/839
<ariard> t-bast: can you sum up the benefits quickly?
<t-bast> Routing nodes have an incentive to use low fees when opening channels to ensure their activity is economically viable.
<t-bast> However, when a funding transaction takes too long to confirm, the fundee may have forgotten the channel. In that case the funder is forced to broadcast the first commit tx to get his funds back and then open a new channel, which is costly.
<t-bast> We can avoid this issue by having an explicit commitment to a block before which the funding tx will be confirmed. The fundee will keep the channel around for that duration, and the funder needs to ensure the funding tx confirms before that deadline (using CPFP on a change output for example). This gives clearer guarantees for both the funder and fundee.
<t-bast> This is just making explicit a deadline that is currently implicit and different in each implementation
<t-bast> I'd also like to add an additional thing while we're at it: I think it would also make sense for the funder to commit to the feerate he'll use in a TLV field in the `open_channel` message. This way if you're DoS-ed by `channel_open` messages, you can immediately reject those that use a low feerate without allocating any resource.
<rusty> t-bast: my general preference here is to always ask "can we just pick a universal number instead"?  I don't know what to put here...
<t-bast> Even though you'll need to wait and see the funding tx to verify that the feerate is indeed what the funder told you
<rusty> t-bast: hmm, yeah, not sure that actually works if it's a real DoS (vs. you just being popular again!)
<t-bast> rusty: that's a possibility, we could all decide that 2 weeks is a healthy limit
<BlueMatt> t-bast: adding a pre-commitment to tx fee kinda sucks
<rusty> t-bast: 2016 blocks *is* a magic number.
<BlueMatt> you may not know that in advance, and definitely not exactly.
<cdecker> Would be great if the fundee could just remember one mutual close signature indefinitely, so we can do a mutual close instead
<ariard> this is not a commitment to tx fee
<BlueMatt> piping it through various places isn't fun for us.
<ariard> just a clear timestop to clean your state machine
<BlueMatt> ariard: t-bast indicated he'd like to also add that.
<t-bast> BlueMatt: yes that's something else I'd like to add, but maybe I need to think about it further and articulate it correctly
<t-bast> Let's focus at first on what's in the PR, that would be a good start, and I'll come back with a proposal for additional stuff later if that makes sense
<ariard> t-bast: if you wanna DoS someone just use a high feeerate
<t-bast> So, as rusty mentions, we could just say fundee can forget channels after 2016 blocks
<ariard> like if the DoS is about sending a lot of open messages don't matter the content itself to be junk
<t-bast> And funders would ensure they CPFP accordingly if they don't want to have to force-close. Or we can do something cooler like cdecker says and provide an initial mutual close (but I'd need to dig more into it to see how feasible that is)
* cryptapus (~cryptapus@unaffiliated/cryptapus) has joined
<t-bast> ariard: it's not really about the messages, but rather the state you need to keep
<rusty> OK, so it's my youngest son's birthday today and I FORGOT TO WRAP HIS PRESENT.  I, um, need to go.... thanks all!
<t-bast> ariard: if you can just drop the message and not have to keep any state, it's an improvement over what we have today
<cdecker> The overhead for the canned mutual sig is 64 bytes per failed channel, and it'd speed up funds recovery a lot and safe fees as well
<BlueMatt> lol, have fun rusty 
<t-bast> haha see you rusty!
* BlueMatt is ok with just fixing it to a static 2016 blocks
<cdecker> Bye Rusty, good luck and say hi from us :-)
<ariard> t-bast: if the message intention is really to be malicious use a content which will make victim allocate state anyway
<bitconner> adios rusty!!
<t-bast> Are there concerns if we simply use a 2016 blocks static value instead of this TLV?
<t-bast> We can do cdecker's proposal for a mutual close sig as a follow up
<cdecker> Agreed, let's get a fixed timeout going first, then the follow ups can make that negotiable, and stash a mutual sig aside
<ariard> t-bast: hmmmm how do you invalidate mutual close sig once exchanged ?
<bitconner> have a mutual close signature up front?
<ariard> but good to me with 2016 blocks as static value
<bitconner> that would invalidate the channel?
<t-bast> don't know, cdecker just mentioned it but haven't digged into it yet
<bitconner> i'm fine with fixed 2016 block proposoal
<t-bast> great, I'll update the PR to a much simpler version then
<bitconner> if there is a mutual close signature i can make htlc updates and then broadcast the mutual close and get my money back
<t-bast> #action t-bast to update the PR to use a fixed 2016 blocks timeout
<bitconner> same reason why we can't resume operation of a channel after sending 1 coop close proposal to the remote peer
<cdecker> We can just set a fixed timeout of another 2016 to clean up the signature as well
<ariard> the mutual close sig needs to commit to a balance state
<t-bast> IIUC the mutual close sig is only provided by the fundee once it decides to forget about the channel because it didn't confirm in time
<cdecker> Right, it can just be the funding amount - any reasonable fee (handwave)
<ariard> you can't invalidate the signature without renewing the utxo
<bitconner> but the sig remains valid if the channel does confirm
<t-bast> It's being nice to the funder to avoid having him waste too much funds by force-closing and re-opening
<bitconner> unless i'm missing understanding
<ariard> so it's more a goodbye signature
<t-bast> exactly
<BlueMatt> bitconner: presumably you'd only provide it if the channel is going to be ignored
<BlueMatt> "sorry, deleting all other state, heres a sig to get your funds back if you care, but I dont remember it as a channel now"
<cdecker> If the fundee wants to forget, it marks the channel as closing, does not accept anyfuture updates, and just returns the canned sig to reestablish, as an extension to "don't know that channel"
<ariard> the sig can be SIGHASH_ANYONECANPAY to allow fee flexibility
<t-bast> It would be much nice than now, where the fundee just forgets about the channel and the funders gets a generic "unknown channel" error and has to force-close / re-open
<ariard> or even SINGLE, likely the fundee don't have a balance output yet
<cdecker> Right, good idea ariard
<bitconner> gotcha, as long as it's clear that the channel MUST NOT be used if does end up confirming that's okay
<cdecker> Yep, that should definitely be noted in the proposal ^^
<t-bast> The explicit 2016 timeout will already be a very nice improvement, let's start with that cause it's going to be trivial to implement and then we can do another PR for this courtesy signature
<t-bast> I gotta go, shall we end the meeting?
<ariard> cdecker: in fact the best fit is likely the unsafe SIGHASH_NONE
<ariard> t-bast: yeah thanks for chairing
<cdecker> Yeah, that'd allow the fundee to bump it as well, removing the need to have a good fee estimation
<cdecker> Thanks for chairing t-bast
<cdecker> I better be off as well ^^
<cdecker> Thanks everyone for a productive meeting :+1: 
<t-bast> #endmeeting

@t-bast t-bast mentioned this issue Feb 15, 2021
Merged
@t-bast t-bast unpinned this issue Mar 15, 2021
@t-bast t-bast closed this as completed Mar 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@t-bast