t-bast
commented
3 years ago As usual, please suggest other topics / reorder them as you think makes sense.
Closed t-bast closed 3 years ago
t-bast
commented
3 years ago As usual, please suggest other topics / reorder them as you think makes sense.
joostjager
commented
3 years ago There are several bigger projects / long term plans on today's agenda and elsewhere in this repository. I think it could be worth having a discussion about priorities. One way to frame this is via the following question:
If there would only be resources to finish one of these projects in 2021, which one would you choose and why?
t-bast
commented
3 years ago Good idea, it's a good opportunity to discuss priorities!
ariard
commented
3 years ago Github built-in security tab for vulnerability disclosure (@ariard)
You can drop this, I did investigate this a while back. It was pointless as it's some kind of integrated security workflow with GH. Not great as it's increasing project dependence towards the platform.... (though IIRC they have some notifications systems in case of security issues in your repo dependencies)
t-bast
commented
3 years ago You can drop this, I did investigate this a while back.
Thanks for the update! I'll remove it then, let's just beef up our SECURITY.md with instructions if necessary.
t-bast
commented
3 years ago <t-bast> #startmeeting Spec Meeting
<lndev-bot> Meeting started Mon Mar 15 19:01:57 2021 UTC and is due to finish in 60 minutes. The chair is t-bast. Information about MeetBot at http://www.foss-eda.org/.
<lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
<lndev-bot> The meeting name has been set to 'spec_meeting'
<t-bast> beautiful!
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/853
<cdecker> The log upload isn't automated just yet, I'll publish them on github afterwards
<t-bast> Thanks cdecker!
<t-bast> #topic Update closing fee requirement for anchor outputs
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/847
<t-bast> As discussed last time, I updated the requirement to only apply to anchor outputs
<ariard> SGTM, if the channel is anchor, the receiver just shrugh about the proposed feerate?
<rusty> Yep, looks good. I can easily implement this.
<cdecker> Sounds good, I think that was the only nit we found
<lndbot> <johanth> ACK
<t-bast> ariard: exactly, you go do your negotiation algorithm to bring it closer to what *you* think is a good fee, but you let the peer start with a fee that's decorrelated from the commit tx fee
<jkczyz> hi
<t-bast> hey jkczyz!
<ariard> t-bast: i think this is smarter you might have a bit of time elapsed since lastest update, mempools fee might be far away
<ariard> in both sense, either higher or lower
<t-bast> yes exactly, this lets you use what's happening on-chain right now as your basis for starting the fee negotiation, regardless of past decisions for the commit tx feerate
<t-bast> BTW since this is linked to the fact that we artificially keep the feerate low for anchor output commit txs, I have a quick Q for the lnd folks who are more advanced there
<t-bast> IIRC lnd by default caps the commit tx feerate at 10 sat/byte, correct?
<t-bast> What does it do when it's below the min-relay-fee (a few weeks ago, the mempool was purging at 11 sat/byte)?
<ariard> t-bast: you mean the mempool min fee, we don't dynamically update the min-relay-fee?
<ariard> iirc
* inara` (~inara@static.38.6.217.95.clients.your-server.de) has joined
* otoburb_ (~otoburb@unaffiliated/otoburb) has joined
* ChanServ gives voice to roasbeef
* inara has quit (Ping timeout: 256 seconds)
* otoburb has quit (Ping timeout: 256 seconds)
<t-bast> ariard: yes mempool-min-fee (the dynamic threshold that changes based on mempool load)
<ariard> min-relay-fee is just a penalty applied for rbf replacement
<t-bast> actually this Q is for everyone implementing anchor outputs with a capped feerate BTW, don't be shy :)
<roasbeef> oh wow, the bot is back!?
<lndbot> <johanth> lnd is currently unaware of this dynamic min relay fee
<t-bast> roasbeef: hey, it's 2021, we had to have a bot, credits to cdecker xD
<lndbot> <johanth> So the user must increase it manually if it’s a problem
<cdecker> Not quite automated the bot yet, but working on it, and at least we get a working record now :-)
<ariard> is this 10sat/vbyte feerate applied on commitment ?
<t-bast> johanth: ok, that's what I was planning to do as well for eclair: let the user watch macro conditions and increase this pre-emptively if he doesn't feel safe
<roasbeef> we have an issue to expose a flag to modify it (could possibly be a call) that should land in the next release
<lndbot> <johanth> it’s already a flag
<roasbeef> alternatively it could try to watch the full node RPC itself, but light clients don't have access to that fwiw
<roasbeef> ah cool I missed that
<t-bast> I was thinking longer term, that it may make sense to watch your mempool-min-fee, and ensure your commit tx feerate is always at least twice that
<rusty> (In vaguely related stuff, we had an issue that our smoothed "slow" feerate (100 ECONOMICAL) fell below mempool min fee, and it meant users saw sadness if they specified "slow" as the feerate for txs).
<ariard> t-bast: if you're running a big node, I would advise to use the median of few different full-nodes...
<roasbeef> so w/ #847 there'd be no "cap"? as otherwise rn you know the fee rate can only be so high on a coop close transaction
<t-bast> ariard: that's clearly a good idea!
<roasbeef> has eclair modified their neogtitation logic to handle tht lack of a fee cap now t-bast ? (well w/ that?)
<t-bast> roasbeef: yes we've updated eclair (but since we haven't turned on anchor outputs, it's still "hidden")
<ariard> generally you should cap the feerate on bumping transaction on the sum value of HTLC at stake
<roasbeef> t-bast: so what's the new policy? pick a new cap based on a multiplier?
<ariard> and _not_ your local balance itself
<roasbeef> (this is for the coop close fee rate btw)
<t-bast> roasbeef: right now there's no cap, but we'll introduce one, not sure based on what (maybe locally observed feerate times a small multiplier)
<roasbeef> gotcha yeh that's something that just came to mind, as now a responder can cause the initiator to bleed out more fees if that isn't minded after #847
<t-bast> I think roasbeef is discussing #847 but the rest of the room was talking about commit tx feerate, make sure we don't get confused between the two!
<roasbeef> oh yeah..I was talking about the implicaitnos on coop close
<roasbeef> since rn the intiator knows they'll pay no more than the current commitment fee rate, and both sides cna use CPFP to increase it further if they wish
<t-bast> Regarding #847, I think we can let implementers decide how they tweak their negotiation algorithm to impose a user-configurable cap on the other side
<rusty> We currently (by default) split the difference between our offer and their offer, but we'll cap their offer to the max we consider reasonable I think.
<t-bast> #847 is really to unblock anchor outputs, because otherwise it cannot be spec compliant in mutual-close scenarios
<roasbeef> feels like we might end up w/ force close scenarios again during co-op close like we did waaay back....
<roasbeef> unless they just now take w/e lowest one they received
<ariard> in case of disagreement, I think that's fine to take the latest feerate agreed by both, if you have a balance on the closing_tx you can still CPFP
* deusexbeer has quit (Ping timeout: 260 seconds)
<cdecker> Seems gameable if we use the lowest (I could propose something that doesn't confirm)
<roasbeef> ariard: but there can be no "agreement": I send 100 sat/byte, what do you do now?
<roasbeef> there's already a whole can of worms w.r.t the current "negotaition" aside from this...
<ariard> roasbeef: right, in that case you fallback to unilateral close, should we specificy some $CAP in the spec
<ariard> where $CAP is implementation-fulfilled
<roasbeef> it needs to be signllaed tho right?
<roasbeef> coul dbe sent in tlv in shutdown msg?
<t-bast> I agree, implementations need to enforce a cap on the first fee proposed by their peer, but I think it should be implementation-specific (probably user-configured with good defaults)
<niftynei> what happens if the cap's exceeded?
<roasbeef> initiator could communicat their cap right when it starts
<ariard> i dont' think you need to signal it, ignoring it or being above trigger the same effect?
<t-bast> niftynei: you just force-close
<roasbeef> ariard: yeh but it can at least serve as guidance
<t-bast> niftynei: basically you need a cap to decide when a force-close is more economical than what your peer suggest for a mutual close
<niftynei> ... and then use anchors to get the force-close through?
<t-bast> but TBH we should only hit that cap with malicious peers if we use reasonable limits
<t-bast> niftynei: exactly
<roasbeef> niftynei: yeh mnore expensive tho, so you want to co-cop close if you're able to as the initiator, also if you have an upfront shutdown addr
<t-bast> non-malicious and non-buggy nodes have no reason to use a ludicrous feerate there
<roasbeef> malicious and skewed fee estimator at indistinguishable here
<rusty> We already have this issue. You figure out your own preferred range, and only offer signatures within that. If you can't, fail the close. If you end up with a signature from them in that range, use it, otherwise resort to unilateral.
<roasbeef> fee estimation itself has no objective "truth"
<ariard> t-bast: but they might still have a hard time to agree on the required feerate, it depends of your fee estimation and data set available
<roasbeef> rusty: this adds a new thing to accoutn for as there's no ceiling
<t-bast> rusty: exactly, that's the only reasonable local strategy
<niftynei> roasbeef: yeah it's a "quality" problem, not a "truth" problem
<rusty> roasbeef: yeah, but we always had the floor problem, so now you just have to maintain both ends (spoken as someone who hasn't *implemented* this yet tho!)
<roasbeef> floor was also "kinda" already there right? 1 sat/byte
<roasbeef> there is no fee top
<roasbeef> (kek)
<ariard> actually floor should be updated to match dynamic mempool min fee
<roasbeef> even that's just policy tho ariard, it isn't a global param
<roasbeef> as it changes dpending on the size of each node's configured mempool...
<roasbeef> yours can be higher than all your connected peers as an eaxmple
<t-bast> but that's why you should sample it from multiple bitcoin nodes, as ariard suggested
<ariard> roasbeef: yeah your local mempool min fee obv
* jonatack_ has quit (Ping timeout: 245 seconds)
<t-bast> and always respect your local one otherwise you won't be able to broadcast to your own node xD
<ariard> t-bast: no multiple bitcoin nodes is to mitigate other things...
<niftynei> for the spec, do we need to add anything about this arbitrary, independently defined cap?
<t-bast> ariard: it does mitigate that as well, if your node is the only node in the network to accept your tx you're kinda in a bad state
<t-bast> niftynei: maybe I can add a comment to say that implementers should still think about setting an implementation-dependent ceiling
<roasbeef> niftynei: imo the initiator should signal their cap in shutdown, which lets the responder mind it and lets them avoid a force close scenario, which is the worst cast for the initiator
<ariard> t-bast: how do you know your node is the only node in the network to accept your tx without being connected to all the other nodes :) ?
<niftynei> heh we had a thing about signaling cap/min in the dual-funding protocol but i took it out for reasons...
<t-bast> ariard: not all the others, but you're at least mitigating this risk if you're sampling *a few other nodes* instead of only yours :)
<ariard> you might sample your peers feefilters but that's a bit hacky
* jonatack_ (jon@gateway/vpn/airvpn/jonatack) has joined
<niftynei> i think "signal your fee range for this tx we're co-building" is reasonable
<roasbeef> yeh it's best effort but could help avoid force closes in practice
<niftynei> just gotta make sure the cap you're signaling is in fact a number you're comfortable paying in practice
<niftynei> lol
<t-bast> I'll explore adding a tlv to signal this, and will update the PR
<rusty> Hmm, I think we could have just gone for closer specifying "min, max, preferred" and other side picking a value in that range, TBH (defaulting to preferred if it has no pref)
<roasbeef> gotta think twice before you put in that limit order...
<ariard> i did this for the dlc spec, mentioning bounds to check where bounds are defined by the implementation: https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md
<niftynei> roasbeef: lolll
<t-bast> #action t-bast to add a tlv to signal accepted feerate bounds in `shutdown`
<roasbeef> rusty: not too late? would be an improvement to the current negotiation, which is basically unboounded and both sides have no hints, the game theory there gets kinda wonky
<roasbeef> but maybe for a larger c hange
<roasbeef> similarly, you prob shouldn't send sigs each time
<roasbeef> do impls throttle the total amt of sigs they send? as otherwise it's also a signing oracle
<ariard> i think a preferred value is useless as counterparties might have diff liquidity preferrences
<t-bast> roasbeef: eclair throttles, yes
<roasbeef> like imagine there's an impl that leaks info re private key bits over time....
<ariard> like one might want the confirm next block the other only don't care if it's a day from now
<rusty> roasbeef: no, we will send infinite sigs if you reconnect, I think.
<niftynei> well if there's just a "here's a range, here's what i'd pick", then the reply can simply be a feerate + a sig at that feerate (within the range bounds)
* treyzania_ has quit (Ping timeout: 264 seconds)
<roasbeef> ariard: it's at least something to use as a hint, otherwise your "satisficement" has no hints to go off of
<t-bast> I'll explore adding this TLV, there's no hurry to merge 847 so it's a good opportunity to do this work here I think
* otoburb_ has quit (Ping timeout: 264 seconds)
<t-bast> Shall we start discussing each team's priorities for 2021? I think it's going to be a very interesting discussion to have
<ariard> roasbeef: i mean a preferrence make sense locally but not announced to the counterparty
<roasbeef> an rn there're really not many bounds...like one side can just never budge and may the other side acquiesce
<roasbeef> make*
<roasbeef> t-bast: sounds like a nice meta topic
<roasbeef> w/ the way things are going rn, maybe we'll all actually get to meet up in meatspace near the end of the year too?
<cdecker> That'd be such a nice change ^^
* niftynei knocks on wood
<t-bast> I don't want to be optimistic about that and be disappointed :)
<roasbeef> got my money on fall, FTX should add a "when % of population will be covid vaccinated" event derivative ;)
<t-bast> I'd love to but can't bear the roller-coaster emotional state
* otoburb (~otoburb@unaffiliated/otoburb) has joined
<roasbeef> lol
<t-bast> #topic Discuss implementation priorities for 2021
<rusty> roasbeef: but it's low stakes. I'll only send sigs on feerates I like, and I'll only remember ones similarly. I have a backup plan, so if my peer plays games, meh.
<cdecker> The way switzerland is doing we'll be banned from all other countries :-(
<roasbeef> lolol
<t-bast> cdecker: xD
<niftynei> if catching covid counts, i'm in b4 lolll
<niftynei> *counts as getting vacc'd
<t-bast> niftynei: catching covid, living without electricity, you had a rough early 2021!
<roasbeef> niftynei: something something anti-bodies? ;)
<ariard> we still have the option to meet in some sunny place, isolated from the rest
<niftynei> just living in the future lolol
<ariard> don't forget to watch revoked states broadcast during power outage !
<t-bast> So, who wants to go first to share what (big) feature they'd like to see in LN in 2021?
<joost> Maybe it is useful to make the question a bit stricter: "see and also commit significant resources to in 2021" ?
<niftynei> t-bast why don't you kick us off?
* treyzania (~treyzania@paphos.tr3y.io) has joined
<t-bast> joost: you're right, this is more accountable
<t-bast> right I'll start
<roasbeef> for some definition of "significant" lol
<t-bast> for eclair, our priorities are:1) anchor outputs
<joost> haha, yes. significant = enough to get it released :)
<t-bast> anchor outputs requires a lot of changes to ensure it's always safe, regardless of on-chain fees conditions - there's a lot more work there than we anticipated
<t-bast> So we'll spend a lot of time on getting this right
* jonatack_ has quit (Ping timeout: 256 seconds)
<t-bast> Then I'd love to see a first version of trampoline going
<t-bast> And last thing we can have dev time this year to work on seriously is offers
<t-bast> I think if we're able to get these 3 in with thorough support, we'll be happy
<niftynei> ok so acinq's got: anchors, trampoline, offers
<t-bast> Your turn now :)
* jonatack_ (~jon@37.172.178.208) has joined
<rusty> I think I can take c-lightning...
<niftynei> go for it
<rusty> Dual-funding and possibly a spin-off for splicing, since it's closely related as designed. niftynei is leading that.
<rusty> I've drafted onion messages and offers, though it's hard to make further progress since we don't really have a front-end wallet; really want someone to start playing with it and give feedback.
<rusty> But more sophisticated tx tracking is my current thing (once current delayed release gets out the door), so I can anchor outputs sanely.
<rusty> I'll probably throw in trampoline since it's cool and pretty easy. cdecker, niftynei: did I miss anything?
<cdecker> Mostly usability stuff besides that
<niftynei> that's all i had
<cdecker> We'd like to make it a lot easier to build on, also over the RPC, finally exposing that over the network
<niftynei> so c-lightning: dual-funding, splicing, offers, onion messages, anchor
<cdecker> Sounds like a plan :-)
<t-bast> Great, thanks for sharing! Once we have time to start implementing some onion messaging/offers stuff, we'll be able to provide wallet feedback (from users and our experience integrating it)
<niftynei> oh i missed trampoline
<ariard> RL-side, primary focus is anchor output support and related fee-bumping/utxo management efforts
<ariard> we're also open to implement trampoline
<ariard> beyond, I don't think we've that much discussed about our priorities
<roasbeef> on the lnd side we're pretty close to rolling out an initial version of AMP, we have things working end to end in a simplified scenario, and conner is pretty far along w/ a standalone spec doc (call it a LIP? lol) for the change itself
<ariard> personally, i'll also focus on package relay and better L2 support on core-side, gonna be time consuming
<ariard> other RL contributors might have bandwidth to work on offers/dual-funding, but not I :)
<t-bast> ariard: package relay would be awesome, it would simplify fee management greatly!
<ariard> t-bast: i don't give timeline anymore, mempools refactors to support it are likely to be gory...
<roasbeef> I'm also nearly done w/ a PoC for dynamic commitments alongside a standalone spec doc, it jsut does something basic rn (increase the anchor output size), but imo is an important meta upgrade as it preps us to experiment w/ taproot stuff later (hopefully? kek) and make certain flow control limits dynamic/changeable which can partially mitigate channel jamming by letting peers btter manage their available HTLC slots
<rusty> roasbeef: awesome, def something we'll need as the taproot tsunami hits.
<roasbeef> related to that is adding in soft errors based on TLV extensions, as it lets you communicate unsupported state transitions, etc and is just all around pretty useful from our PoV
<t-bast> roasbeef: good point, I forgot about dynamic commitments, that's also something we'll find time to work on (but probably later this year)
* ThomasV (~ThomasV@unaffiliated/thomasv) has joined
<niftynei> to summarize RL: anchors, trampoline, package-relay in core
<ariard> roasbeef: instead of starting a LIP, what do you think about refactoring the spec as you previously offered to do it ? ofc a meatspace meeting could be better to exchange on such more modular spec but...
<roasbeef> beyond that we want to look into experimenting w/ some alternative non-sat-punitive ideas to mitigate channel jamming, and also have some renewed interest to trampoinle possilby as we're interested in opening up the protocol so we can explore other methods for packet routing beyond source routing, etc
<roasbeef> there's some loftier stuff like a payment level ack, tho we haven't really discussed it in much detail
<bitconner> hey y'all, sorry i'm late. had to vacate my apt while a repairman fixed the dishwasher
* bitconner catches up
<cdecker> Hi bitconner ^^
<t-bast> regarding channel jamming, I think there's room for more research work (before starting any spec work): I liked the early proposal by ariard and gleb, and there are probably other ways of doing it that we could find
<roasbeef> bitconner: lemmie know if there's anything I missed there above ^
<t-bast> Hey bitconner!
<roasbeef> t-bast: yeh varying mitigations also have diff scopes re deployment (some can be just sender and intermediate, others entire network, etc)
<roasbeef> i'm generally bearish on any thing that tries to make the attacker spend a de minimis amt of sats tho, as they're already not doing it for direct gain, and seems any amt woul dneed to be more than on chain fees to actually make a difference
<t-bast> roasbeef: yes, TBH I'm not satisfied with "the best thing I got currently", this is why I haven't pushed much on it, I'm hoping smarter people find better ways of addressing this
<roasbeef> kinda falls back to the OG idea of just force close and spend a proof back...
<joost> roasbeef: they could be in it for direct gain if they're routing nodes that want to disable the competition
<roasbeef> but even before that, better education to routing nodes w.r.t what all their available params actually even do can go a long way
<ariard> t-bast: yeah wrt to stake certificates we're likely dependent on taproot pubkeys for the cryptosystem, have to investigate further
<roasbeef> joost: then they get disabled back? seems to devolve down to the game theory w.r.t miner block withhlding in competing pools
<rusty> I'm pretty convinced we eventually need both prepay and a long-time penalty, but allmy schemes for prepay needs someone crypto smarter to help me decorrelate.
<niftynei> have we had any in-depth convos about the channel-jamming problem space? it might be fun to hop on a call about
<joost> roasbeef: could be the same, but it may play out differently too for routing
<roasbeef> tons of convos on the ML niftynei, but long threads can be kinda hard to follow
<roasbeef> joost: mhmm yeh just saying could prob gain some insights from studying a similar-ish problem, ofc the stakes are much higher w.r.t mining revneue vs off-chain fee revenue as well
<ariard> niftynei: https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
<niftynei> feels like this has a nice tie-in the the velocity metric the pool paper established
<niftynei> you only really care about jammed channels so long as there's other payments that aren't able to be completed etc
<niftynei> (don't remember the exact name of the pool velocity thing lol)
<ariard> jammed channels are also a building block for some probing attacks
<t-bast> exactly, as niftynei says it's a good problem to have, that means the network is successful
<t-bast> I think it's important to dedicate some research into it in 2021, but too early to go to spec/implementation
<roasbeef> routing volume is def rising from a few sample points of mine
<roasbeef> even my node routes now lol
<niftynei> lolol
<niftynei> (same same)
<t-bast> yes routing volume is rising, but we're far from being overloaded right now
<t-bast> and it's hard to tell whether the rise in bitcoin price will make people use it more or less for payments
<t-bast> but I don't want to stir the store of value / digital cash debate, we can have that one (again?) later xD
<rusty> (FWIW: I tried to pay for my new coffee machine with Bitcoin, dude said "err, no", so I think we're not there yet)
<niftynei> to go back to the 2021 discussion, is someone avails to give us the electrum list?
<t-bast> I think ThomasV is online for electrum
<t-bast> rusty: nice try though :)
<roasbeef> exchanges are more of a thing now on LN also, so may see a rise in ppl wanting to move stuff around more quickly to avoid on-chain fees
<t-bast> roasbeef: that's right, exchanges are probably what's going to impact the volume most in 2021
<joost> In case someone missed it: I've posted a simulator google sheet for bidirectional fees (building on t-basts initial idea) to defend against channel jamming to the ML. If anyone is interested in a solution in the category 'sats punishment', consider taking a look. I'm still looking for reasons why this variation wouldn't work.
<rusty> joost: oh, nice! Link?
<ThomasV> t-bast: hey
<roasbeef> t-bast: yeh we just need one more exchange for the trifecta
<niftynei> sweet joost! can you post the link here?
<joost> rusty: https://docs.google.com/spreadsheets/d/1UX3nMl-L9URO3Vd49DBVaubs6fdi6wxSb-ziSVlF6eo/edit#gid=0
<t-bast> joost: I think it's an okay proposal, but I'd just like to see more research into alternatives, as it's still pretty invasive and needs to be globally deployed to work
<niftynei> danke
<niftynei> !!
<gribble> Error: "!" is not a valid command.
<joost> but probably requires reading the thread as well
<t-bast> ThomasV: we're discussing each implementation's priorities for 2021, could you share what your priorities are for Electrum?
<joost> the sheet allows trying out various scenarios of nodes acting badly
<joost> t-bast: yes it is invasive, but also it is something that I think works for all scenarios. As far as I can see, it is always the adversary who pays for the damage. To me it is an interesting question how much time we've got left to wait for alternatives
<ThomasV> t-bast: trampoline, anchor outputs, taproot. probably also offers
<roasbeef> joost: ofc how much of a cost is actually substantial? imo hard to gauge what the actual mitigation will be, particularly if an attacker is well funded and the costs are much lower than setting up chans in the first place, seems difficult to paramertize
<ThomasV> ghost43 may have more to add
<t-bast> Thanks for sharing ThomasV!
<joost> roasbeef: parameters are chosen based on time value of bitcoin. each node can set their requirement there, so that even when fully jammed, they'll still see a return
<joost> roasbeef: channels can be used endlessly for attacks, so that cost can be amortized over a long time
* cryptapus_ (~cryptapus@jupiter.osmus.org) has joined
<ariard> i think this proposal still have the concern about unbalanced hold fees paid between backwanrd and forward channels for routing nodes
* cryptapus has quit (Ping timeout: 256 seconds)
<ariard> especially if settlement don't happen at the same time due to a malicious backward node, though we already discussed this on the ml
<t-bast> ariard: I think that's addressed by the forward fee being constant and very small, and backward fee bigger and deduced from the signed commitment? But I may be misremembering some details
<ThomasV> t-bast: also, lloyd fournier made a few interesting proposals last year about boating accidents. rusty proposed to add that to channels v2
<t-bast> ariard: it would really need a prototype implementation to figure out these details
<ThomasV> I would love to hear about that
<ariard> t-bast: have a look on last joost proposal it did account for time delta and thus fees weren't constant
* rusty still doesn't understand the streaming fee antispam proposal, will have to re-read.
<ariard> t-bast: yes this was my suggestion too, hard to reason on without code
<roasbeef> also seems to deolve down to just force closing if the final node doesn't pay
<t-bast> ThomasV: yes, improving the scripts to get better backup capacilities would be great, but I think we'll likely wait for the Taproot wave of changes to do that - it's great to have ongoing research about it though
<joost> ariard: you mean the on-chain settlement case? if you're the attacker's peer it gets more complicated. but I think the main threat of channel jamming is that it can be done remotely
<niftynei> ThomasV, boating accidents?
<joost> ariard: the google sheet was intended as a first prototype
<ariard> joost: yes i agree my security concern assume a malicious peer is directly connected to a routing node to exploit the channel jamming mitigation, can't harvest free hold fees if you're not connected to it
<t-bast> niftynei: it's about the proposed changes to the funding tx script to get better channel backups
<ariard> joost: thanks for the google sheet, going to think about it with other ldk folks
<t-bast> niftynei: mostly these threads: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html and https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002912.html
<niftynei> danke!
<t-bast> I'm going to be heading out soon, thank you all for this meeting!
* pigeons has quit (Ping timeout: 256 seconds)
* pigeons (~pigeons@androzani.sysevolve.com) has joined
<t-bast> Hopefully our meatspace meeting in a sunny place will eventually happen ;)
<rusty> Me too, someone want to close meeting?
<t-bast> #endmeeting
The meeting will take place on Monday 2021/03/15 at 7pm UTC on IRC #lightning-dev. It is open to the public.
Pull Request Review
Issues
Long Term Updates
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.
Post-Meeting notes:
Action items
shutdownto indicate feerate boundsImplementation priorities for 2021