20:11:28 <niftynei> #startmeeting
20:11:28 <lightningbot> Meeting started Mon Jul 20 20:11:28 2020 UTC.  The chair is niftynei. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:11:28 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:12:00 <niftynei> #info agenda at https://github.com/lightningnetwork/lightning-rfc/issues/790
20:12:27 <niftynei> according to this agenda i've got, it looks like 'CLTV expiry delta recommendations' is the first discussion topic
20:13:18 <niftynei> #topic CLTV delta recommendations
20:13:27 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/785
20:13:39 <t-bast> since last meeting, conner raised a point about updating the default min-final-expiry-delta in Bolt 11 as well, which I did in the last commit
20:14:12 <t-bast> it requires a phased change from implementations: when an invoice doesn't specify min-final-expiry-delta, we should now use 18 instead of 9
20:14:43 <t-bast> however when receiving, we should either now write our min-final-expiry-delta in the invoice (instead of relying on a spec hard-coded default value)
20:15:15 <t-bast> or we'll need to keep accepting payments using min-final-expiry-delta=9 for backwards-compat with non-upgraded wallets/nodes that will send 9 by default
20:15:16 <roasbeef> yeh the implicit thing wasn't the best idea
20:15:24 <rusty> t-bast: with the idea we can eventually rely on the default?... one day?
20:15:32 <t-bast> In eclair, I started explicitly setting min-final-expiry-delta in invoices
20:15:38 <roasbeef> we should remove the implicit value and _always_ set
20:15:46 <t-bast> agreed, that's more future-proof
20:16:08 <t-bast> and just in case it's not specified in the invoice (because backwards-compat) we should now send 18 instead of 9
20:16:45 <rusty> Yeah, ack that.  Make it "Reader MUST >= 18 if not specified" and "Writer MUST specify".
20:17:03 <t-bast> rusty: SGTM, I was going to suggest something like that
20:17:14 <t-bast> I'll update the PR to reflect that
20:17:41 <t-bast> #action t-bast to update PR: bolt 11 writers MUST specify min-final-expiry-delta
20:18:28 <niftynei> does anyone have further commment on this topic item?
20:18:42 <niftynei> moving on then
20:19:08 <niftynei> #topic PR #787 add missing MAC check in Act Three
20:19:12 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/787
20:19:53 <roasbeef> seems sane, just approved on the PR, coudl argue that applies everywhere and not just on that step
20:20:10 <renepick1> I already commented that one on git. seems logical
20:20:12 <roasbeef> ah below there it has the same message also
20:20:25 <t-bast> agreed, renepick1 pointed that this is mentioned at the beginning of the bolt, so maybe not necessary to say again
20:21:18 <t-bast> we do explicitly mention it in most places though...
20:21:20 <niftynei> it seems like this change mostly just makes the two decryptWithAD result sections identical
20:21:46 <roasbeef> niftynei: yeh that's how I'm viewing it now
20:21:58 <rusty> Being explicit is nice, coders can usually figure out checklists, and are bad with implied contexts.
20:21:58 <t-bast> for consistency, it's probably worth applying
20:22:00 <niftynei> the symmetry seems reasonable
20:22:41 <renepick1> agree with rusty. we have it at other spots and it makes it easier for coders than cross refs. For motivation I would still keep the sentence at the beginning though
20:22:41 <roasbeef> lgmt'd on the pr
20:22:52 <t-bast> same, ACKed
20:22:54 <niftynei> ok looks like we've got two acks and no issues. i'll merge
20:23:06 <niftynei> #action niftynei to merge PR #787
20:23:26 <niftynei> next up is our Long Term Updates discussion
20:24:45 <niftynei> anchor outputs is listed up first but since renepick1 is here today let's start with the FoaF and rebalancing topic
20:24:51 <roasbeef> anchor seems to be moving along on teh PR, so maybe skip it to let other stuff be discussed since it's kinda dominated the convo the past few meetings?
20:25:13 <niftynei> sg!
20:25:22 <niftynei> #topic FoaF and rebalancing
20:25:26 <t-bast> I think the PR is in good shape, it was easy to implement from scratch. The only place where I hesitated and did it differently from lnd is the case where only one anchor materializes. In that case I used to refund the 330 to the funder's output, whereas lnd doesn't. For simplicity's sake, I think the lnd way of always deducing 660 sats makes sense.
20:25:40 <t-bast> (was my only feedback for anchor that I'd like to see cleared out soon)
20:25:52 <renepick1> did anyone have the chance to look at the FOAF balance sharing proposal?
20:25:55 <rusty> t-bast: yeah, I assumed 660 basically gets added to the fee.
20:26:00 <roasbeef> t-bast: yeh less things moving around kinda, can see it as an extension of the reserve
20:26:24 <renepick1> I guess the main question is if we want to start thinking about sharing balances with neighbors and if the query and reply should look in the way how I proposed them
20:26:52 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/780
20:27:01 <roasbeef> renepick1: sharing balances to give more path finding context, or like down stream forwarding context?
20:27:03 <rusty> I'm confused by the FoaF proposal.  It's unclear what to do with this information, and why is there a query and a reply, not just a "broadcast"?
20:28:05 <rusty> It seems like it could let a node find rebalancing triangles, but not broader topologies.  And all it allows us more "friendly" rebalancing, but there's no mechanism for giving a discount?
20:28:13 <renepick1> the information could be used to a) make path finding decisions b) if utilized properly help with JIT-rebalancing (e.g. to prevent channel probing attacks)
20:28:41 <renepick1> circles of length 4 are also included and the ones of length 5 could be guessed pretty reliably
20:28:45 <t-bast> renepick1: at first glance, it feels like we hope the shared balance information doesn't move too quickly, right? Because it could be quickly outdated if many transactions are happening
20:28:53 <renepick1> as a node could ask all its friends
20:29:10 <renepick1> I decided against broadcasting as a node wants the information at a certain point in time
20:29:26 <renepick1> goes in the same direction as t-bast says about outdating (if I understand this correctly)
20:30:19 <niftynei> i think the stated goals of this proposal are good, but it seems like it's got a lot of WIP markers on it still
20:30:56 <rusty> renepick1: I think it leaks information if I only ask for it when a payment is going through though.  Maybe better as "broadcast no more than every 1 minute": like anything, it's a "good enough" gossip attempt.
20:31:08 <rusty> (Plus, adding a new optional message is trivial)
20:31:47 <niftynei> renepick1 it seems like having an implementation done might help fill in a lot of the gaps here
20:31:54 <renepick1> rusty: I could pose the query also at random times
20:32:15 <rusty> renepick1: which is the same only marginally less efficient and more complex?
20:32:20 <renepick1> @niftynei there is an implementation as a c-lightning plugin. but just to send the query and the reply. not to utilize the results yet
20:32:53 <renepick1> @rusty it allows the node to also include the moments when it "needs" the information to know it doesn't have outdated information
20:32:56 <rusty> renepick1: I would suggest simply sending a set of "flow_dir/amt/scid" tuples (i.e. a new subtype).
20:32:58 <renepick1> but I will think about this
20:33:19 <rusty> renepick1: that's not possible, since it can change?
20:33:23 <roasbeef> if it's path finding, then is it polling based? to avoid having to have even more flooded information
20:33:53 <renepick1> @roasbeef what do you mean with flooded information?
20:33:59 <cdecker> Well, supposedly the FOAF network is rather small already, so flooding shouldn't be too much of an issue
20:34:15 <roasbeef> also fwiw, a few published papers have sown how easy it is to map thing based on probing, but ofc there're other mitigations like setting a lower max_htlc, etc
20:34:20 <roasbeef> every thing*
20:34:23 <renepick1> polling in general would probably be less traffic than broadcasting though. but I will tinker about the broadcast question
20:35:03 <renepick1> @roasbeef that is part of the rational. probing FOAF seems trivial in most cases anyway so why not just asking nicely
20:35:05 * roasbeef zooms out to mention that there's been a TON of published research on LN this year which is great
20:35:15 <cdecker> Problem with probing is that it gets destroyed by JIT-rebalancing, which changes the balances as a reaction to probes
20:35:47 <roasbeef> cdecker: does it tho? as rebalancing can fail, and I can still craft other routes to occupy channels and probe what I really wana
20:35:51 * cdecker agrees that it's nice to see all the good research, though a lot to read it all :-)
20:36:02 <rusty> Yes, I was surprised that this doesn't include JIT routing.  I kind of expected it to give a token which you ca put in your onion to get a "free" HTLC...
20:36:14 <roasbeef> heh yeh i've read maybe 20% of it all
20:36:48 <renepick1> @rusty: I thought I would seperate it from free HTLC stuff and rebalancing onions because I thought the information sharing would be useful for many other settings
20:36:49 <cdecker> I assumed that the information can be used for a JIT rebalancing / routing, which I also assumed was the reason for active queries rather than regular broadcasts
20:37:36 <roasbeef> also re jit rebalancing: why would a node try to optimisticlaly rebalance (which costs them fees), for an HTLC that might not actually be resolved?
20:37:52 <renepick1> can I summerize that we are open to balance sharing within the friend of a friend network and that the question is if it should be broadcast or a query / reply?
20:38:55 <rusty> renepick1: yes, but I'd also like to see a free rebalancing protocol sketched out on top (maybe that's just me).
20:38:58 <renepick1> @roasbeef: I think the main argument for jit rebalancing is to have circular paths with costfree htlcs if every node along the circle decreses their imbalance. it is actually a recommendation for the reply to only include channels along wich a node would want to rebalance
20:39:33 <roasbeef> but then how do you ensure the cohort does the rebalancing in an atomic way?
20:39:44 <roasbeef> like you could doa buncha work, then the htlc gets canceleld back in the next hop due to some policy violation
20:39:45 <renepick1> @rusty: you have my support for that! though it might be tricky to have the free fee rebalancing in a way that it won't be abused to deliver regular payments
20:39:58 <rusty> renepick1: yes :)
20:39:59 <roasbeef> not convined that it makes sense to generate even _more_ forwarding traffic in an attempt to forward a single origin HTLC
20:40:08 <niftynei> it seems like this proposal might greatly benefit from a higher level design and use document?
20:40:41 <rusty> roasbeef: agreed, unless there's some clever free rebalancing protocol, then you can use that to mess up probes.
20:40:56 <renepick1> use document as in product requirement document describing use cases?
20:40:58 <t-bast> agreed with niftynei, maybe instead of a spec PR start with something in the "proposals" format (like I did for blinded paths/trampoline) that's a bit higher level so that we discuss the concept first
20:41:15 <rusty> (Though I thought I had a proposal to include an "amount hint" in channel_temporarily_unavailable replies now we have MPP...)
20:41:29 <roasbeef> in terms of negotaiting the rebalancing up front and making in atomic, there's this: https://dl.acm.org/doi/10.1145/3133956.3134033, not sure if they evern deployed it tho
20:41:42 <t-bast> have a look at the trampoline PR for example, I changed it to include a higher-level design doc with diagrams in the "proposals" folder, I hope it will be helpful
20:41:47 <cdecker> t-bast: well it being a completely separate bolt sort of makes the proposal redundant imho, it's already a well-contained document
20:42:07 <t-bast> cdecker: yes, but I meant something less in "spec format" and more diagram-y / higher level at first :D
20:42:20 <cdecker> Right
20:42:43 <renepick1> @roasbeef I think revive is not quite what we want
20:42:58 <niftynei> renepick1, you can find t-bast's route blinding proposal here https://github.com/lightningnetwork/lightning-rfc/pull/765/files
20:43:20 <renepick1> @t-bast I can try to add a high level proposal / use case document so that we can have a more focused discussion. but the feedback today is very helpful so that I can move this forward
20:43:30 <roasbeef> not saying it's what we want renepick1 , but just some existing related research
20:43:59 <niftynei> ok in the sake of time, let's move onto a quick anchor outputs discussion then
20:44:29 <renepick1> @roasbeef : just saying that I looked at revive because I hoped they would solve the problem for us. but how I understood I think they didn't but it is certainly a point in the right direction
20:44:29 <niftynei> #action renepick1 to consider feedback and update proposal/PR etc
20:44:50 <niftynei> #topic anchor outputs
20:45:01 <cdecker> Awesome, that was a great discussion renepick1 and everybody ^^
20:45:20 <niftynei> #link https://github.com/lightningnetwork/lightning-rfc/pull/688
20:46:13 <roasbeef> so joost is on vacation, so johan is taking over the PR
20:46:18 <roasbeef> w.r.t fixing it up n stuff
20:46:34 <t-bast> I've been able to create anchor outputs channels between eclair and lnd
20:46:40 <lndbot> <johanth> woop
20:46:40 <t-bast> and exchange HTLCs/update commitments
20:46:54 <lndbot> <johanth> cool, yeah mostly waiting from feedback from other impls
20:47:08 <niftynei> i think t-bast had a comment about the 660 vs 330 (trimming etc?)
20:47:12 <lndbot> <johanth> to sort out the latest quirks/questions on the current PR
20:47:13 <t-bast> but I'm having issues during mutual close, signatures don't match...and unfortunately even at debug level lnd doesn't log the tx it signs, so I'm currently combing through your code to add it for my tests :D
20:47:44 <roasbeef> t-bast: interesting, could give you a patch to add more logging there
20:47:49 <t-bast> niftynei: I think rusty said earlier that he also thinks we should always deduce 660 sats even if one anchor doesn't materialize for simplicity's sake
20:48:08 <niftynei> t-bast: ah i missed that :thumbsup:
20:48:26 <t-bast> roasbeef: don't worry, I think I've got it, I'm in `CreateCloseProposal` in channel.go, I should be able to add that log line and figure it out by tomorrow
20:48:28 <rusty> t-bast: and now I've commented the same on-issue.
20:48:58 <t-bast> great, so that clears out the un-materialized anchor refund, apart from that the state of the PR looks mostly good to me
20:49:07 <rusty> Yeah, close tx should *not* have anchors.  Nor should the 660 count towards the "maximum allowable fee" for close tx.
20:49:31 <t-bast> test vectors work, just need to finish interop tests and then do a ton of work on figuring out good ways of doing automatic fee bumping
20:49:36 <lndbot> <johanth> status on the lnd implementaiont is that we have been running it in the wild for a while, no major issues
20:49:43 <rusty> i.e. "base fee" definition is unchanged.
20:49:47 <lndbot> <johanth> no automatic fee bumping yet tho
20:50:12 <rusty> johanth: any particular node I should test against?  Mainnet OK...
20:50:33 <lndbot> <johanth> hehe, I can send you a node URI for sure…
20:50:43 <lndbot> <johanth> still using the 1337 bit
20:50:57 <lndbot> <johanth> so that has to be flipped before going non-experimental
20:51:30 <t-bast> rusty: where are you on the implementation on the c-lightning side?
20:52:21 <rusty> t-bast: it's implemented, pending interop testing (didn't make the coming release).  Doesn't do *anything* with the anchors yet, but ignore them....
20:52:47 <rusty> johanth: ah, OK, I'll hack that feature in...
20:53:00 <t-bast> good, eclair is around the same state as well
20:53:12 <niftynei> do we have any outstanding action items for the anchors PR?
20:53:16 <t-bast> I think we should be able to finalize interop testing before the next meeting
20:53:29 <t-bast> niftynei: nope, good to go!
20:54:05 <niftynei> #action t-bast + rusty to work on interop testing with lnd's anchor outputs impl; will update at next spec meeting
20:54:12 <niftynei> ok we've got 5min
20:54:18 <niftynei> let's talk about protocol tests!
20:54:25 <niftynei> #topic protocol test suite
20:54:40 <niftynei> rusty do you have a link for this?
20:55:03 <rusty> So, cdecker is working on finishing the Sphinx implementation in python, so I can actually test *successful* HTLCs..
20:55:04 <rusty> https://github.com/rustyrussell/lnprototest
20:55:28 <niftynei> #link https://github.com/rustyrussell/lnprototest
20:55:36 <rusty> (Though you can get an awful long way without actually forwarding an HTLC, turns out).
20:55:41 <roasbeef> niiice, have been taking a look at what we need to do in lnd to be able to run as a tester
20:55:57 <cdecker> Aaaaaalmost there, I promise ^^
20:56:09 <rusty> roasbeef: hopefully it's getting less, the test framework is smart enough to adapt, though youj need to be able to reach into your node and extract the secrets.
20:56:38 <roasbeef> yeh seems the main thing is first being able to start an instance w/ a set of canned private keys, and dump other secrets that we may derive off that, so like a special build dev tag
20:56:47 <rusty> Technically this means I've implemented anchor outputs *twice*, but damn it was easier in lnprototest.
20:57:02 <t-bast> damn, I'll need to learn some python :(
20:57:16 * niftynei (sympathizes with t-bast)
20:57:21 <cdecker> Well there is jython xD
20:57:22 <rusty> roasbeef: doesn't need that any more (though c-lightning still does it taht way), but can query node keys at runtime.
20:57:24 <roasbeef> it's like fancy python
20:57:27 <roasbeef> type hints n stuff
20:57:38 <roasbeef> idk what version of python we're even on anymore lol
20:57:40 <rusty> (Don't get me started on type hints in Python....)
20:58:01 <roasbeef> 3.8....woah, and somehow python 2.7 isn't dead yet lol
20:58:05 <rusty> We actually contracted a Python person to look at my code.... TL;DR: it got better.
20:58:39 <t-bast> rusty: xD
20:58:43 <cdecker> roasbeef: 2.X has officially reached End of Life last new year
20:59:11 <t-bast> rusty: so the tl;dr on what we need to do, is plug some hooks in implementations to extract secrets somehow, then write some python to connect with lnprototest?
20:59:14 <rusty> Yeah, I'm aiming for 3.6+, but I know it works with 3.8 because that's here.
20:59:38 <niftynei> rusty is there anything you want people to know when trying to write tests / runners for lnprototest?
20:59:39 <roasbeef> cdecker: only took like a decade or something? kek
20:59:53 <rusty> t-bast: yeah, since the only runner currently is clightning, copy that.  We should probably share some stuff (.e.g a heap of it us just to drive bitcoind for example)
21:00:21 <rusty> And looking fwd to niftynei writing the dual fund tests and providing feedback on what it's like.,
21:00:29 <niftynei> soon! TM
21:01:21 <niftynei> i actually need to head out here shortly
21:01:31 <niftynei> are there any action items for the lnprototests?
21:01:40 <rusty> There'll be some flux as we will no doubt add more requirements for backends so we can test more stuff, but we can do a *lot* with what's there.
21:01:59 <rusty> niftynei: not really, just get people to try to attach it to their implementations.
21:02:00 <niftynei> #action niftynei to write dual funding prototests to dogfood the lnprototest docs
21:02:19 <cdecker> Always remember: the official lightning motto is "duo septimanas" (two weeks) :-)
21:02:27 <niftynei> ehehehe
21:02:30 <t-bast> great, not sure we'll have time to do it in the next 2-weeks period for eclair but if there's a bit of time available I'll take a look at it!
21:03:01 <niftynei> #action lnd + eclair to investigate the runner implementation requirements (time permitting) ;)
21:03:21 <niftynei> ok i think that's all we have time for today
21:03:51 <t-bast> thanks for chairing niftynei!
21:03:53 <niftynei> thanks everyone for your input and participation and we'll meet again soon!
21:03:55 <cdecker> Great meeting everyone ^^
21:03:59 <niftynei> #endmeeting