--- Log opened Mon Jun 07 00:00:31 2021
00:51 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 244 seconds]
00:52 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev
00:56 -!- smartin [~Icedove@88.135.18.171] has joined #lightning-dev
01:13 -!- nsh [~lol@5.135.157.17] has quit [Ping timeout: 244 seconds]
01:17 -!- belcher_ is now known as belcher
01:20 -!- koolazer [~koo@user/koolazer] has quit [Ping timeout: 272 seconds]
01:21 -!- koolazer [~koo@user/koolazer] has joined #lightning-dev
01:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
01:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
02:33 -!- bitromortac [bitromorta@gateway/vpn/protonvpn/bitromortac] has joined #lightning-dev
02:48 -!- bitromortac [bitromorta@gateway/vpn/protonvpn/bitromortac] has quit [Quit: leaving]
03:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
04:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev
06:07 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
06:08 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Client Quit]
06:16 -!- sstone [~sstone@user/sstone] has joined #lightning-dev
06:17 -!- sstone [~sstone@user/sstone] has quit [Quit: Leaving]
06:28 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Quit: node-irc says goodbye]
06:28 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: node-irc says goodbye]
06:28 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Quit: node-irc says goodbye]
06:28 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Quit: node-irc says goodbye]
06:34 -!- cryptapus_ is now known as cryptapus
06:47 -!- sstone [~sstone@user/sstone] has joined #lightning-dev
06:49 -!- sstone [~sstone@user/sstone] has quit [Client Quit]
06:50 -!- t-bast [~t-bast@2a01:cb19:706:cb00:c50d:eafb:6f69:67b2] has joined #lightning-dev
06:52 -!- t-bast [~t-bast@2a01:cb19:706:cb00:c50d:eafb:6f69:67b2] has quit [Changing host]
06:52 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev
06:53 -!- t-bast [~t-bast@user/t-bast] has quit [Client Quit]
07:56 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #lightning-dev
07:56 < devrandom> potential spec issue in https://github.com/lightningnetwork/lnd/issues/5362, initially wrongly attributed to lnd
08:12 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Remote host closed the connection]
08:13 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #lightning-dev
08:15 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #lightning-dev
08:15 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has joined #lightning-dev
08:15 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has joined #lightning-dev
08:28 < devrandom> the most obvious issue seems to be that in open_channel, the recipient checks msg.dust < msg.reserve, but msg.dust is a requirement on the sender's commitment txs, and msg.reserve is a requirement that's mostly of interest on the recipient's commitment txs
11:03 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Ping timeout: 244 seconds]
11:03 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 272 seconds]
11:03 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Ping timeout: 272 seconds]
11:04 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Ping timeout: 272 seconds]
12:15 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
12:58 -!- sstone [~sstone@user/sstone] has joined #lightning-dev
12:59 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #lightning-dev
12:59 -!- niftynei [~niftynei@99-8-218-209.lightspeed.hstntx.sbcglobal.net] has joined #lightning-dev
12:59 < niftynei> did someone post the agenda for our chat today yet?
12:59 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has joined #lightning-dev
12:59 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #lightning-dev
12:59 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has joined #lightning-dev
13:00 < niftynei> i dont see one on the rfc repo, looks like we don't have one put together for today 
13:00 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
13:01 < rusty> Hi all!
13:01 < niftynei> hello hello!
13:02 < michaelfolkson> hi
13:03 < valwal> hi
13:03 < sstone> hi everyone! I'm stepping in for t-bast who won't be able to join us tonight
13:04 < rusty> sstone: welcome!  Nothing serious I hope?
13:04 < sstone> no he's a train rn :)
13:04 < sstone> in a train
13:05 < jkczyz_> hey
13:06 < rusty> sstone: LOL, I preferred "he's a train right now".  That left me with *way* more questions than answers!
13:06 < rusty> OK, lots to discuss, did anyone want to chair today?
13:07 < niftynei> i'd be happy to
13:07 < niftynei> but will need topic suggestions :)
13:07 < niftynei> #startmeeting jun-7 lightning spec chat
13:07 < lndev-bot> Meeting started Mon Jun  7 20:07:51 2021 UTC and is due to finish in 60 minutes.  The chair is niftynei. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:07 < lndev-bot> The meeting name has been set to 'jun_7_lightning_spec_chat'
13:08 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/877 ?
13:08 < rusty> (and work our way backwards? )
13:08 < niftynei> let's start there. thanks!
13:09 < niftynei> #topic remove htlc amount restriction 
13:09 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/877
13:09 -!- jkczyz_ [sid419941@id-419941.tooting.irccloud.com] has quit []
13:09 -!- jkczyz_ [sid419941@id-419941.tooting.irccloud.com] has joined #lightning-dev
13:09 -!- jkczyz_ [sid419941@id-419941.tooting.irccloud.com] has quit [Client Quit]
13:09 < niftynei> to summarize, there's a specified limit on how big an individual HTLC can be
13:10 -!- jkczyz [sid419941@id-419941.tooting.irccloud.com] has joined #lightning-dev
13:10 < rusty> This is "wumbo HTLCs" BTW.
13:10 < rusty> (i.e. wumbo payments, vs wumbo channels)
13:10 < niftynei> this PR proposes removing the spec level HTLC cap, reasoning being that max_htlc_value_in_flight_msat is a better method to restrict this amount by
13:11 < niftynei> would this need a flag?
13:11 < rusty> niftynei: weirdly, c-lightning also doesn't enforce this on receive!  (Though we do on send!)
13:11 -!- smartin [~Icedove@88.135.18.171] has quit [Quit: smartin]
13:11 < rusty> niftynei: not if  nobody was actually enforcing it.  Apparently Eclair wasn't, so I guess LND is the only question?
13:11 < niftynei> well that's convenient for rolling this change out then
13:12 < niftynei> do we have anyone from LND here?
13:12 < sstone> would c-lightning relay such payments (guess not if you would not send them) ?
13:13 < rusty> sstone: no, but we can roll this out pretty fast, since release is next week.  As long as LND allows, really.
13:13 < niftynei> sstone iiuc we'd relay them but not be able to initiate them
13:13 < rusty> niftynei: naah, we'd refuse to add them to the outgoing channel
13:13 < niftynei> oh i see
13:13 < michaelfolkson> rust-lightning does/doesn't? It probably should't be removed from spec if c-lighting still enforces this restriction on the receive?
13:14 < rusty> michaelfolkson: to be clear, we *don't* enforce on receive.  BlueMatt should tell is what rust-lightning does?
13:14 < rusty> niftynei: I can test LND on testnet, I think I'm still testnet rich...
13:14 < michaelfolkson> rusty: Oh sorry, on send, not receive
13:15 < sstone> electrum does check, that how we found this issue
13:15 < rusty> sstone: gah, OK, then it needs to be a feature flag (assuming it checks on receive?)
13:15 < BlueMatt> rusty: good question! sec.
13:16 < jkczyz> couldn't find anything but may not be looking in the right places :P
13:16 < sstone> rusty: yes, on receive
13:17 < rusty> sstone: OK, then we need option_wumbo_htlcs...
13:17 < BlueMatt> yea, well we dont allow wumbo channels anyway, so I dont think it matters, we dont appear to be enforcing this directly in any case.
13:17 < niftynei> rusty why does the check-on receive necessitate a flag, but the check-on send not?
13:18 < niftynei> #action t-bast (?) to add flag to PR
13:18 < niftynei> #action rusty to check LND's params via testnet
13:18 < rusty> niftynei: you're not even supposed to *try* to send, the other side can close channel.
13:19 < niftynei> oh i see.
13:19 < niftynei> ok should we move on?
13:19 < rusty> OK, I'm assigning a feature bit now, on issue.  Move on!
13:20 < niftynei> #topic concretize output ordering to be less confusing
13:20 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/876
13:20 < niftynei> we discussed this last meeting, needs another ACK
13:21 < niftynei> tldr: removes reference to BIP69, instead specify the output ordering heuristics explicitly
13:22 < rusty> Ack, I read it just before.  It's nice and clear, good work BlueMatt.
13:22 < niftynei> ok just needs to be merged then
13:23 < niftynei> #action merge PR 876
13:23 < niftynei> moving on
13:23 < rusty> Acked on issue.
13:23 < jkczyz> I ran into some trouble testing on RL, fwiw
13:23 < jkczyz> https://github.com/rust-bitcoin/rust-lightning/issues/927
13:23 < jkczyz> similar problem when the test vectors were last changed
13:23 < jkczyz> haven't had time to dive into unfortunately. could be on our end
13:24 < BlueMatt> last time the test vectors were changed for this? I had thought without diggint into it a ton it was cause of some confusion over the way it was put into the test vector?
13:25 < jkczyz> ah, rather changes that came from 872
13:26 < jkczyz> which is already merged, so feel free to move on. can discuss offline
13:26 < niftynei> ok great
13:26 < niftynei> next up in the PR list is rusty's quiescence protocol PR
13:26 < niftynei> #topic BOLT 2: quiescence protocol
13:26 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/869
13:27 < niftynei> t-bast gave it a review about a month ago
13:27 < michaelfolkson> A definition of "quiescence" is probably in order first off :)
13:27 < rusty> OK, the idea is to ensure both sides' commitment txs are symmetrical, and stay that way (no changes in flight)
13:27 < BlueMatt> michaelfolkson: see spec
13:27 < rusty> OK, I've implemented this.  It's now slightly asymmetrical, in that one side proposes the other accepts: if they both propose at the same time, opener wins by tiebreak.
13:28 < rusty> (This is useful for splice, where the "initiator" is the one who's proposing the splice).
13:29 < rusty> It's pretty damn simple, really.  Kind of a subset of what we do when shutdown occurs (in that case, there must be no HTLCs present either: here there can be HTLCs).
13:29 < BlueMatt> rusty: do you intend to have a leave-stfu-mode message? or that comes via other things?
13:29 < BlueMatt> (and disconnection)
13:29 < rusty> BlueMatt: yeah, the splice draft defines it to end when splice negotiation is complete.
13:30 < rusty> Since quiescing isn't very useful unless you're going to *do* something, it reads a bit unfinished as is
13:30 < BlueMatt> yea, ok, maybe mention that in rationale. 
13:30 < BlueMatt> about initator, does it matter? cant you just figure that out in the actual splice protocol or so?
13:31 < rusty> BlueMatt: you could, but in practice it's the same one who requested quiescence, and adding it to quiescence is easier.
13:31 < BlueMatt> yea, ok
13:31 < rusty> (Like, trivial: if it's a reply, don't set the flag)
13:31 < BlueMatt> should the loses-the-tiebreaker node respond with a stfu-0?
13:32 < BlueMatt> in either case can we more concretely specify that?
13:32 < rusty> BlueMatt: I think that's overkill, though it's important to make sure we test this (easy with lnprototest)
13:32 < BlueMatt> ie "we are considered in quiscence mode when we get a stfu-1 as well"
13:32 < BlueMatt> just to make it super explicit
13:32 < BlueMatt> I'm fine with either answer, just write it down :)
13:33 < rusty> BlueMatt: indeed, it should explicitly say "once you've sent and received, we're quiescent".
13:34 < rusty> (It only says that on the receiver side, it should on the sender too)
13:34 < rusty> OK, two updates then.  Anything else?
13:35 < rusty> Oh, and note that it does not have a feature bit!  Was planning on implying it by splice.
13:35 < rusty> (Perhaps, in future, anything else which wants it, like upgrade protocol)
13:36 < niftynei> #action rusty to update spec; mention lack of leave-stfu in rationale + clarify initiator selection
13:36 < rusty> niftynei: thanks!
13:36 < rusty> (Next PR is update-protocol, which is a bit more exciting!)
13:37 < niftynei> (not having a feature bit sounds similar to the tx construction protocol -- implicit in embedded workflow, so to speak)
13:37 < niftynei> ok let's move on
13:37 < rusty> https://github.com/lightningnetwork/lightning-rfc/pull/868 ?
13:37 < niftynei> #topic bolt 2: upgrade protocol on reestablish 
13:37 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/868
13:38 < rusty> OK, so this is implemented now, so I know it's sane!
13:38 < rusty> We support option_static_remotekey upgrade, which is pretty neat.
13:38 < rusty> I stole roasbeef's idea of "channel types" explicitly; they're just a set of feature bits.
13:40 < rusty> Opener (random tiebreaker that she is) says "here's the type of channel I want" in reconnect, and the other side says "here's the type we are, and here are the possible upgrades".  If you're quiescent, and if "desired channel" is in "possible upgrades", you're upgraded.  Otherwise you're "current type" still.
13:41 < rusty> This is robust against reconnections and other changes, and message loss.
13:41 < niftynei> that seems nicely lightweight imo
13:42 < rusty> The "channel type" can be nicely reused to put a TLV in opening messages later, as roasbeef suggested, so you can choose explicitly what channel features you want rather than assumiing that the latest features are best.
13:42 < rusty> Oh, and ofc, you can quiesce, if you weren't quiescent, then reconnect, if you want to force an upgrade (say, if next version won't support the old channel type)
13:43 < rusty> Implmentation note: we had to change "option_static_remotekey" in our db internally from a boolean, to a pair of commitment numbers (local and remote).
13:44 < rusty> So we know, based on commitment number, how to handle it onchain.  Simple thing though.
13:44 < rusty> Any questions?
13:45 < sstone> how does upgrading channels impact the handling of revoked commit txs ? is the change you mention above enough ? 
13:45 < rusty> If not, I'll grab features 34/35, and imply support for quiescence.
13:46 < rusty> sstone: yeah, that change is sufficient.  We also have handling for "unknown" commitment txs, which have to be careful to handle both static remotekey and not (this is for future commitments, where we rolled back our db, so it's a minor point).
13:46 < rusty> (Since commitment number is encoded in the tx, it's a simple lookup)
13:47 < sstone> thanks
13:47 < niftynei> eltoo fixes this?? ;)
13:48 < rusty> #action rusty to put feature bit into the PR, make quiescence depend on it.
13:48 < rusty> (I don't know if I can action or not, actually)
13:48 < rusty> Next?
13:48 < niftynei> #action what rusty said ;)
13:49 < niftynei> jk
13:49 < niftynei> #action rusty to put feature bit into the PR, make quiescence depend on it.
13:49 < niftynei> next is 867, which is a draft
13:50 < niftynei> let's skip it and go to 866
13:50 < niftynei> #topic proposal: added funding timeout recovery proposal (KEYOLO)
13:50 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/866
13:51 < BlueMatt> didnt we discuss this last time or two times ago and decide against the keyolo variant (after having been weakly in favor the week before)?
13:51 < BlueMatt> i had thought there was rough consensus against keyolo
13:51 < BlueMatt> in favor of sighash any
13:51 < niftynei> (note that the discussion is over on #854)
13:51 < niftynei> https://github.com/lightningnetwork/lightning-rfc/pull/854
13:51 < rusty> BlueMatt: indeed, we should note that and close this one.
13:52 < niftynei> thanks for that context BlueMatt, ok let's keep going then.
13:52 < niftynei> #action close #866 in favor of #854
13:53 < niftynei> moving on then
13:53 < niftynei> #topic clarify about length of an `r` field in invoice 
13:53 < niftynei> #link <BlueMatt> didnt we discuss this last time or two times ago and decide against the keyolo variant (after having been weakly in favor the week before)?
13:53 < niftynei> <BlueMatt> i had thought there was rough consensus against keyolo
13:53 < niftynei> oops
13:53 < niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/865
13:55 < rusty> I think this is wrong?  Data length is in 5-words, so it's actually max 5x1024 bits.
13:56 < rusty> Commented on issue
13:56 < niftynei> thanks rusty
13:57 < niftynei> we've got about 5 minutes left
13:57 < niftynei> the next up PR is rusty's splice draft
13:57 < niftynei> should we cover something else?
13:58 < rusty> niftynei: hmm, not much progress on splice, I'm going to circle back after the next c-lightning release.
13:58 < rusty> (Which is in a week or two!)
13:58 < niftynei> fact
13:58 < niftynei> *facts
14:00 < niftynei> i got a few questions at the conference this past weekend about rendezvous routing 
14:01 < niftynei> does anyone have an update on that proposal?
14:02 < rusty> niftynei: unf cdecker is sailing and t-bast is training, so maybe we need to defer?  Trampoline and rr would be good to get back to!
14:03 < niftynei> ok, i think that's a wrap then
14:03 < niftynei> #endmeeting
14:03 < lndev-bot> Meeting ended Mon Jun  7 21:03:20 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:03 < lndev-bot> Minutes:        https://lightningd.github.io/meetings/jun_7_lightning_spec_chat/2021/jun_7_lightning_spec_chat.2021-06-07-20.07.html
14:03 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/jun_7_lightning_spec_chat/2021/jun_7_lightning_spec_chat.2021-06-07-20.07.txt
14:03 < lndev-bot> Log:            https://lightningd.github.io/meetings/jun_7_lightning_spec_chat/2021/jun_7_lightning_spec_chat.2021-06-07-20.07.log.html
14:03 < rusty> niftynei: thanks for chairing!
14:03 < niftynei> anytime! :)
14:03 < niftynei> ok, see you all in two weeks TM
14:04 -!- AaronvanW [~AaronvanW@65.195.240.38] has joined #lightning-dev
14:04  * jkczyz waves
14:06 < sstone> thanks everyone!
14:06 -!- sstone [~sstone@user/sstone] has quit [Quit: Leaving]
14:15 < rusty> lndev-bot, ajtowns: I still get a 404 for the bot links :(
14:15 < lndev-bot> rusty: Error: "ajtowns:" is not a valid command.
14:20 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds]
14:24 -!- AaronvanW [~AaronvanW@65.195.240.38] has quit [Remote host closed the connection]
14:32 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 245 seconds]
14:33 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
14:37 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #lightning-dev
14:40 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 244 seconds]
14:40 -!- lukedashjr is now known as luke-jr
14:42 -!- major1 [~major@gateway/tor-sasl/major] has quit [Remote host closed the connection]
14:42 -!- major1 [~major@gateway/tor-sasl/major] has joined #lightning-dev
15:04 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 250 seconds]
17:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:12 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
18:27 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
18:28 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
19:01 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
19:05 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev
21:36 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 264 seconds]
21:49 -!- belcher [~belcher@user/belcher] has joined #lightning-dev
--- Log closed Tue Jun 08 00:00:32 2021