Lightning Specification Meeting 2021/05/10

[t-bast]

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

Pull Request Review

• On-the-fly channel upgrade BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869 BOLT 2: upgrade protocol on reestablish #868
• Splicing Splice draft (feature 62/63) #863

Long Term Updates

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (@t-bast)
• Offers Offers #798 (@rustyrussell)
• Upfront payments / DoS protection Hold fees #843
• Blinded paths Route Blinding (Feature 24/25) #765 (@t-bast)

Backlog

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

• Hornet (@cfromknecht)
• lnprototest https://github.com/rustyrussell/lnprototest (@rustyrussell)

[t-bast]

Meeting logs:

<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.
<lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
<lndev-bot> The meeting name has been set to 'lightning_dev'
<ariard> oh works at first try
<rusty> I am liking "Canaux de foudre" though...
<ariard> #topic on-the-fly channel upgrade
<ariard> rusty: you've the mic to explain #869, #868!
<rusty> OK, I have an update draft... let me push it...
<t-bast> rusty: we're probably going to use that one for a feature, "canaux de foudre" looks badass
<rusty> t-bast: :)
<cdecker> Excellent choice of message names ^^
<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.
<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.
<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) 
<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 
* orccoin has quit (Remote host closed the connection)
<rusty> roasbeef: yeah, taproot will be a big one too.
* ThomasV has quit (Ping timeout: 260 seconds)
<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 
<rusty> roasbeef: this protocol is basically "one side proposes update, the other says what updates are OK". 
<ariard> rusty: are you covering channel policy update, like open/accept scopes?
<roasbeef> been bogged down by the non-LN parts of my job, so I've had it paused for the past few weeks 
* orccoin (~Rheanna@218.78.43.189) has joined
<rusty> ariard: not sure what that means?
<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?
<roasbeef> t-bast: but you'd need to re-initiate the connection right? 
<t-bast> It sounds like once we're in quiescence, we can upgrade pretty much whatever we want
<roasbeef> it also doesn't make things explicit 
<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 
<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?
<ariard> rusty: well things like dust_limit, htlc_min_msat
<rusty> t-bast:  it's far easier, since it automatically works for lost messages though.
<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 
<cdecker> Yes, the reconnect commit is separate from the quiescence
<roasbeef> not following where quiescence comes in? 
<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.
<t-bast> roasbeef: so your proposal is kind of a two-phase commit with new messages?
* Emcy has quit (Read error: Connection reset by peer)
<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 
<roasbeef> it also leaves room for backing out, since only the initator commits the actual confi change 
<roasbeef> it works kinda like the way raft does config updates 
<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 
* Emcy (~Emcy@unaffiliated/emcy) has joined
* jonatack has quit (Ping timeout: 240 seconds)
<t-bast> it's true that the high-level feature we want to get (updating channel things) has a very large design space
<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 
<niftynei> where does splice fit into the list of "channel update parameters"
<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. 
<roasbeef> the propose messages are just a signed tlv (signed so the initaitor can do retransmission, etc) 
<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?
<rusty> t-bast: kind of.  It's just a subset of the current state machine.
<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 
<roasbeef> we fixed a recent issue on our state machine, likely the last (fingers crossed lol)? 
* BlueMatt admits he likes going with quiescence/turns on new changes, but is dubious of the value of doing turns for existing stuff.
<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 
<BlueMatt> does anyone else have fuzzing on their state machine to catch the inconsistent-state bugs?
<rusty> BlueMatt: it makes splicing, and changing other channel parameters much easier.
<roasbeef> yeh we've been using one to find our recent issues BlueMatt  
* orccoin has quit (Remote host closed the connection)
<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? 
<rusty> roasbeef: that's why I'm implementing it, so I have a concrete idea of what's involved.
<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.
<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) 
<rusty> BlueMatt:quiescence also needs queues :)
<niftynei> what is explicit funding?
<roasbeef> niftynei: so my open chan message just adds a new tlv that says the type of channel I'm opening 
<roasbeef> rn we expect a certain type based on feature bits, which doesn't work when you have "non-default" commitment/funding types 
<ariard> ah, typed funding sounds a good name
<BlueMatt> rusty: true, but for fewer things - I *think* it adds fewer states, but I may be wrong.
<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 
<rusty> roasbeef: yeah, I wrestled with the same. I have been calling them channel features, which is overloaded unf.  Types is beter.
<roasbeef> vs being able to signal what you understand, then explicitly tell the other side which one yuo're trying to use 
* orccoin (~Rheanna@218.78.43.189) has joined
<rusty> roasbeef: yeah, definitely better for diags when things go wrong, too.
<roasbeef> so there's another thing here about the ability to not really flip chan related featire bits to required 
<t-bast> yep that would be quite useful
<roasbeef> as then you can't maintain older connections w/ those you have legacy chans w/, w/o unsetting those bits 
<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 
<niftynei> oh i see. interesting
<rusty> Yes, channel bits in open/accept FTW?
<roasbeef> not bits, just an explicit type 
<rusty> Though ideally upgrade will also help transition.
<roasbeef> since you need to pick one 
<niftynei> picking the type scope seems... challenging
<rusty> roasbeef: except simplified commitment protocol is an orthogonal option unfortunately.
<roasbeef> niftynei: how so? 
<roasbeef> rusty: don't follow, it's basically a new commitment type as the engine changes, no? 
<roasbeef> so you'd need something to uprgade on the fly, then start to use that 
<rusty> roasbeef: no, you can have that and taproot, or that and Eltoo...
<niftynei> what necesscitates a new type?
<roasbeef> mhmm that can be another dimension/field -> commitment engine or w/e 
<roasbeef> niftynei: what if I want to use the new taproot commitment, not not this new commitment engine? 
<niftynei> is eltoo a type? option_anchor_outputs?
<ariard> and another dimension field would be dlc or any other type of packets on  top of an anchor channel
<roasbeef> sure anything future thing really, DLC, etc, etc 
<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 
<roasbeef> a similar structure is useful for DLC stuff as well, before something like no_input 
<ariard> what do you mean by forking the funding commitment? a new intermediate stage
<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).
<roasbeef> yeh like the eltoo kick off transaction type stuff ariard 
<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 
<roasbeef> ariard: so funding output, then intermediate transaction w/ two outputs, then another level of the actual commitments 
<ariard> it's just a bitmap matrix like doesn't sound to work well with all the upcoming features
<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 
<ariard> like you might be interested to use taproot output but want to apply zero-fee on the commitment once we have package relay
<ariard> that kind of combinations
<t-bast> I think it's dangerous to support a wide number of such combinations
<roasbeef> yeh in my mind, you'd just flatten that all out to induvidual types
<roasbeef> you signal if you understand it or not in feature bits 
<roasbeef> then at execution you explcitily say which one you're using 
<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 
<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'?
<BlueMatt> t-bast: yea, you really want to say "I support sets A+B, A+B+C, but not A+C"
<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? 
<niftynei> ok but you haven't explained what a 'channel type' is and how it's not a feature bit?
<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
<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)
<roasbeef> niftynei: say anchors is type 4, static key is 3, etc, etc 
<roasbeef> ariard: yeh that's another option, large design space, for our specific use case it's better they be fully independent 
<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 
<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
<roasbeef> particularly w/ taproot, the design space really starts to expand 
<niftynei> roasbeef, i think another way to restate what you're proposing is committing to a feature-bit set at open
<roasbeef> and the impls are getting more and more de-synchronized today 
<niftynei> which maps to your 'explicit vs implicit' designation earlier
<ariard> yes lloyd was also working on asymmetric channnels leveraging witness scripting
<roasbeef> ariard: this variant? https://eprint.iacr.org/2020/476 
<ariard> like i would say we should only converge on a standard secure/confidential type post-taproot and let folks explore the fringers 
<ariard> *the fringes
<ariard> roasbeef: yep this one iirc : https://github.com/LLFourn/witness-asymmetric-channel/blob/master/original.md
<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"
<rusty> We may get an explosion of types, but I hope we'll generally converge on a few useful best ones.
<BlueMatt> right, as long as you can restrict yourself to a limited set
<t-bast> Sounds good then ;)
<ariard> yep that's my thinking too, the few useful best ones will emerge
<BlueMatt> an all-out explosion would be really bad.
<BlueMatt> ie as long as we can limit ourselves to supporting only the "best sets"
<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 
<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 
<ariard> and some specification is reused by other dev communities like DLC
<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
<ariard> t-bast: maybe need all the scope of channel commitment formats but one dynamic upgrade mechanism seems quite core imho
<t-bast> it's really important to have as many eyes as possible on the parts that are critical for funds safety
<ariard> *maybe not
<niftynei> i'm not sure what the network as a whole gains by a fractured approach to a common spec
<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.
<niftynei> (they are called 'network effects' for a reason lol)
<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
<roasbeef> niftynei: in the end, the network in a sense is the shared HTLC construct 
<t-bast> (https://github.com/lightningnetwork/lightning-rfc/pull/847)
<roasbeef> as long as that's the asme along a route, doesn't really matter what transfers it 
<niftynei> t-bast: that's still on my to-do list, btw!
<roasbeef> or ptlc or w/e the kid are calling it these days 
<t-bast> but it does matter for the network as a list if it's unsecure!
<ariard> roasbeef: htlc-over-opendime? 
<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?
<ariard> rusty: i like this twist too, you guarantee to do the negotiation in one RTT
<niftynei> in a sense, sure. in practical reality it's confusing to end-users if nodes dont interoperate as expected lol
<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? 
<roasbeef> from my pov feels like we've kinda reeached that point already 
<t-bast> roasbeef: no, but I think it's a good thing that it moves slowly
<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.
<t-bast> roasbeef: frustrating sometimes, but better in the long run imho
<ariard> but maybe we should have differing tracks inside the same LN specification effort
<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 
<ariard> the ietf is doing it for a bunch of protocols like sip
<cdecker> Agreed, experimentation is all good and fine, but we need a minimal common set that ensures compatibility and a good UX
<rusty> I sympathize with roasbeef here: more freedom to experiment is good, as long as it's explicit in the protocol.
<roasbeef> ideally taht custom stuff is at least _documented_, wouldn't expect everyone to impl all of it tho 
<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" 
<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.
<ariard> i agree on proning the experimentation aspect, as long as we can find a proper documentation somewhere
<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 
<roasbeef> some of us may not really like the tradeoffs it makes, but wallets use it as it solves a problem for them 
<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
<rusty> roasbeef: +1
<niftynei> ln-url doesn't deal with inter-node communication
<roasbeef> t-bast: yeh def, in terms of like "tracks" agree there's like a fundamental track (htlc types, etc) then would be others 
<roasbeef> niftynei: it kinda does, ppl use it to communicate invoices between nodes 
<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
<roasbeef> for like scan to withdraw flows, etc 
<ariard> yep we should have more tracks if people feel like it, bip do have consensus/p2p/applications/etc
<roasbeef> fwiw offers kinda occupies the same domain as it tho, as they offer similar functionality in the end 
<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
<rusty> Well, offers covers much of this (though not all!).
<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"
<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
<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?
<roasbeef> I g2g in 10 
<BlueMatt> I'd assume none
<BlueMatt> like there should be *opportunity* for review, but it could be, like BIPs, "author documents"
<ariard> t-bast: i would say a minimal bar of not being junk and decently written, like only 1 implem supporting it?
<BlueMatt> like, the author decides what the contents are, and others can only provide feedback
<t-bast> Ok, interesting
<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).
<t-bast> And the stronger review would happen when we'd want to move it from "experimental/proposal" to a core BOLT?
<roasbeef> rusty: pushes me actually write down my ideas too lol
<ariard> t-bast: in practice review happen when you implement the stuff
<rusty> roasbeef: :)
<BlueMatt> t-bast: yes
<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 
<BlueMatt> rusty and roasbeef: thanks y'all!
<roasbeef> especially when reviewing diffs 
<t-bast> roasbeef:iIt would be great to have two proposals to look at to see the differences! 
<BlueMatt> yea, I tend to agree, though its good to have a "core thing"
<roasbeef> also not clear to new ppl how things have evolved over time either, other than looking at the git history ofc 
<rusty> roasbeef: Grand Feature Elimination is on my TODO, TBH.
<ariard> roasbeef: yeah made the point about interactive construction protocol could be its own BIP
<ariard> *BOLT
<rusty> (After we have upgradality ofc)
<rusty> *upgradability
<ariard> okay let's move on from upgradability?
<rusty> ariard: please :)
<ariard> do we have another long-term subject we want to parse?
<t-bast> let's call these "sparks" instead of lightning BIPs
<ariard> like dual-funding?
<ariard> t-bast: tonnere, foudre, orage?
<rusty> ariard: oh, dual-funding, splicing and splice-to-close are all related, BTW.
<ariard> #topic dual-funding & friends
<t-bast> ariard: étincelle, for the experimental proposals!
<ariard> wr.t to dual-funding or any others multi-party funded protocols like splicing
<rusty> Not sure if I should leave this to niftynei...
<niftynei> i'm not sure what kind of discussion we're looking for haha
<niftynei> so go ahead rusty?
<rusty> Err, OK.  I'm two coffees down, so good to go I guess :)
<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
<ariard> so rn, opening a multi-party funded channel require more trust in your counterparty
<ariard> than single-funded one, and i'm not if it's rightly captured by the spec
<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.
<ariard> and beyond adverserial settings, we have also lazzy/buggy peers, where you might want to fallback and funding timeout recovery style of things
<rusty> The good news is, it works for splice, and a to-be-defined subset of splice which is splice-to-close.
<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.
* vtnerd (~vtnerd@50-82-248-114.client.mchsi.com) has joined
<rusty> (Close is naturally quiescent since we define it to start once all updates are done).
* AaronvanW has quit (Remote host closed the connection)
<niftynei> rusty, correct the DF open worked as expected the first time lol
<ariard> rusty: what flavor of splice-in it's about? you parallelize channel updates until new funding_txo has enough confirmation?
<niftynei> ariard, by DOS you mean "channel doesn't open (in a reasonable timeframe)"
<ariard> niftynei: yeap funding doesn't confirm in a reasonable timeframe, what should you do?
* orccoin has quit (Remote host closed the connection)
<t-bast> for splice, do you stay quiescent until you have on-chain confirmations?
<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
<niftynei> :s/in theory//
<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.
<rusty> t-bast: naah, just during active negotiation.
<rusty> t-bast: i.e. tx construction.
<ariard> niftynei: it sounds good in non-adverserial settings, in non-adverserial settings you should beware upper bounding your fee-bumping
<ariard> *adverserial settings
<t-bast> how does that work if that tx never confirms?
<t-bast> you *have* to make it confirm through CPFP whatever the cost?
<niftynei> right now you have to CPFP a channel open if it doesn't confirm
<rusty> t-bast: you carry those forever, and you can have multiple; only constraint is that they must pay 1.25x feerate of previous.
<niftynei> the DF protocol provides a method for initiating an RBF with your peer
* orccoin (~Rheanna@101.91.232.94) has joined
<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)?
<rusty> t-bast: no, they are all in parallel.  You can't start a second on top of the first.
<rusty> t-bast: (we had to stop somewhere!)
<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?
<t-bast> Like a close and an open merged in one tx (with the opportunity to dual-fund added)?
<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.
<t-bast> oh ok so this other splice would replace the previous one entirely?
<rusty> t-bast: we carry all the possible splices until one wins 6 confs.
<rusty> Then we clear them all, and you can propose a new one.
<t-bast> Ok, that's clear now
<t-bast> Thanks
<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.
<t-bast> Interesting, I can see the synergy with interactive-tx then
<ariard> you should beware of respecting the absolute fee for RBF, otherwise you lastest splice might not propagae
<ariard> though do you really care as long as you expect *any* one of them to confirm?
<rusty> ariard: exactly.
<niftynei> yeah, it's possible you make a non-propagating tx but then you'd just try again?
<rusty> (Though you're right, proposer should check this!)
<rusty> But this is why it kind of goes with splice-to-close, since you can't currently shutdown with outstanding splices.
<ariard> niftynei: nightmare scenario where a reorg occurs, and a parent gets unconfirmed violating bip125 rule 4?
<niftynei> how big of a reorg are you talking?
<ariard> *rule 2 : don't add new unconf input
<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?
<niftynei> what makes this a nightmare scenario ariard?
<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?
* jonatack (jon@gateway/vpn/airvpn/jonatack) has joined
<ariard> niftynei: parent might get double-spent, and you have to adapt your tx construction ?
<rusty> ariard: yeah, that'd cost you 25% bump in fees, but is possible?
<niftynei> iiuc for channel opens, you'd have to RBF the tx *again*. you don't lose anything but time
<niftynei> oh right and the fee bump rate
<rusty> Maybe 25% is too harsh, but as ariard says, if you're using low-confirmed txs you're playing with matches already maybe?
<ariard> niftynei: depends if you have a double-spend in network mempools not signaling rbf, RBF on your side is pretty useless
<niftynei> this could happen with a normal channel open today also, no?
<niftynei> ah wait, no it's a RBF only corner case and you can't rbf an open today. ok
<ariard> niftynei: with a normal channel open, the funder will either double-spend or RBF
<niftynei> you cant RBF an open right now, you'd have to CPFP it
<ariard> with dual-funding or N-funding, each counterparty might have a rebroadcast/differing policy failure
<ariard> like Alice is trying to RBF, but Bob already reaches his funding timer and double-spend his contributed inputs
<niftynei> the mitigation for these corner cases is the same though, no? you double spend an input.
<niftynei> ok so at some point Alice will also hit her funding timer and double-spend her input
<ariard> niftynei: that's a nice failure if both counterparties double-spend their inputs at the same time
<ariard> niftynei: really messy cases it's when your counterparty pin the funding transaction to block your double-spend propagation on the network
<niftynei> does 'at the same time' matter? eventually they should both end up in the same state
<niftynei> true, that does sound messy
<ariard> anyway, i think we'll improve those cooernes cases over time, the core interaction protocol sounds good enough for me :)
<niftynei> any time someone blocks a tx propagation it gets messy haha
<ariard> Package Relay Solves This (or maybe Eltoo?)
<niftynei> PRST !!
<niftynei> haha
<ariard> any other topic or we shutdown here?
<niftynei> cool, thanks for lending your pinning + feerate expertise to the review!
<ariard> niftynei: yw, feel free to ask further questions on the pr :)
<rusty> ariard: I think we're overtime, but good conversation!@
<ariard> yep was a good one
<ariard> #endmeeting
<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)
<lndev-bot> Minutes:        https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.html
<lndev-bot> Minutes (text): https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.txt
<lndev-bot> Log:            https://lightningd.github.io/meetings/lightning_dev/2021/lightning_dev.2021-05-10-20.07.log.html