--- Log opened Mon May 10 00:00:50 2021 01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:12 -!- belcher_ is now known as belcher 01:32 -!- orccoin [~Rheanna@218.78.88.163] has quit [Remote host closed the connection] 01:33 -!- fiatjaf [~fiatjaf@2804:7f2:298d:1e20:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 250 seconds] 01:34 -!- orccoin [~Rheanna@101.91.180.110] has joined #lightning-dev 01:35 -!- fiatjaf [~fiatjaf@2804:7f2:2a8f:67a2:ea40:f2ff:fe85:d2dc] has joined #lightning-dev 02:14 -!- gleb [~gleb@178.150.137.228] has joined #lightning-dev 02:19 -!- awesome_doge [~Thunderbi@2001-b400-e275-cc71-4d79-5fcb-c094-aaf0.emome-ip6.hinet.net] has joined #lightning-dev 02:22 -!- orccoin [~Rheanna@101.91.180.110] has quit [Remote host closed the connection] 02:22 -!- orccoin [~Rheanna@101.89.154.192] has joined #lightning-dev 02:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 02:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 03:11 -!- orccoin [~Rheanna@101.89.154.192] has quit [Remote host closed the connection] 03:14 -!- orccoin [~Rheanna@101.91.240.201] has joined #lightning-dev 03:31 -!- contrapumpkin [~copumpkin@unaffiliated/copumpkin] has joined #lightning-dev 03:32 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 240 seconds] 04:01 -!- orccoin [~Rheanna@101.91.240.201] has quit [Remote host closed the connection] 04:03 -!- awesome_doge [~Thunderbi@2001-b400-e275-cc71-4d79-5fcb-c094-aaf0.emome-ip6.hinet.net] has quit [Ping timeout: 250 seconds] 04:03 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 260 seconds] 04:04 -!- orccoin [~Rheanna@101.91.232.94] has joined #lightning-dev 04:23 -!- darosior [~darosior@194.36.189.246] has joined #lightning-dev 04:31 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 04:45 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has quit [Ping timeout: 265 seconds] 04:50 -!- EndFiat [EndFiat@gateway/vpn/mullvad/endfiat] has joined #lightning-dev 04:51 -!- orccoin [~Rheanna@101.91.232.94] has quit [Remote host closed the connection] 04:53 -!- orccoin [~Rheanna@101.91.193.123] has joined #lightning-dev 04:54 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection] 04:54 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 05:05 -!- awesome_doge [~Thunderbi@111-71-21-212.emome-ip.hinet.net] has joined #lightning-dev 05:12 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev 05:16 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 05:26 -!- awesome_doge [~Thunderbi@111-71-21-212.emome-ip.hinet.net] has quit [Read error: Connection reset by peer] 05:31 -!- laptop [~laptop@80.225.17.154] has joined #lightning-dev 05:49 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 05:56 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 05:56 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection] 06:08 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has joined #lightning-dev 06:33 -!- musdom [~Thunderbi@202.184.3.8] has quit [Quit: musdom] 07:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:14 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds] 07:21 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 07:45 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-daqmgpiqolbibgyl] has joined #lightning-dev 08:17 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 252 seconds] 08:18 -!- jarthur [~jarthur@2603-8080-1540-002d-4833-2069-9a58-8526.res6.spectrum.com] has joined #lightning-dev 08:34 -!- proofofkeags [~proofofke@205.209.28.54] has joined #lightning-dev 08:55 -!- contrapumpkin is now known as copumpkin 09:01 -!- orccoin [~Rheanna@101.91.193.123] has quit [Remote host closed the connection] 09:04 -!- orccoin [~Rheanna@101.91.232.94] has joined #lightning-dev 09:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 09:12 -!- greypw_ [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!] 09:28 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev 09:29 -!- greypw [~greypw@unaffiliated/greypw] has quit [Client Quit] 09:34 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev 09:39 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: The Lounge - https://thelounge.chat] 09:39 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev 09:45 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!] 09:47 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev 09:51 -!- orccoin [~Rheanna@101.91.232.94] has quit [Remote host closed the connection] 09:54 -!- orccoin [~Rheanna@101.89.197.243] has joined #lightning-dev 09:58 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 10:02 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 10:06 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: The Lounge - https://thelounge.chat] 10:07 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev 10:41 -!- orccoin [~Rheanna@101.89.197.243] has quit [Remote host closed the connection] 10:44 -!- orccoin [~Rheanna@218.78.43.189] has joined #lightning-dev 11:01 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 11:02 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 11:14 -!- valwal [~valwal@96.224.58.144] has joined #lightning-dev 11:31 -!- orccoin [~Rheanna@218.78.43.189] has quit [Remote host closed the connection] 11:33 -!- orccoin [~Rheanna@101.91.232.94] has joined #lightning-dev 12:06 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev 12:37 -!- zkao is now known as _zkao 12:41 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 12:44 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving] 12:46 -!- Zander [~lord@c-66-229-1-22.hsd1.fl.comcast.net] has joined #lightning-dev 12:47 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 12:48 -!- Zana [~lord@c-66-229-1-22.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds] 12:51 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:e977:61d8:78f2:895] has joined #lightning-dev 12:54 -!- Zana [~lord@c-66-229-1-22.hsd1.fl.comcast.net] has joined #lightning-dev 12:56 -!- Zander [~lord@c-66-229-1-22.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds] 12:56 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving] 12:57 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 12:59 -!- smartineng [~Icedove@88.135.18.171] has quit [Quit: smartineng] 13:00 < niftynei> hello hello 13:01 < niftynei> i don't see t-bast online ariard 13:01 < ariard> hi niftynei 13:01 < niftynei> oh i spoke too soon haha 13:01 < niftynei> hello! 13:01 < ariard> well he did publish an agenda at least :) 13:01 < cdecker> Hi all 13:01 < niftynei> need to update my t-bast watch script ;) 13:02 < t-bast> hey everyone! 13:02 < niftynei> ariard do you mind posting the agenda link if you have it handy 13:02 < cdecker> https://github.com/lightningnetwork/lightning-rfc/issues/870 13:02 < t-bast> niftynei: https://github.com/lightningnetwork/lightning-rfc/issues/870 :) 13:03 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:03 < niftynei> merci!! 13:03 < cdecker> De rien :-) 13:03 < ariard> voila :) 13:03 < t-bast> This is the day we do the meeting in french? Great idea! 13:04 < rusty> Hello all! 13:04 < cdecker> C'est pour l'inclusivite 13:04 < rusty> Pardon. Bonjour! 13:05 < ariard> t-bast: si on compte cdecker dans les francophones pour l'instant on est a majorite ;) 13:05 < t-bast> Bonjour à tous 13:05 < niftynei> oh my. 13:05 < t-bast> ariard: we shouldn't let them know, they'll understand that this project is a big french conspiracy 13:06 < niftynei> bonjour! 13:06 < rusty> Google Traduction transforme les "channels" en chaînes. Hmm.. 13:06 < t-bast> And I'm sure you taught BlueMatt a lot of french as well 13:06 < niftynei> ariard would you like to chair today? 13:06 < ariard> niftynei: well sounds my day to chair 13:06 < ariard> t-bast: lol we speak in german 13:07 < ariard> #startmeeting lightning-dev 13:07 < lndev-bot> Meeting started Mon May 10 20:07:22 2021 UTC and is due to finish in 60 minutes. The chair is ariard. 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 'lightning_dev' 13:07 < ariard> oh works at first try 13:07 < rusty> I am liking "Canaux de foudre" though... 13:07 < ariard> #topic on-the-fly channel upgrade 13:08 < ariard> rusty: you've the mic to explain #869, #868! 13:08 < rusty> OK, I have an update draft... let me push it... 13:08 < t-bast> rusty: we're probably going to use that one for a feature, "canaux de foudre" looks badass 13:09 < rusty> t-bast: :) 13:09 < cdecker> Excellent choice of message names ^^ 13:10 < rusty> OK, so I was looking at channel upgrade. We have wanted this for a while, but I really did want it for simplified update protocol. 13:10 < rusty> It's easiest if you can assert that the new method/format applies canonically from a given commit number. Turns out that fits pretty well with reconnection, where we explicitly send the numbers. 13:11 <+roasbeef> saw that, was interesting we went w/ pretty different approaches (independent of the scope of simplified updates, not sure how much value vs effort that brings) 13:11 <+roasbeef> the main diff is that what I've been working on in the background moves to making everything explicit w.r.t channel funding, as soon there may not be a "default/preferred" chan type 13:11 -!- orccoin [~Rheanna@101.91.232.94] has quit [Remote host closed the connection] 13:11 < rusty> roasbeef: yeah, taproot will be a big one too. 13:12 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 13:12 <+roasbeef> also what I've been tinkering on is a bit more general, as it makes room to let you update things like the dust limit or the # of max HTLCs on the fly, while the channle is being used within teh same connection context 13:12 < rusty> roasbeef: this protocol is basically "one side proposes update, the other says what updates are OK". 13:12 < ariard> rusty: are you covering channel policy update, like open/accept scopes? 13:12 <+roasbeef> been bogged down by the non-LN parts of my job, so I've had it paused for the past few weeks 13:12 -!- orccoin [~Rheanna@218.78.43.189] has joined #lightning-dev 13:13 < rusty> ariard: not sure what that means? 13:13 < t-bast> roasbeef: IIUC updating things like dust_limit or max_accepted_htlcs would also be easy with rusty's proposal, or am I missing something? 13:13 <+roasbeef> t-bast: but you'd need to re-initiate the connection right? 13:13 < t-bast> It sounds like once we're in quiescence, we can upgrade pretty much whatever we want 13:13 <+roasbeef> it also doesn't make things explicit 13:14 <+roasbeef> like w/ mine, we add a chan_type to the open/accept messages, so we avoid the weird issues we ran into when we make certain feature bits required, and we had to downgrade our bits to maintain connections w/ eclair nodes, etc 13:14 < t-bast> oh got it, but I don't think we'd need the channel_reestablish to trigger updating channel parameters once we're in quiescence, right rusty? 13:14 < ariard> rusty: well things like dust_limit, htlc_min_msat 13:14 < rusty> t-bast: it's far easier, since it automatically works for lost messages though. 13:14 <+roasbeef> at a high level I've been tinkering with: new shtudown liek message to propose a commitment update, new update_fee like message to commit the proposal by one or both nodes, works w/ the existing retransmission stuff as it's just another log update 13:14 < cdecker> Yes, the reconnect commit is separate from the quiescence 13:15 <+roasbeef> not following where quiescence comes in? 13:15 < rusty> Frankly, changing other things is far far easier with simplified commitment update. You're *always* quiescent at the start of your turn, and the state is the same on both sides. 13:15 < t-bast> roasbeef: so your proposal is kind of a two-phase commit with new messages? 13:15 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 13:15 <+roasbeef> t-bast: yes, w/ the initaitor doing the commit, with a fast path where if only the responder wants to change then you can do it more quickly 13:16 <+roasbeef> it also leaves room for backing out, since only the initator commits the actual confi change 13:16 <+roasbeef> it works kinda like the way raft does config updates 13:16 <+roasbeef> backing out as in, I disagree w/ your fancy commitment type or w/e, so we don't need to run into like an invalid sig and destroy the channel in that case or w/e 13:16 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 13:16 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 240 seconds] 13:16 < t-bast> it's true that the high-level feature we want to get (updating channel things) has a very large design space 13:17 <+roasbeef> indeed, I had a goal to go w/ something more general, and there're a lot of hard coded params rn that you can't ever change once the chan is open, so had eyes set on a two birds w/ one stone kinda thing 13:17 < niftynei> where does splice fit into the list of "channel update parameters" 13:17 < rusty> I'm determined to pursue simplified commitment protocol, since I don't believe we will ever get all the synchronization bugs out of all the implementations :( It's been five years and we're still finding them. Adding more complexity is not a win. 13:18 <+roasbeef> the propose messages are just a signed tlv (signed so the initaitor can do retransmission, etc) 13:18 < t-bast> rusty: simplified commitment update is the change to the channel state machine, right? Where we have turns instead of the current message flow? 13:18 < rusty> t-bast: kind of. It's just a subset of the current state machine. 13:18 <+roasbeef> if ppl implement the simplified stuff or not, again we'd need to make sure we have explicit funding, as it makes diff tradeoffs 13:18 <+roasbeef> we fixed a recent issue on our state machine, likely the last (fingers crossed lol)? 13:19 * BlueMatt admits he likes going with quiescence/turns on new changes, but is dubious of the value of doing turns for existing stuff. 13:19 <+roasbeef> but I guess is it a bigger hill to climb to introduce something brand new or just better understand/formalize/spec the existing one 13:19 < BlueMatt> does anyone else have fuzzing on their state machine to catch the inconsistent-state bugs? 13:19 < rusty> BlueMatt: it makes splicing, and changing other channel parameters much easier. 13:19 <+roasbeef> yeh we've been using one to find our recent issues BlueMatt 13:19 -!- orccoin [~Rheanna@218.78.43.189] has quit [Remote host closed the connection] 13:20 <+roasbeef> rusty: at the cost of x-put, and also the effort to switch everything over (and the unknowns that lie there) to the new method? 13:20 < rusty> roasbeef: that's why I'm implementing it, so I have a concrete idea of what's involved. 13:21 < BlueMatt> rusty: right, we've hashed this out on the ml, I dont really think I have anything to add to that convo beyond what I'd said before - that quiescence relies on a lot of the same code as shutdown anyway, whereas simplified commitment adds new logic around queues, so I'd think the first is easier, but curious to see your implementation. 13:21 <+roasbeef> mhmm, but then there may be a scenario where ppl add it, but don't make it the default, which motivates explicit funding (so no more feature bit implicit negotiation) 13:21 < rusty> BlueMatt:quiescence also needs queues :) 13:21 < niftynei> what is explicit funding? 13:21 <+roasbeef> niftynei: so my open chan message just adds a new tlv that says the type of channel I'm opening 13:22 <+roasbeef> rn we expect a certain type based on feature bits, which doesn't work when you have "non-default" commitment/funding types 13:22 < ariard> ah, typed funding sounds a good name 13:22 < BlueMatt> rusty: true, but for fewer things - I *think* it adds fewer states, but I may be wrong. 13:22 <+roasbeef> like we had an issue when we made static key required: older nodes didn't udnerstand it, so we couldn't establish our older connections w/ say eclair nodes, and had to _downgrade_ those feature bits, then reject those funding attempts we didn't like 13:22 < rusty> roasbeef: yeah, I wrestled with the same. I have been calling them channel features, which is overloaded unf. Types is beter. 13:22 <+roasbeef> vs being able to signal what you understand, then explicitly tell the other side which one yuo're trying to use 13:23 -!- orccoin [~Rheanna@218.78.43.189] has joined #lightning-dev 13:23 < rusty> roasbeef: yeah, definitely better for diags when things go wrong, too. 13:23 <+roasbeef> so there's another thing here about the ability to not really flip chan related featire bits to required 13:23 < t-bast> yep that would be quite useful 13:23 <+roasbeef> as then you can't maintain older connections w/ those you have legacy chans w/, w/o unsetting those bits 13:24 <+roasbeef> you're basically forced to downgrade to the lowest common known chan vs being able to keep that connection then only accepting requests to fund your preferred chans 13:24 < niftynei> oh i see. interesting 13:24 < rusty> Yes, channel bits in open/accept FTW? 13:24 <+roasbeef> not bits, just an explicit type 13:24 < rusty> Though ideally upgrade will also help transition. 13:24 <+roasbeef> since you need to pick one 13:24 < niftynei> picking the type scope seems... challenging 13:25 < rusty> roasbeef: except simplified commitment protocol is an orthogonal option unfortunately. 13:25 <+roasbeef> niftynei: how so? 13:25 <+roasbeef> rusty: don't follow, it's basically a new commitment type as the engine changes, no? 13:25 <+roasbeef> so you'd need something to uprgade on the fly, then start to use that 13:25 < rusty> roasbeef: no, you can have that and taproot, or that and Eltoo... 13:25 < niftynei> what necesscitates a new type? 13:25 <+roasbeef> mhmm that can be another dimension/field -> commitment engine or w/e 13:26 <+roasbeef> niftynei: what if I want to use the new taproot commitment, not not this new commitment engine? 13:26 < niftynei> is eltoo a type? option_anchor_outputs? 13:26 < ariard> and another dimension field would be dlc or any other type of packets on top of an anchor channel 13:26 <+roasbeef> sure anything future thing really, DLC, etc, etc 13:27 <+roasbeef> on the pool side we have a new channel type that basically forks the funding commitment, so we can have a uni-directional channel that pays out coupon payments for the lease 13:27 <+roasbeef> a similar structure is useful for DLC stuff as well, before something like no_input 13:27 < ariard> what do you mean by forking the funding commitment? a new intermediate stage 13:28 < rusty> roasbeef: we already have a defined feature bitmap, I think we should use it? And define that you can only have one bit (for now). 13:28 <+roasbeef> yeh like the eltoo kick off transaction type stuff ariard 13:28 <+roasbeef> rusty: yeh but imo I don't see how the bit map is compatible w/ explicit funding, there may be overlap, but I don't want to use that channel type as I just understand it as an example 13:28 <+roasbeef> ariard: so funding output, then intermediate transaction w/ two outputs, then another level of the actual commitments 13:29 < ariard> it's just a bitmap matrix like doesn't sound to work well with all the upcoming features 13:29 <+roasbeef> DLC rn wants something like this, as you want to be able to update the channels independently w/o invalidting the sigs w/ a txid change, w/ no_input it matters less 13:29 < ariard> like you might be interested to use taproot output but want to apply zero-fee on the commitment once we have package relay 13:29 < ariard> that kind of combinations 13:30 < t-bast> I think it's dangerous to support a wide number of such combinations 13:30 <+roasbeef> yeh in my mind, you'd just flatten that all out to induvidual types 13:30 <+roasbeef> you signal if you understand it or not in feature bits 13:30 <+roasbeef> then at execution you explcitily say which one you're using 13:31 <+roasbeef> commit_sig would also start to carry that, since it'll b epossible to have two commitments of diff commit types until revoked, so you get the context during retransmission/reconstruction 13:31 < niftynei> i'm struggling to understand the difference btw feature bits and types. it sort of sounds like you're just naming each possible feature-bit combination a 'type'? 13:31 < BlueMatt> t-bast: yea, you really want to say "I support sets A+B, A+B+C, but not A+C" 13:31 <+roasbeef> niftynei: if we send over feature bits, and have 3 channel types overlapping (we just take em from the node ann for w/e), which one are we using for the funding attempt? 13:32 < niftynei> ok but you haven't explained what a 'channel type' is and how it's not a feature bit? 13:32 < ariard> roasbeef: right for DLC, idea was to group your DLC by frequency of update to avoid the really active ones bothering you update the update-once-in-a-year-contract 13:32 < t-bast> BlueMatt: yeah but I'd really want my implementation to avoid supporting 10 different cases, ariard's comment seemed to imply a big combinatorial explosion of possible channel configurations, and I find that dangerous (hard to properly test) 13:32 <+roasbeef> niftynei: say anchors is type 4, static key is 3, etc, etc 13:33 <+roasbeef> ariard: yeh that's another option, large design space, for our specific use case it's better they be fully independent 13:33 <+roasbeef> t-bast: if there's a lot of types, you just need to know which ones you support or not, signalling happens at the feature bit level, execution one level down 13:33 < ariard> t-bast: well flattening as proposed by roasbeef might work, we should aslo consider we won't deploy everything on the same dev cycle, so yuou might deprecrate old types 13:33 <+roasbeef> particularly w/ taproot, the design space really starts to expand 13:34 < niftynei> roasbeef, i think another way to restate what you're proposing is committing to a feature-bit set at open 13:34 <+roasbeef> and the impls are getting more and more de-synchronized today 13:34 < niftynei> which maps to your 'explicit vs implicit' designation earlier 13:34 < ariard> yes lloyd was also working on asymmetric channnels leveraging witness scripting 13:35 <+roasbeef> ariard: this variant? https://eprint.iacr.org/2020/476 13:35 < ariard> like i would say we should only converge on a standard secure/confidential type post-taproot and let folks explore the fringers 13:35 < ariard> *the fringes 13:36 < ariard> roasbeef: yep this one iirc : https://github.com/LLFourn/witness-asymmetric-channel/blob/master/original.md 13:36 < BlueMatt> t-bast: right, that was my point, like you could just support "all features up to A, B, or C, but not the combinatorial explosion of A, B, and C" 13:36 < rusty> We may get an explosion of types, but I hope we'll generally converge on a few useful best ones. 13:36 < BlueMatt> right, as long as you can restrict yourself to a limited set 13:37 < t-bast> Sounds good then ;) 13:37 < ariard> yep that's my thinking too, the few useful best ones will emerge 13:37 < BlueMatt> an all-out explosion would be really bad. 13:37 < BlueMatt> ie as long as we can limit ourselves to supporting only the "best sets" 13:37 <+roasbeef> imo this is related to the discussion to move away from teh current BOLT documetn structure and move forward with more contained/standalone documents 13:38 <+roasbeef> there's a lot of potential for innovation/experimentation, and I wouldn't really expect everyone to commit to keep up w/ it all, as everyone has diff priorities/needs 13:39 < ariard> and some specification is reused by other dev communities like DLC 13:39 < t-bast> agreed, but there are things that really need to be in the core, even for security's sake: channel commitment format is one for example 13:39 < ariard> t-bast: maybe need all the scope of channel commitment formats but one dynamic upgrade mechanism seems quite core imho 13:39 < t-bast> it's really important to have as many eyes as possible on the parts that are critical for funds safety 13:39 < ariard> *maybe not 13:39 < niftynei> i'm not sure what the network as a whole gains by a fractured approach to a common spec 13:39 < rusty> I like a twist on roasbeef's idea: the open msg should enumerate all the combinations it is OK with, the accept msg picks one. 13:40 < niftynei> (they are called 'network effects' for a reason lol) 13:41 < t-bast> rusty: that's similar to the closing change we've done recently: the node initiating close specifies the fees it's ok with, and the other node chooses one in that range 13:41 <+roasbeef> niftynei: in the end, the network in a sense is the shared HTLC construct 13:41 < t-bast> (https://github.com/lightningnetwork/lightning-rfc/pull/847) 13:41 <+roasbeef> as long as that's the asme along a route, doesn't really matter what transfers it 13:42 < niftynei> t-bast: that's still on my to-do list, btw! 13:42 <+roasbeef> or ptlc or w/e the kid are calling it these days 13:42 < t-bast> but it does matter for the network as a list if it's unsecure! 13:42 < ariard> roasbeef: htlc-over-opendime? 13:43 < t-bast> let's not forget that ariard found an issue with anchor even after it had been reviewed a lot, so imagine what happens when new channel commitment types are deployed without getting as much review? 13:43 < ariard> rusty: i like this twist too, you guarantee to do the negotiation in one RTT 13:43 < niftynei> in a sense, sure. in practical reality it's confusing to end-users if nodes dont interoperate as expected lol 13:43 <+roasbeef> t-bast: tradeoffs in the end, do you think you'd be able to keep up w/ and fully review everything that came across the board? 13:44 <+roasbeef> from my pov feels like we've kinda reeached that point already 13:44 < t-bast> roasbeef: no, but I think it's a good thing that it moves slowly 13:44 < BlueMatt> what t-bast said. There's massive usability loss from fragmentation. its one thing to have certain major systems (like DLC) separate, but something else to have things like keysend or 0-value invoices be fragmented. those we've seen actively hurt users many times. 13:44 < t-bast> roasbeef: frustrating sometimes, but better in the long run imho 13:44 < ariard> but maybe we should have differing tracks inside the same LN specification effort 13:44 <+roasbeef> nimbleness of LN as is is a strength imo, like rn a buncha wallets do custom things that improve their UX, they just did it and didn't need to "ask permission" from anyone as they were driving towards a precise goal 13:45 < ariard> the ietf is doing it for a bunch of protocols like sip 13:45 < cdecker> Agreed, experimentation is all good and fine, but we need a minimal common set that ensures compatibility and a good UX 13:45 < rusty> I sympathize with roasbeef here: more freedom to experiment is good, as long as it's explicit in the protocol. 13:45 <+roasbeef> ideally taht custom stuff is at least _documented_, wouldn't expect everyone to impl all of it tho 13:46 < t-bast> of course there are parts of the protocol that are prone to quicker prototyping and deployment, but for the really core parts I think it's important to move slow and get everyone to look at it - but I'm not sure where to put the boundary of what is "core" 13:46 < BlueMatt> right, my issue is more "going off in one direction without even documenting it". I think we all agree experimentation is good, as long as those things make their way into the spec eventually and we can learn from the experiementation and get broader review. 13:46 < ariard> i agree on proning the experimentation aspect, as long as we can find a proper documentation somewhere 13:46 <+roasbeef> another example is something like ln-url: pretty much all the major wallets implement it, but the spec itself is pretty light and isolated from everything else 13:47 <+roasbeef> some of us may not really like the tradeoffs it makes, but wallets use it as it solves a problem for them 13:47 < t-bast> roasbeef: good example, this is the kind of thing that would make sense to have in a BIP-like document close to the spec 13:47 < rusty> roasbeef: +1 13:47 < niftynei> ln-url doesn't deal with inter-node communication 13:47 <+roasbeef> t-bast: yeh def, in terms of like "tracks" agree there's like a fundamental track (htlc types, etc) then would be others 13:48 <+roasbeef> niftynei: it kinda does, ppl use it to communicate invoices between nodes 13:48 < BlueMatt> ln-url is great, I also love that it has documentation and such. would be great if it were *in* the bolts repo, maybe under an experiemtntal/ directory 13:48 <+roasbeef> for like scan to withdraw flows, etc 13:48 < ariard> yep we should have more tracks if people feel like it, bip do have consensus/p2p/applications/etc 13:48 <+roasbeef> fwiw offers kinda occupies the same domain as it tho, as they offer similar functionality in the end 13:48 < BlueMatt> this may be somewhere we can learn from BIPs - they exist only to communicate things people wish to be interoperable, not to "get review", we could have an experimental/ folder for similar documents 13:48 < rusty> Well, offers covers much of this (though not all!). 13:49 < BlueMatt> those things dont have to go into the main bolts, but they could be a "for now we're doign this, we may do something else later" 13:49 < ariard> and another aspect to consider is documenting "best practices" especially how you taught node operators to select config parameters in function of use-case 13:50 < t-bast> BlueMatt: +1 for the "experimental" or "proposals" folder, what would be the criteria to get it merged though? What review does it need? 13:50 <+roasbeef> I g2g in 10 13:50 < BlueMatt> I'd assume none 13:50 < BlueMatt> like there should be *opportunity* for review, but it could be, like BIPs, "author documents" 13:50 < ariard> t-bast: i would say a minimal bar of not being junk and decently written, like only 1 implem supporting it? 13:51 < BlueMatt> like, the author decides what the contents are, and others can only provide feedback 13:51 < t-bast> Ok, interesting 13:51 < rusty> Anyway, thanks for the discussion, esp roasbeef. I am going to go back and change the upgrade proposal to explicitly list a set of allowable upgrades rather than a single bitfield (which has awkward semantics as diff possibilities arise). 13:51 < t-bast> And the stronger review would happen when we'd want to move it from "experimental/proposal" to a core BOLT? 13:51 <+roasbeef> rusty: pushes me actually write down my ideas too lol 13:51 < ariard> t-bast: in practice review happen when you implement the stuff 13:51 < rusty> roasbeef: :) 13:51 < BlueMatt> t-bast: yes 13:52 <+roasbeef> I think splitting thngs out would also make the spec a lot easier to read, idk about y'all but I find it hard parsing thru it rn, as there's basically a buncha if statements everywhere 13:52 < BlueMatt> rusty and roasbeef: thanks y'all! 13:52 <+roasbeef> especially when reviewing diffs 13:52 < t-bast> roasbeef:iIt would be great to have two proposals to look at to see the differences! 13:52 < BlueMatt> yea, I tend to agree, though its good to have a "core thing" 13:52 <+roasbeef> also not clear to new ppl how things have evolved over time either, other than looking at the git history ofc 13:52 < rusty> roasbeef: Grand Feature Elimination is on my TODO, TBH. 13:52 < ariard> roasbeef: yeah made the point about interactive construction protocol could be its own BIP 13:53 < ariard> *BOLT 13:53 < rusty> (After we have upgradality ofc) 13:53 < rusty> *upgradability 13:53 < ariard> okay let's move on from upgradability? 13:53 < rusty> ariard: please :) 13:53 < ariard> do we have another long-term subject we want to parse? 13:53 < t-bast> let's call these "sparks" instead of lightning BIPs 13:53 < ariard> like dual-funding? 13:53 < ariard> t-bast: tonnere, foudre, orage? 13:54 < rusty> ariard: oh, dual-funding, splicing and splice-to-close are all related, BTW. 13:54 < ariard> #topic dual-funding & friends 13:54 < t-bast> ariard: étincelle, for the experimental proposals! 13:55 < ariard> wr.t to dual-funding or any others multi-party funded protocols like splicing 13:55 < rusty> Not sure if I should leave this to niftynei... 13:55 < niftynei> i'm not sure what kind of discussion we're looking for haha 13:55 < niftynei> so go ahead rusty? 13:55 < rusty> Err, OK. I'm two coffees down, so good to go I guess :) 13:55 < ariard> we're quite vulnerable to a bunch of dumb DoSes as documented here : https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html 13:56 < ariard> so rn, opening a multi-party funded channel require more trust in your counterparty 13:57 < ariard> than single-funded one, and i'm not if it's rightly captured by the spec 13:57 < rusty> So, the basic protocol of DF uses a negotiation method, which took more than a year to refine because we wanted to reuse it for everything else, and we wanted it to be usable by either peer to coordinate with multiple peers at once. 13:57 < ariard> and beyond adverserial settings, we have also lazzy/buggy peers, where you might want to fallback and funding timeout recovery style of things 13:58 < rusty> The good news is, it works for splice, and a to-be-defined subset of splice which is splice-to-close. 13:59 < rusty> Implementation-wise: niftynei has reckless experimental option which has been used on mainnet for DF (though I don't think they had to RBF?), and I'm actively working on splice. Splice is easier to define if quiescent, hence my work there. 13:59 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has joined #lightning-dev 13:59 < rusty> (Close is naturally quiescent since we define it to start once all updates are done). 13:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 14:00 < niftynei> rusty, correct the DF open worked as expected the first time lol 14:00 < ariard> rusty: what flavor of splice-in it's about? you parallelize channel updates until new funding_txo has enough confirmation? 14:00 < niftynei> ariard, by DOS you mean "channel doesn't open (in a reasonable timeframe)" 14:01 < ariard> niftynei: yeap funding doesn't confirm in a reasonable timeframe, what should you do? 14:01 -!- orccoin [~Rheanna@218.78.43.189] has quit [Remote host closed the connection] 14:01 < t-bast> for splice, do you stay quiescent until you have on-chain confirmations? 14:01 < niftynei> which is .. currently the case with channel opens because of feerates etc. in theory we get around that by double-spending the inputs after a timeout 14:01 < niftynei> :s/in theory// 14:01 < rusty> ariard: yes, exactly. Technically there's no splice in vs out distinction then. Splice proposer pays for 1 input (spending channel), 1 output (new channel out) and the tx core. Other side can choose to add whatever they want. 14:02 < rusty> t-bast: naah, just during active negotiation. 14:02 < rusty> t-bast: i.e. tx construction. 14:02 < ariard> niftynei: it sounds good in non-adverserial settings, in non-adverserial settings you should beware upper bounding your fee-bumping 14:02 < ariard> *adverserial settings 14:02 < t-bast> how does that work if that tx never confirms? 14:02 < t-bast> you *have* to make it confirm through CPFP whatever the cost? 14:03 < niftynei> right now you have to CPFP a channel open if it doesn't confirm 14:03 < rusty> t-bast: you carry those forever, and you can have multiple; only constraint is that they must pay 1.25x feerate of previous. 14:03 < niftynei> the DF protocol provides a method for initiating an RBF with your peer 14:04 -!- orccoin [~Rheanna@101.91.232.94] has joined #lightning-dev 14:04 < t-bast> ok, it's a chain so you only move forward? Does it mean you could have two unconfirmed splices going (the second one applied after the first one)? 14:04 < rusty> t-bast: no, they are all in parallel. You can't start a second on top of the first. 14:04 < rusty> t-bast: (we had to stop somewhere!) 14:05 < t-bast> Ok, I must be missing on the fundamentals of splicing then...doesn't splicing just spend the funding tx to make a new funding tx for the channel? 14:05 < t-bast> Like a close and an open merged in one tx (with the opportunity to dual-fund added)? 14:06 < rusty> t-bast: yes, but also adds arbitrary outputs and inputs. You can propose *another* splice, but it must be at 1.25x (or more) of previous splice feerate. 14:06 < t-bast> oh ok so this other splice would replace the previous one entirely? 14:06 < rusty> t-bast: we carry all the possible splices until one wins 6 confs. 14:06 < rusty> Then we clear them all, and you can propose a new one. 14:06 < t-bast> Ok, that's clear now 14:06 < t-bast> Thanks 14:07 < rusty> If you propose a giant feerate, that's fine, but your peer is unlikely to contribute any changes. You can ofc make an invalid input and block further splices, but you can always make a channel useless in less exotic ways, too. 14:07 < t-bast> Interesting, I can see the synergy with interactive-tx then 14:07 < ariard> you should beware of respecting the absolute fee for RBF, otherwise you lastest splice might not propagae 14:08 < ariard> though do you really care as long as you expect *any* one of them to confirm? 14:08 < rusty> ariard: exactly. 14:08 < niftynei> yeah, it's possible you make a non-propagating tx but then you'd just try again? 14:08 < rusty> (Though you're right, proposer should check this!) 14:09 < rusty> But this is why it kind of goes with splice-to-close, since you can't currently shutdown with outstanding splices. 14:09 < ariard> niftynei: nightmare scenario where a reorg occurs, and a parent gets unconfirmed violating bip125 rule 4? 14:09 < niftynei> how big of a reorg are you talking? 14:09 < ariard> *rule 2 : don't add new unconf input 14:10 < ariard> niftynei: even 1-depth reorg is enough to make your transaction not propagating? as a rule of thumb maybe recommend to use parent well-confirmed? 14:11 < niftynei> what makes this a nightmare scenario ariard? 14:11 < rusty> ariard: yeah, but you can keep sending it to bitcoind and it eventually works once tx is remined. Unless you're double-spending, which is always possible? 14:12 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #lightning-dev 14:12 < ariard> niftynei: parent might get double-spent, and you have to adapt your tx construction ? 14:13 < rusty> ariard: yeah, that'd cost you 25% bump in fees, but is possible? 14:13 < niftynei> iiuc for channel opens, you'd have to RBF the tx *again*. you don't lose anything but time 14:13 < niftynei> oh right and the fee bump rate 14:13 < rusty> Maybe 25% is too harsh, but as ariard says, if you're using low-confirmed txs you're playing with matches already maybe? 14:13 < ariard> niftynei: depends if you have a double-spend in network mempools not signaling rbf, RBF on your side is pretty useless 14:14 < niftynei> this could happen with a normal channel open today also, no? 14:14 < niftynei> ah wait, no it's a RBF only corner case and you can't rbf an open today. ok 14:15 < ariard> niftynei: with a normal channel open, the funder will either double-spend or RBF 14:15 < niftynei> you cant RBF an open right now, you'd have to CPFP it 14:15 < ariard> with dual-funding or N-funding, each counterparty might have a rebroadcast/differing policy failure 14:16 < ariard> like Alice is trying to RBF, but Bob already reaches his funding timer and double-spend his contributed inputs 14:16 < niftynei> the mitigation for these corner cases is the same though, no? you double spend an input. 14:16 < niftynei> ok so at some point Alice will also hit her funding timer and double-spend her input 14:17 < ariard> niftynei: that's a nice failure if both counterparties double-spend their inputs at the same time 14:17 < ariard> niftynei: really messy cases it's when your counterparty pin the funding transaction to block your double-spend propagation on the network 14:17 < niftynei> does 'at the same time' matter? eventually they should both end up in the same state 14:17 < niftynei> true, that does sound messy 14:18 < ariard> anyway, i think we'll improve those cooernes cases over time, the core interaction protocol sounds good enough for me :) 14:18 < niftynei> any time someone blocks a tx propagation it gets messy haha 14:18 < ariard> Package Relay Solves This (or maybe Eltoo?) 14:18 < niftynei> PRST !! 14:18 < niftynei> haha 14:19 < ariard> any other topic or we shutdown here? 14:19 < niftynei> cool, thanks for lending your pinning + feerate expertise to the review! 14:19 < ariard> niftynei: yw, feel free to ask further questions on the pr :) 14:19 < rusty> ariard: I think we're overtime, but good conversation!@ 14:20 < ariard> yep was a good one 14:20 < ariard> #endmeeting 14:20 < lndev-bot> Meeting ended Mon May 10 21:20:02 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 14:20 < lndev-bot> Minutes: https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.html 14:20 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.txt 14:20 < lndev-bot> Log: https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.log.html 14:20 < t-bast> Thanks everyone! 14:20 < t-bast> I learnt many things today, and some things started to "click" 14:20 < ariard> t-bast: that you should have pickup splicing as a college major :p ? 14:21 < t-bast> haha definitely, I'm really realizing that splicing will allow us to get rid of swaps in our wallet and do something much better for users (trustless and more fee efficient) 14:22 < t-bast> great discussions, lot of ideas to explore now, see you on github and next time! 14:24 -!- t-bast [~t-bast@2a01:e0a:24a:7d0:e977:61d8:78f2:895] has quit [Quit: Leaving] 14:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 14:35 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds] 14:46 -!- laptop [~laptop@80.225.17.154] has quit [Remote host closed the connection] 14:51 -!- orccoin [~Rheanna@101.91.232.94] has quit [Remote host closed the connection] 14:52 -!- orccoin [~Rheanna@101.89.154.192] has joined #lightning-dev 15:02 -!- vincenzopalazzo [~vincenzop@host-79-23-113-134.retail.telecomitalia.it] has quit [Quit: Leaving] 15:10 -!- melvster [~melvin@ip-86-49-124-124.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 15:41 -!- orccoin [~Rheanna@101.89.154.192] has quit [Remote host closed the connection] 15:44 -!- orccoin [~Rheanna@101.91.214.30] has joined #lightning-dev 16:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 16:31 -!- orccoin [~Rheanna@101.91.214.30] has quit [Remote host closed the connection] 16:33 -!- orccoin [~Rheanna@101.91.240.201] has joined #lightning-dev 16:40 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 16:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 16:44 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 16:45 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 17:03 -!- jarthur_ [~jarthur@2603-8080-1540-002d-a172-fa76-51c1-034c.res6.spectrum.com] has joined #lightning-dev 17:06 -!- jarthur [~jarthur@2603-8080-1540-002d-4833-2069-9a58-8526.res6.spectrum.com] has quit [Ping timeout: 250 seconds] 17:08 -!- jarthur_ is now known as jarthur 17:21 -!- orccoin [~Rheanna@101.91.240.201] has quit [Remote host closed the connection] 17:21 < rusty> I stole roasbeef's "channel type" idea and rolled it into the upgrade proposal. The idea is we can add the same thing to open/accept FTW. 17:23 -!- orccoin [~Rheanna@101.91.192.124] has joined #lightning-dev 17:28 < rusty> (In particular, we now spell out all the types we could upgrade to). 17:37 -!- yzernik [~yzernik@2603:3024:1c06:c900:9450:beea:24f5:3de0] has quit [Ping timeout: 250 seconds] 17:37 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:39 -!- yzernik [~yzernik@50-247-111-130-static.hfc.comcastbusiness.net] has joined #lightning-dev 18:00 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 18:03 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 18:11 -!- orccoin [~Rheanna@101.91.192.124] has quit [Remote host closed the connection] 18:13 -!- orccoin [~Rheanna@101.91.197.175] has joined #lightning-dev 18:28 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 252 seconds] 18:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 18:59 -!- jarthur [~jarthur@2603-8080-1540-002d-a172-fa76-51c1-034c.res6.spectrum.com] has quit [Ping timeout: 250 seconds] 19:01 -!- orccoin [~Rheanna@101.91.197.175] has quit [Remote host closed the connection] 19:04 -!- orccoin [~Rheanna@101.91.197.175] has joined #lightning-dev 20:38 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 20:41 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 20:42 -!- orccoin [~Rheanna@101.91.197.175] has quit [Remote host closed the connection] 20:43 -!- orccoin [~Rheanna@101.89.197.243] has joined #lightning-dev 21:17 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 21:46 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has quit [Quit: Bye...] 21:51 -!- musdom [~Thunderbi@175.142.214.204] has joined #lightning-dev 21:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 22:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 22:17 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #lightning-dev 22:25 -!- gleb [~gleb@178.150.137.228] has quit [Ping timeout: 252 seconds] 22:27 -!- junderw [sid43070@gateway/web/irccloud.com/x-dospwhfotlegwzaz] has quit [Read error: Connection reset by peer] 22:27 -!- junderw [sid43070@gateway/web/irccloud.com/x-fytwzaqcolbavnbm] has joined #lightning-dev 22:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds] 22:48 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 22:48 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 23:11 -!- orccoin [~Rheanna@101.89.197.243] has quit [Remote host closed the connection] 23:14 -!- orccoin [~Rheanna@101.89.154.192] has joined #lightning-dev 23:35 -!- musdom [~Thunderbi@175.142.214.204] has quit [Ping timeout: 268 seconds] 23:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev --- Log closed Tue May 11 00:00:51 2021