--- 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