--- Log opened Mon Jan 17 00:00:32 2022 00:45 -!- greypw254 [~greypw2@grey.pw] has joined #lightning-dev 02:04 -!- kexkey [~kexkey@static-198-54-132-171.cust.tzulo.com] has quit [Ping timeout: 240 seconds] 02:06 -!- kexkey [~kexkey@static-198-54-132-123.cust.tzulo.com] has joined #lightning-dev 03:02 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 03:04 -!- luke-jr [~luke-jr@user/luke-jr] has joined #lightning-dev 03:18 -!- geyaeb3 [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Ping timeout: 276 seconds] 03:19 -!- geyaeb3 [~geyaeb@gateway/tor-sasl/geyaeb] has joined #lightning-dev 03:30 -!- bairen [~bairen@gateway/tor-sasl/bairen] has quit [Remote host closed the connection] 03:31 -!- bairen [~bairen@gateway/tor-sasl/bairen] has joined #lightning-dev 03:34 -!- geyaeb3 [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Ping timeout: 276 seconds] 03:36 -!- geyaeb3 [~geyaeb@gateway/tor-sasl/geyaeb] has joined #lightning-dev 05:05 -!- bitdex_ [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:24 -!- jespada [~jespada@87.74.36.188] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:58 -!- jb55 [~jb55@user/jb55] has joined #lightning-dev 07:42 -!- jespada [~jespada@87.74.36.188] has joined #lightning-dev 09:02 < cdecker[m]> Today's a US holiday, how many people are planning to join the meeting? Shall we do a project update round like before the holidays, or shall we try a regular spec meeting today? 09:02 < BlueMatt[m]> I'm around. 09:06 < cdecker[m]> Ok, perfect 09:14 < realtbast[m]> I'm around as well 10:12 -!- xraid [~xraid@185.176.246.67] has joined #lightning-dev 10:12 -!- xraid [~xraid@185.176.246.67] has quit [Client Quit] 10:16 -!- xraid [~xraid@185.176.246.67] has joined #lightning-dev 10:30 -!- arik [sid402902@id-402902.lymington.irccloud.com] has joined #lightning-dev 10:48 -!- t-bast [~t-bast@user/t-bast] has joined #lightning-dev 10:50 < BlueMatt[m]> are we doing jitsi? 10:51 < t-bast> I guess we can, unless you'd rather stick to IRC? 10:51 < t-bast> We're probably going to be a small crowd today 10:51 < cdecker[m]> Might not join that one, still finishing dinner :-) 10:51 < BlueMatt[m]> heh, okay, irc it is 10:51 < cdecker[m]> #endmeeting 10:52 < t-bast> xD 10:52 < cdecker[m]> We might still be running in last weeks meeting 10:52 < cdecker[m]> t-bast: try saying #endmeeting :-) 10:52 < t-bast> #endmeeting 10:52 < lndev-bot> t-bast: Meeting ended at 2022-01-17T18:52+0000 10:52 < lndev-bot> t-bast: Raw log: https://lightningd.github.io/meetings/20220103-1905.log.html 10:52 < lndev-bot> t-bast: Minutes: https://lightningd.github.io/meetings/20220103-1905.html 10:53 < BlueMatt[m]> lollllllll 10:53 < cdecker[m]> rofl 10:53 < t-bast> Oh you're right, I forgot to do it last time :/ 10:53 < t-bast> That mix of jitsi and IRC... 10:53 < cdecker[m]> And now I can upload the meeting 10:53 < BlueMatt[m]> welp, got a nice long meeting in last week 10:53 < t-bast> That was intense 10:53 < BlueMatt[m]> 😅 10:54 < t-bast> We have quite an open agenda tonight, apart from #942 that was updated since last time, we only have "long term" PRs to discuss (and #941 which is a text clarification) 10:54 < BlueMatt[m]> do hope rusty shows up, I want to chat about websockets and how to handle tls websockets 10:54 < t-bast> I think rusty is on vacation, isn't he? 10:54 < BlueMatt[m]> oh, damn 10:54 < arik> would there be some lightning-specific deviation for TLS websockets? 10:54 < cdecker[m]> Yep he's on pto 10:55 < BlueMatt[m]> well we can still talk about it, makes it even easier since none of us have to do the work to update the PR :) 10:55 < t-bast> I haven't dug into this at all, I'm quite a websocket n00b! 10:55 < BlueMatt[m]> arik: no, but the current PR only proposes a way to announce websocket support in the gossip, not secure-websocket support (which would need a domain name, not just an IP) 10:56 < BlueMatt[m]> re: 919 I think we can take it off the to-hit list - its awaiting author cleanups 10:56 < BlueMatt[m]> and unless someone wants to rewrite it without...🤷‍♂️ 10:56 < BlueMatt[m]> is there a (second) implementation of 910 - early funding_locked? 10:56 < BlueMatt[m]> if not i think its mostly waiting on that, nothing to discuss there either. 10:57 < BlueMatt[m]> 911 - dns hostnames in gossip - is there a second implementation? I think I may have one somewhere. It has acks, just needs cross-impl check, I think. 10:57 < BlueMatt[m]> so not much to talk about either. 10:57 < BlueMatt[m]> there, now we have lots of time for long-term updates, happy t-bast? :p 10:58 -!- seardsalmon [~seardsalm@2605:a601:ab03:5500:9eb:31a7:712e:5589] has joined #lightning-dev 10:58 < cdecker[m]> Nice 👍️ 10:58 -!- ellemouton [~ellemouto@155.93.252.70] has joined #lightning-dev 10:59 < t-bast> #919: agreed, #910: nothing on our side yet, #911 is waiting for a second impl 10:59 < t-bast> I agree this was fast ;) 10:59 -!- oopsydanger [~textual@99-171-190-152.lightspeed.sndgca.sbcglobal.net] has joined #lightning-dev 10:59 < t-bast> #917 has a small thing to discuss 10:59 < t-bast> We have two implementations, but an open question on whether to include the port or not 11:00 < t-bast> See https://github.com/lightning/bolts/pull/917#issuecomment-1008276220 and below 11:00 < cdecker[m]> Paging mschmoock :-) 11:00 < mschmoock> hi 11:00 < mschmoock> just about time 11:00 < t-bast> I don't mind much what option we choose, both have (tiny) pros and cons 11:01 < BlueMatt[m]> hmmmm, I'd think yes include source. I don't have strong feelings about it, though. 11:01 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:411:d78b:69d4:9242] has joined #lightning-dev 11:01 < mschmoock> My opinion is we should include the port... as my comment show 11:01 < BlueMatt[m]> if its random, its not useful because people can't connect, if its non-random, you probably know it. 11:01 < mschmoock> It can be used to detect NAT at least 11:02 < mschmoock> and maybe other things 11:02 < BlueMatt[m]> sure, i guess you know if you see a random port there that the ip reported isn't useful in gossip lol 11:02 < BlueMatt[m]> well, i guess that's not true 11:02 < BlueMatt[m]> nevermind 11:02 < BlueMatt[m]> yea, I dunno, I don't think its very useful there, but if someone wants to include it, sure, whatever 11:03 < BlueMatt[m]> there's no real reason not to include it, as much as I don't really see much of a reason to 11:03 < BlueMatt[m]> so....whatever, author's choice 11:03 < t-bast> Perfect, I feel the same, so let's do whatever mschmoock prefers 11:03 < t-bast> If that means keeping the port, we have two implementations that interop, so we can merge now! 11:03 < cdecker[m]> Sounds good ^^ 11:03 < mschmoock> i prefer with port. other than that details the PR was clear I guess 11:03 < t-bast> Let's make it official with a meeting ;) 11:03 < t-bast> #startmeeting 11:03 < lndev-bot> t-bast: Meeting started at 2022-01-17T19:03+0000 11:03 < lndev-bot> t-bast: Current chairs: t-bast 11:03 < lndev-bot> t-bast: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting 11:03 < lndev-bot> t-bast: See also: https://hcoop-meetbot.readthedocs.io/en/stable/ 11:04 < BlueMatt[m]> t-bast: that seems like a reason to keep it! 11:04 < t-bast> #topic Remote address in init 11:04 < t-bast> #link https://github.com/lightning/bolts/pull/917 11:04 < t-bast> Definitely! We have interop on this PR, anyone wants to hold off before we merge? 11:04 < mschmoock> my first RFC that gets merged :D 11:04 < BlueMatt[m]> cool. rough agreement immediately pre-meeting that there's not much reason to, or not to, include port. existing code and docs includes port, and there's interop, so we should keep it! 11:05 < BlueMatt[m]> t-bast: MERGE ITTTTTTTT 11:05 < BlueMatt[m]> (I say despite not having read it) 11:05 < BlueMatt[m]> okay, now I've read it, ACK 11:05 < mschmoock> hehe :] 11:05 < BlueMatt[m]> done 11:05 < BlueMatt[m]> next topic 11:06 < t-bast> #topic Clarify broadcast requirements 11:06 < t-bast> #link https://github.com/lightning/bolts/pull/942 11:06 < t-bast> We said last time that we should cherry-pick stuff from #932 and add a rationale 11:06 < t-bast> The author has done exactly that 11:06 -!- seardsalmon [~seardsalm@2605:a601:ab03:5500:9eb:31a7:712e:5589] has quit [Quit: Client closed] 11:07 -!- seardsalmon [~seardsalm@2605:a601:ab03:5500:9eb:31a7:712e:5589] has joined #lightning-dev 11:08 -!- gleb745 [~gleb@178.150.137.228] has quit [Ping timeout: 250 seconds] 11:08 < BlueMatt[m]> LGTM 11:08 < BlueMatt[m]> any notes @cdecker? Otherwise I say merge. 11:08 < cdecker[m]> No, looks good to me 11:09 < t-bast> Great, done 11:09 < BlueMatt[m]> okay, if roasbeef has any further comments we can clean it up later, but its pretty trivial 11:09 < BlueMatt[m]> thanks t-bast 11:09 < BlueMatt[m]> movin' at a clip today 11:10 < t-bast> We're on a roll ;) 11:10 < t-bast> Now, let's merge trampoline! 11:10 < t-bast> Aaaand, it's done 11:10 < t-bast> Well, kidding 11:10 < t-bast> There's a clarification PR that has been opened, the author requested some feedback 11:10 < ryanthegentry> lol 11:10 < t-bast> #topic Clarify how we refer to messages 11:10 < t-bast> #link https://github.com/lightning/bolts/pull/941 11:11 < BlueMatt[m]> no real opinion, I don't find it to be in any way confusing - do some of the non-native-english folks? 11:11 < BlueMatt[m]> but, mostly, this kind of copy-edit stuff I just...don't care about, I don't find that it changes readability. 11:12 < t-bast> I never found the current text confusing, so I'm not sure this change is necessary 11:12 < BlueMatt[m]> but if someone feels strongly otherwise, just hit merge, really. 11:12 < cdecker[m]> Can't say I do, but then again I'm used to our nomenclature 11:12 < BlueMatt[m]> I mean if there were messages referred to without backticks, I'd agree 11:12 < BlueMatt[m]> but in backticks? I find it pretty clear 11:13 < vincenzopalazzo> I don't see any difference from before to now, it is only another way to write the same things IMO 11:13 < arik> agree with Matt, backticks make it obvious 11:13 < t-bast> Agreed with vincenzopalazzo 11:14 < BlueMatt[m]> k, lets comment on the pr that it is insufficiently justified and move on 11:14 < mschmoock> I find it more readable 11:14 < t-bast> sgtm 11:14 < t-bast> Let's let people who find this useful enough to justify the change signal that on the PR, otherwise let's move on 11:15 < t-bast> What do you want to discuss next? We've done all the easy topics ;) 11:15 < BlueMatt[m]> mschmoock alright, want to comment on the PR? it looks like rusty's already reviewing it...generally if y'all ack it i'd say its a copy-edit so just merge, and the rest of us will ignore it :) 11:15 < t-bast> If someone wants to raise a topic or ask questions, now is the time! 11:15 < BlueMatt[m]> t-bast lets see, I don't have questions on route-blinding, but I do have a question on onion messages regardign route-blinding 11:15 < BlueMatt[m]> if you'll indulge me 11:15 < t-bast> perfect, let's have at it 11:16 < BlueMatt[m]> oh, not onion messages, actually, offers. I have a feeling I'll get yelled at for this, but it seems offers was cut back somewhat to ensure its "minimal" and let people implement it quickly to get at least base support out in the wild....that said, it still depends on HTLC route blinding, which seems like a substantial additional amount of work on top of its existing onion message dependency. 11:17 < BlueMatt[m]> even if the crypto is the same/reused, handling blinded HTLCs is a lot more complicated than just the crypto itself 11:17 < t-bast> I agree with that 11:17 < mschmoock> BlueMatt[m]: nope nothing to add 11:17 -!- lndev-bot [~limnoria@2a03:b0c0:3:d0::13b1:6001] has quit [Remote host closed the connection] 11:17 < t-bast> I haven't gotten far enough on reviewing offers though 11:17 -!- lndev-bot [~limnoria@2a03:b0c0:3:d0::13b1:6001] has joined #lightning-dev 11:17 < BlueMatt[m]> I guess its really a discussion to be had when rusty is around, but we were doing quarterly dev planning and timeline for offers came up and I figured it was really quick until jkczyz pointed out it relies on route blinding 11:17 < t-bast> I didn't realise it required route blinding to actually pay the retrieved invoice, I thought it was only to fetch the invoice 11:18 < BlueMatt[m]> obviously its a tradeoff, so I'm open to ideas, but it feels like we'd want to ship offers quicker, dunno. 11:18 < jkczyz> from the pathfinding side, it seems having a single blinded route instead of many would at least make that part of the implementation a little easier 11:18 < BlueMatt[m]> t-bast: that was my understanding, based on what jkczyz told me. I admit I didn't read it in detail, only saw that it seemed to be. 11:19 < t-bast> jkczyz: something requires multiple blinding routes atm? 11:19 < BlueMatt[m]> well it can presumably return multiple blinded "last-hops" 11:19 < BlueMatt[m]> err, hop-hints 11:19 < jkczyz> yeah, I thought you could supply multiple blinded path hints in the invoice 11:20 < jkczyz> just as you can do today with non-blinded paths 11:20 < t-bast> Ok, I guess you can, but why does it make it harder that a single one? 11:20 < cdecker[m]> Yeah, that makes it much more usable for nodes that don't announce their channels 11:20 < t-bast> Becuase you don't know if there's blinded overlap? 11:20 < t-bast> And can't know how to split the payment? 11:20 < jkczyz> multiple destinations to potentially route to 11:21 < jkczyz> in the non-blinded world, there's alway a common recipient on all the hints 11:21 < BlueMatt[m]> cdecker[m]: sure, but we're also about to get random SCIDs, so I'm not sure it matters much, unless you're using blinded paths to hide multiple hops 11:22 < t-bast> But this shouldn't change anything though, does it? You can imagine that virtually all introduction points are directly connected to the final recipient (for path-finding purposes) 11:22 < cdecker[m]> In non-blind world we can still route random parts to multiple endpoints by adding non-existent channels as routehints 11:22 < t-bast> From a path-finding's point of view, I'd treat each blinded route as a virtual channel to the recipient (independently of the blinded route actual length) 11:22 < cdecker[m]> Not useful at all, because you can't control who gets how much though 11:22 < BlueMatt[m]> cdecker[m]: sure, but you can't without blinding cause multiple *real* hops to be hidden 11:23 < cdecker[m]> Correct 11:23 < BlueMatt[m]> anyway, I don't really think we can/should decide anything today, but I wanted to raise it, and we should discuss it at the next meeting that has rusty in it. I'm not saying we don't want to move to blinded paths, only that we can likely deploy offers much quicker without. 11:23 < cdecker[m]> And I agree with t-bast, simulating blinded routes as single direct channels is the way to go 11:23 < BlueMatt[m]> and it may be worth the tradeoff to support both, I dunno 11:24 < jkczyz> t-bast: true, we'd essentially have a fake recipient then, I suppose 11:24 < t-bast> jkczyz: that's how I would model it (even though I haven't yet, but eclair shouldn't be too far from starting to work on that part) 11:25 < BlueMatt[m]> anyway, I have no further comments on route blinding/offers/onion messages 11:25 < BlueMatt[m]> so happy to move on 11:26 < BlueMatt[m]> I guess @niftynei isn't here today? 11:26 < t-bast> Agree that it's worth discussing with rusty next time 11:26 < BlueMatt[m]> I do have lots of comments on splicing, but oh well 11:26 < t-bast> Have you looked at dual funding first then? 11:27 < BlueMatt[m]> I have not, no, but I feel like the whole model we have for splicing here is all wrong. 11:27 < BlueMatt[m]> which may inform dual funding 11:27 < t-bast> My main comment is to add an explicit message to cancel a dual funding session 11:27 < cdecker[m]> Not sure where nifty is either 11:27 < t-bast> Hah, that's interesting, can you detail why BlueMatt[m]? 11:27 < t-bast> I'll start working on dual funding and splicing someday soon, so I'm interested in your comments there 11:27 < BlueMatt[m]> I think its a rather critical feature for splicing that, in a world where one node is always-online (ie LSP) and one is often not online (ie mobile) the always-online node should be able to splice-out unilaterally 11:28 -!- oopsydanger [~textual@99-171-190-152.lightspeed.sndgca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:28 < cdecker[m]> Uff, how should that work? 11:28 < BlueMatt[m]> right it'd be tricky, you'd need to have the splice output be revocable, and pre-sign transactions at each new commitment 11:28 < BlueMatt[m]> but that's really not that crazy 11:29 < BlueMatt[m]> and I think its a really critical feature for liquidity management on LSPs 11:29 < BlueMatt[m]> either we build it or someone else will 11:29 < t-bast> If that's achievable without making it too complex, I think it's a desirable feature indeed 11:29 < BlueMatt[m]> and ideally it be in-protocol 11:29 < cdecker[m]> I mean I don't see a way that we can offer anything shorter to splice out than the unilateral timeout, since that by definition is the time we give a counterparty to react to any unilateral action 11:29 < t-bast> You'd presign many transactions for many spliced-out amounts, is that it? 11:29 < BlueMatt[m]> yes, but I think even that is a win 11:29 < BlueMatt[m]> because its not unrealistic for a mobile node to not be online for 3 weeks 11:30 < BlueMatt[m]> users tend to do that sometimes... 11:30 < cdecker[m]> Yeah, but how is that different than a unilateral close? 11:30 < BlueMatt[m]> cdecker[m]: because you wouldn't have to re-open? 11:31 < BlueMatt[m]> instead of broadcasting the commitment you'd have a "2-layer" commitment where you duplicate the commitment hanging off a splice-out 11:31 < t-bast> And you don't touch the mobile user's funds, they don't need to claim their part of the channel on-chain, which is quite important 11:31 < BlueMatt[m]> so its a lot more state to store, which sucks 11:31 < BlueMatt[m]> but its a pretty huge win 11:31 < cdecker[m]> Right, so a time-delayed splice with timeout = unilateral timeout, I see 11:31 < cdecker[m]> I mean I see how you'd do it in eltoo, but not in LN-penalty without adding loads of penalty cases 11:31 < BlueMatt[m]> so replace commitment with splice-out that has a splice-out revocable output with CSV and a to-2nd-layer-commitment output 11:32 < BlueMatt[m]> cdecker[m]: I think its just one layer of transactions. without eltoo you'd need a full duplication of the commitment tx and signatures, though :( 11:32 < cdecker[m]> But really it sounds like a relatively orthogonal thing to the current interactive splicing 11:32 < BlueMatt[m]> I mean if you build this, you'd drop the interactive one 11:32 < BlueMatt[m]> if we may end up with this anyway, lets avoid duplicate features :) 11:33 < BlueMatt[m]> that do the same thing via different code paths 11:33 < cdecker[m]> No, these need to be time-delayed, which breaks a whole lot of use-cases (instant swaps) 11:33 -!- yakshaver123 is now known as yakshaver 11:33 < t-bast> A difference is that the interactive splice may let you dynamically choose the amount you take out based on any kind of business logic that makes sense instead of splicing out you whole to_local amount, right? 11:33 < BlueMatt[m]> does the current splice proposal require no HTLCs until the splice tx is confirmed? 11:34 < t-bast> I'm thinking about interactions with liquidity_ads for example (another very important thing for LSP) 11:34 < cdecker[m]> Not sure, need to re-read the proposal 11:34 < BlueMatt[m]> t-bast: sure, presumably non-interactive-splice would have a fixed amount, though I don't see why you wouldn't be able to use not-the-full-to_self. You could select that, of course. 11:34 < t-bast> BlueMatt[m]: IIRC you don't need to wait for the splice to be confirmed to resume forwarding HTLCs in the current splice proposal, but I could be wrong 11:35 < cdecker[m]> If we go with the current proposal it's just "add a csv timeout to the spliced output" and we can seamlessly build this time-delayed unilateral version on top 11:35 -!- oopsydanger [~textual@99-171-190-152.lightspeed.sndgca.sbcglobal.net] has joined #lightning-dev 11:36 < cdecker[m]> Correct, at least forwarding is always possible, even before full confirmation 11:36 < cdecker[m]> The funds never left the multi-sig, so no rugpull possible :-) 11:36 -!- oopsydanger [~textual@99-171-190-152.lightspeed.sndgca.sbcglobal.net] has quit [Client Quit] 11:36 < BlueMatt[m]> right, i guess splice-in is more complicated? 11:36 -!- oopsydanger [uid536846@id-536846.ilkley.irccloud.com] has joined #lightning-dev 11:37 < cdecker[m]> That needs two parallel states to be maintained, yes (pre-splice, post-splice) 11:37 < cdecker[m]> Once we have reached funding depth, we can forget pre-splice and all associated state 11:37 < BlueMatt[m]> right 11:38 < BlueMatt[m]> and its only the ability to "cancel" a splice-out and include those funds back in the channel that makes it impossible to do without a revocable output and all the machinery to make it unilateral :/ 11:38 < BlueMatt[m]> I guess if you just make the output revocable then you dont need a duplicate commitment transaction, right? 11:39 < BlueMatt[m]> so splice-out -> unilateral splice-out is a pretty trivial change, you just need the ability to "cancel" a splice-out and never broadcast, and all the splice outputs have to be revocable from the start? 11:39 < cdecker[m]> That's probably nifty's territory, I'll overlook something for sure :-( 11:40 < BlueMatt[m]> yea, fair. anyway, I wanted to raise this. I feel like its a major feature and needs careful consideration before we plow ahead with splicing 11:40 < cdecker[m]> The funds that remain in the channel are on revocable outputs, yes 11:40 < BlueMatt[m]> if we have a model that can be adapted trivially to unilateral splice-out later I'm happy 11:40 < BlueMatt[m]> cdecker[m]: no, I meant to change to a splice-out model that is "cancel"-able, you'd need the splice outputs themselves to be revocable 11:41 < cdecker[m]> Well, predictive splicing seems a major complication if you ask me, and is going to make the state machine even more inscrutable 11:41 < BlueMatt[m]> maybe? I think it should be a requirement for any splicing proposal that we are either (a) confident that it cannot be done simply or (b) confident the splicing proposal can be simply amended to "predictive splicing" 11:42 < BlueMatt[m]> and I'm not all convince (a) is true 11:42 < BlueMatt[m]> but I think (b) is likely true 11:42 < BlueMatt[m]> depending on exactly how its structured 11:43 < cdecker[m]> Ok, happy to discuss actual proposals, until then we have the current splice proposal :-p 11:43 < BlueMatt[m]> Separate topic, quick update on private gossip, planning on chatting with a few cryptographer folks to get a more exact understanding of what the options are for ZKPs today. Sadly most of the bitcoin community cryptographers seem to have stopped paying as much attention to the latest-and-greatest here, sadly. Will have an update with more hopefully next meeting, either "nope, nothing works" or maybe something concrete, will need to 11:43 < BlueMatt[m]> chat with rusty too, though. 11:44 < BlueMatt[m]> that's all the random ideas and soapboxy complaints I have for this week, any other topics? 11:44 < cdecker[m]> Excellent ^^ 11:44 < ryanthegentry> while we're here, signmessage bLIP? 11:44 < cdecker[m]> Gotta run off in a couple of minutes 11:44 < ryanthegentry> responded to you BlueMatt[m]: https://github.com/lightning/blips/pull/8#issuecomment-1014817414 11:44 < t-bast> Great, I agree we can spend time on more exploration of the design space for splicing whenever some of us are ready to dive seriously into it 11:44 < BlueMatt[m]> I'm not sure why it can't/shouldnt just be a BOLT, nor why we can't just merge it within a day of the PR being open, but we can discuss further on the PR. 11:45 < BlueMatt[m]> ryanthegentry: "Hmm... given that this signmessage rpc already exists in the wild across all implementations, I don't think it qualifies as a "New feature intended to be universally deployed"." - hmm? I'd call it the exact opposite - given it already exists in the wild across all implementations, I think it very specifically qualifies as a feature which not only should be, but *is* "universally deployed" 11:46 < ryanthegentry> well but it's not a new feature. It already exists and has for years 11:46 < BlueMatt[m]> sure, but we don't generally discriminate if something has code or not? 11:46 < t-bast> I guess it could be a BOLT, it would probably need more work on the "rationale" part for the design decisions since there's no history around it 11:47 < t-bast> (if we want to use that exact version of sign/verify) 11:47 < vincenzopalazzo> t-bast: I agree to be a bold 11:47 < ryanthegentry> the original purpose of the bLIPs was to get folks to document "app layer best practices" that were being done in the wild and I think this is the perfect example of that 11:47 < t-bast> I'm not sure Kixunil would spend the time to champion such a BOLT since he wasn't involved in the design of the feature - we'd need someone to do that (roasbeef?) 11:47 < BlueMatt[m]> t-bast I don't see any problem with that sign/verify format? I guess it could have more motivation in the doc but... 🤷‍♂️ 11:47 < ryanthegentry> I think the discussion of whether it should be a BOLT is separate 11:48 < BlueMatt[m]> t-bast: why can't he champion it? I mean unless someone has a *better* sign/verify they want to propose...... 11:48 < t-bast> I need to have another look at the recovery ID part, that's the trick part that looks like black magic when you first see it 11:48 < ryanthegentry> maybe there's a path where this gets merged as a bLIP, people decide it should be a BOLT and perhaps redesigned, and then the bLIP is deprecated by pointing to a new BOLT? 11:48 < BlueMatt[m]> ryanthegentry: I wouldn't call this an "application best practice" usually a "best practice" document (at least in the IETF sense) is about configuration parameters and certain sharp edges that users should avoid. This is not that. 11:49 < t-bast> BlueMatt[m]: let's ask him on the PR, if he agrees to champion it that would be great 11:49 < BlueMatt[m]> ryanthegentry: lets not put the cart ahead of the horse here....is there a reason to redesign this? I don't see why. 11:49 < cdecker[m]> Yeah, I think the bolt/blip discussion is a different one, it's a good blip to have and we can always later upgrade it 11:49 < BlueMatt[m]> fair, its missing sections required in the bLIP, then, though, including one on "why the given feature is not intended to be universal and why it's still a good idea as a non-universal protocol." 11:50 < BlueMatt[m]> which the author is welcome to write, but I have a feeling may be slightly...defecient, hence why I suggest it may be a BOLT :p 11:50 < ryanthegentry> I think in general the purpose of bLIPs is to provide an easy way for people to document underdocumented features, and this is a great example of one 11:51 < BlueMatt[m]> I mean we can reopen the debate as to "what are bLIPs for" but that is...quite a rabbit hole, and one in which there was already enough disagreement 11:51 < BlueMatt[m]> hence I'm somewhat hesitant to relitigate that :p 11:52 < BlueMatt[m]> but suffice to say I don't think we should be documenting things which are likely to seek universality as bLIPs, that's caused plenty of problems before... 11:52 < BlueMatt[m]> (and, importantly, we've been moving much faster on BOLT merging!) 11:52 < cdecker[m]> It's not like we depend on any of these signatures in the bolts, only on application level 11:52 < BlueMatt[m]> so I'm really hoping we can cut down on any hesitancy towards "just doing things as BOLTs" by Just Merging It 11:52 < ryanthegentry> what problems has the signmessage API not being a BOLT for the last 2+ years caused? 11:53 < cdecker[m]> So better not scope-creep the bolts I say 11:53 < ryanthegentry> cdecker[m]: agreed 11:53 < BlueMatt[m]> ryanthegentry: I don't think it has, precisely because its universally implemented and consistent across implementations, which I understood by that phrasing in bLIPs as being the distinction between BOLTs and bLIPs :) 11:54 < cdecker[m]> The bolts are our promise to our peers, while the blips are our promise/requirements to the application, maybe? 11:54 < BlueMatt[m]> I mean then we should move invoices to bLIPs 11:55 < cdecker[m]> True, it's tether to the rest of the spec is the feature negotiation I think 11:55 -!- jarthur [~jarthur@2603-8080-1540-002d-8926-a20e-7ef6-caff.res6.spectrum.com] has joined #lightning-dev 11:55 < BlueMatt[m]> but bLIPs are allowed to have features in them too 11:55 < BlueMatt[m]> there's even reserved parts of the features! :p 11:55 < cdecker[m]> Yeah, I mean the features being a bolt concept is why invoices probably belongs where it is 11:56 < BlueMatt[m]> but my point is features is not inherently a bolt concept? we'd be perfectly justified to include feature information in the signed message 11:56 < BlueMatt[m]> cause, like, upgradability and stuff 11:57 < BlueMatt[m]> that seems like a very tenuous line to draw for bolts-vs-blips 11:57 < cdecker[m]> Anyway, not a good analogy then, let's stick with signmessage blip proposals for now 11:58 < ryanthegentry> is the signmessage API "universally implemented and consistent across implementations" since lnd alone uses zbase32 for encoding? 11:59 < cdecker[m]> c-lightning also displays the zbase32 encoding, but introducing that just for this feature is weird 11:59 < BlueMatt[m]> wait, am I confused? I understood that every implementation had the same sign/veryify message? 11:59 < ryanthegentry> oh sorry, only ACINQ doesn't use zbase32 encoding 11:59 < ryanthegentry> https://github.com/ACINQ/eclair/issues/2121#issuecomment-1004615247 11:59 < BlueMatt[m]> we had to merge zbase32 and fix a bunch of bugs in a zbase32 impl to make it work :( 12:00 -!- ellemouton [~ellemouto@155.93.252.70] has quit [Quit: leaving] 12:00 < t-bast> Except the encoding, we didn't want to add a dependency on this weird zbase32 encoding so we just use hex 12:00 < ryanthegentry> the bLIP says: "Multiple implementations encode the signature in zbase32 when presenting it to the user. At the time of writing Eclair uses hex instead because zbase32 is uncommon. This document does not mandate any specific user-facing encoding." 12:00 < t-bast> And let the user figure out how to convert to/from zbase32 12:00 < ryanthegentry> which I think is good 12:01 < BlueMatt[m]> ah, okay, so maybe we take the signmessage bLIP with a discussion section that says its a bad idea and we need to drop zbase32, and then we do bech32m as a signmessage bolt 12:01 < cdecker[m]> I'd so much prefer hex-encoding, but I think keeping it out of the blip sounds good to me 12:01 < BlueMatt[m]> "this isnt a candidate for universality because zbase32 is a bad idea anyway, and forcing a new encoding sucks" 12:01 < ryanthegentry> lol 12:01 < t-bast> Can you explain why you'd want bech32m instead of just hex? 12:01 < t-bast> Or any fancy encoding? 12:01 < BlueMatt[m]> oh, hex sounds fine too 12:01 < BlueMatt[m]> bech32m is a bit shorter, I thought? but, yea, just do hex, whatever. 12:02 < BlueMatt[m]> ryanthegentry: to be fair, it feels like defining a signmessage bLIP without a user-facing encoding is also...strange af? 12:02 < t-bast> I think that if it were a BOLT, we wouldn't specify an encoding at all, would we? We'd just manipulate bytes? 12:02 < BlueMatt[m]> t-bast I figured we'd at least recommend something? 12:03 < t-bast> That's why I tend to go hex, which is universally supported even though it's not very compact 12:03 < cdecker[m]> Well, there is the invoices precedent where we very much define a representation format 12:03 < BlueMatt[m]> so maybe a BOLT that defines the signmessage stuff itself, recommend hex, and a bLIP that describes how some nodes accept and generate zbase32 but that is now discouraged and verifymessage must support hex? 12:03 < t-bast> If you have a message in there, I don't think the size of the signature will really be an issue 12:04 < BlueMatt[m]> right 12:04 < BlueMatt[m]> also what cdecker said - we really should define a format, its strange not to 12:04 < t-bast> cdecker[m]: that's because invoices are something of their own, a signature goes with something else (the message) 12:04 < BlueMatt[m]> and leads to yet more lightning ecosystem fragmentation :( 12:04 < BlueMatt[m]> t-bast: its also because users want to exchange these things between each other, which kinda mandates they be encoded in compatible forms :) 12:04 < t-bast> then just hex at the BOLT level? I don't think we'd want to pull a dependency on zbase32 in the bolts, do we? 12:05 < t-bast> Why did roasbeef pick this uncommon encoding in the first place? 12:05 < BlueMatt[m]> that sgtm, we'd say hex in the bolt and the bLIP could say "accept zbase32 for compatibility, but MUST accept hex and SHOULD generate hex" 12:05 < t-bast> BlueMatt[m]: but if it's exchanged over the lightning transport, it would be just bytes in a tlv, right? 12:05 < cdecker[m]> sgtm 12:05 < t-bast> sgtm for your proposal 12:06 < ryanthegentry> BlueMatt[m]: sgtm, do you want to comment that on the PR for Kixunil to add? 12:06 < t-bast> I'll have to drop off soon though, shall we ask Kixunil if he would create a PR for such a BOLT? 12:06 < BlueMatt[m]> sure, I'll comemnt on the pr 12:06 < t-bast> :+1: 12:06 < ryanthegentry> ty 12:07 < t-bast> Awesome, let's close the meeting then! 12:07 < BlueMatt[m]> should we call it a successful meeting, then? 12:07 < t-bast> #endmeeting 12:07 < ryanthegentry> much success 12:07 < BlueMatt[m]> multiple merged PRs and common ground on a contentious issue? 12:07 < BlueMatt[m]> crazy 12:07 < t-bast> Loved it ;) 12:07 < t-bast> But endmeeting doesn't work...I killed the bot cdecker[m] :( 12:07 < cdecker[m]> Sounds good 12:07 < cdecker[m]> That was quite productive ^^ 12:08 < t-bast> It's exhausted after the previous 14-day long meeting 12:08 < cdecker[m]> And the bot crapped out again... 12:08 < BlueMatt[m]> heh 12:08 < cdecker[m]> Sorry for that 12:08 < vincenzopalazzo> lol 12:08 < t-bast> Thanks for your time everyone! 12:09 < cdecker[m]> I need to write my own, this thing is way too flaky 12:09 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:411:d78b:69d4:9242] has quit [Quit: Client closed] 12:09 < BlueMatt[m]> grep + bash is your friend.... 12:09 < BlueMatt[m]> althought at this point half the meeting is via matrix anyway 12:09 < BlueMatt[m]> at least today it seemed like about half the participants were matrix-native with reaction emoji lol 12:10 -!- xraid [~xraid@185.176.246.67] has quit [Quit: Client closed] 12:10 -!- t-bast [~t-bast@user/t-bast] has quit [Quit: Leaving] 12:10 -!- xraid [~xraid@185.176.246.67] has joined #lightning-dev 12:10 < vincenzopalazzo> copy and past just works to get the meeting log with matrix :) 12:10 < BlueMatt[m]> heh, true 12:11 < vincenzopalazzo> Have a good day/night guys, see you in 2 weeks 12:16 -!- timokrgr [~timokrgr@2a01:4f8:241:23a0::2] has joined #lightning-dev 12:19 -!- kexkey [~kexkey@static-198-54-132-123.cust.tzulo.com] has quit [Ping timeout: 250 seconds] 12:33 -!- kexkey [~kexkey@89.36.78.203] has joined #lightning-dev 12:43 -!- xraid [~xraid@185.176.246.67] has quit [Quit: Client closed] 12:44 -!- kexkey [~kexkey@89.36.78.203] has quit [Ping timeout: 256 seconds] 12:44 -!- kexkey [~kexkey@37.120.205.219] has joined #lightning-dev 13:07 -!- gleb745 [~gleb@178.150.137.228] has joined #lightning-dev 13:18 -!- seardsalmon [~seardsalm@2605:a601:ab03:5500:9eb:31a7:712e:5589] has quit [Quit: Client closed] 14:16 -!- kexkey [~kexkey@37.120.205.219] has quit [Ping timeout: 250 seconds] 14:22 -!- gleb745 [~gleb@178.150.137.228] has quit [Ping timeout: 256 seconds] 14:26 -!- kexkey [~kexkey@89.36.78.10] has joined #lightning-dev 15:02 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 250 seconds] 15:40 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...] 15:58 -!- gleb745 [~gleb@178.150.137.228] has joined #lightning-dev 16:15 -!- jb55 [~jb55@user/jb55] has joined #lightning-dev 16:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:35 -!- sr_gi [~sr_gi@47.61.62.163] has quit [Read error: Connection reset by peer] 16:35 -!- sr_gi [~sr_gi@47.61.62.163] has joined #lightning-dev 16:36 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 268 seconds] 16:41 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #lightning-dev 17:19 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 17:24 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 276 seconds] 17:56 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 240 seconds] 18:28 -!- jb55 [~jb55@user/jb55] has joined #lightning-dev 18:54 -!- jarthur [~jarthur@2603-8080-1540-002d-8926-a20e-7ef6-caff.res6.spectrum.com] has quit [Ping timeout: 240 seconds] 18:57 -!- jarthur [~jarthur@2603-8080-1540-002d-8926-a20e-7ef6-caff.res6.spectrum.com] has joined #lightning-dev 19:01 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 256 seconds] 19:30 -!- vertion [~vertion@gateway/tor-sasl/vertion] has joined #lightning-dev 19:48 -!- jarthur_ [~jarthur@2603-8080-1540-002d-c475-c516-38bc-5933.res6.spectrum.com] has joined #lightning-dev 19:49 -!- jarthur [~jarthur@2603-8080-1540-002d-8926-a20e-7ef6-caff.res6.spectrum.com] has quit [Ping timeout: 240 seconds] 20:59 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 21:00 -!- jb55 [~jb55@user/jb55] has joined #lightning-dev 21:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Client Quit] 21:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:43 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 268 seconds] 22:24 -!- geyaeb3 [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Quit: WeeChat 3.4] 22:25 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined #lightning-dev 23:25 -!- vertion [~vertion@gateway/tor-sasl/vertion] has quit [Remote host closed the connection] 23:46 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev --- Log closed Tue Jan 18 00:00:33 2022