19:10:11 <roasbeef> #startmeeting
19:10:11 <lightningbot> Meeting started Mon Mar 16 19:10:11 2020 UTC.  The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:10:11 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:10:42 <roasbeef> #topic #737 (reply channel range simplification)
19:11:02 <roasbeef> action item last time was for peeps to cehck if their current implementations were compat w/ the new guidelines (or existing?) in the PR
19:11:36 <roasbeef> i see the PR has an approval from t-bast now
19:11:39 <t-bast> yep, all good on the eclair front
19:11:43 <ysangkok> #link https://github.com/lightningnetwork/lightning-rfc/pull/737
19:12:10 <roasbeef> on the lnd side, we haven't yet checked so see if things sync up, I suspect they do though...
19:12:15 <roasbeef> or do you know off the top wpaulino?
19:13:20 <roasbeef> dunno if he's around
19:13:36 <t-bast> heh no worries, this can carry over if you want wpaulino to double check
19:13:44 <roasbeef> ok no immediate follow up on this then? we can continue the rest on the spec, don't think it's super critical rn, things seem to be working as is
19:14:05 <t-bast> yeah I think we can carry over, maybe have a ping for wpaulino to look at the PR?
19:14:10 <roasbeef> sure
19:14:38 <roasbeef> #action lnd to have peeps take a look at #737, to resolve before next meeting in PR unless major discussion
19:14:53 <roasbeef> #topic #736 (BOLT 11 negative+positive tests)
19:14:57 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/736
19:15:28 <t-bast> This one needs a small rebase (should be simple though)
19:15:54 <t-bast> Did you have time to add these tests to lnd? Does rust-lightning have full Bolt 11 support?
19:16:29 <BlueMatt> rust-lightning I havent dug into. we do have bolt 11 fully implemented, but I need to go ask sebastian who maintains that separate library about it.
19:16:29 <wpaulino> briefly glancing at the PR desc, we expect ordered non-overlapping replies except for the case where the previous reply didn't cover all the channels in a block, so the next one resumes from the same block
19:17:18 <bitconner> t-bast yes i've double-checked the test vectors w/ lnd, should be gtg
19:17:36 <t-bast> bitconner: cool! just needs a rebase then
19:18:00 <t-bast> BlueMatt: good, probably worth pinging sebastian to add these tests and potentially fix some missing negative cases
19:18:33 <roasbeef> #action rebase #736 for merge
19:18:38 <t-bast> wpaulino: the change now is that it's disallowed to have next reply resuming the same block as the previous one
19:19:00 <roasbeef> why? you can make a response to is the same block but consumes two messages
19:19:04 <t-bast> wpaulino: you may accept it as a reader, but as a writer you shouldn't do that, do you know if lnd may split a block in multiple replies?
19:19:06 <roasbeef> feels like we covered this last time?
19:19:53 <t-bast> but the PR states that right now, Rusty said "a single block's channels are always in the same response"
19:19:58 <cdecker> Oh, looks like I got tricked by DST changes again...
19:20:03 <cdecker> Sorry for being late everyone
19:20:06 <t-bast> maybe it's still unclear in the PR?
19:20:12 <t-bast> Hey cdecker! :)
19:20:25 <roasbeef> t-bast: yeh on avg they are, but it's possible to construct a block where that's no longer true
19:21:06 <roasbeef> maybe let's continue this on taht PR so we can go thru the rest of the agenda
19:21:26 <t-bast> roasbeef: sounds good, let's raise that on the PR then
19:21:44 <roasbeef> added by approval to #736, g2g after rebase
19:21:57 <roasbeef> #topic #754 (tlv everywhere message extensions)
19:22:01 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/754
19:22:28 <roasbeef> lnd has implemented this, it works, but we ran into a small issue w.r.t our implementation, shouldn't block the concept tho
19:22:31 <t-bast> TLV everywheeeeere
19:22:35 <roasbeef> hehe
19:23:05 <t-bast> neat, FWIW it's implemented in eclair too and deployed on the acinq node if you want to test E2E
19:23:18 * BlueMatt probably wont bother implementing it until there is actually data worth reading as tlv on messages, fwiw.
19:23:21 <roasbeef> responded today to t-bast's responses, will take another look after this meeting, but no major objections so far, just minor wording/recommendation stuff
19:23:38 <t-bast> cdecker/niftynei do you know if there's been work on that on the CL side? I know rusty does need this for offers
19:23:45 <BlueMatt> as it is strictly a smaller set of accepted messages.
19:23:52 <t-bast> thanks roasbeef, I'll add the small comment you mentioned
19:24:02 <BlueMatt> dunno why its worth implementing anywhere until then, but whatever
19:24:08 <t-bast> BlueMatt: good idea, do you support upfront_shutdown_script?
19:24:14 <BlueMatt> yea, of course.
19:24:27 <t-bast> BlueMatt: I think the main part that's worth adding to rust-lightning right now is to at least make the fields mandatory
19:24:27 <cdecker> I don't think we have explicit support for the recasting of the shutdown script yet (still interpreting it as a plain old field)
19:24:29 <BlueMatt> ah, cause that can be mis-interpreted?
19:24:52 <cdecker> But it shouldn't be too hard to implement (and it'd simplify our message parsing for that case too)
19:25:02 <BlueMatt> right, well we're about to make those fields mandatory for static_remotekey anyway
19:25:06 <t-bast> cdecker: good thanks
19:25:07 <cdecker> Overall going TLV only for the future was a big plus on our side
19:25:30 <BlueMatt> (and make static_remotekey mandatory)
19:25:31 <t-bast> BlueMatt: perfect then, should be easy to make those mandatory from the start on your side
19:25:33 <roasbeef> yeh really smoothes things out from here on
19:26:14 <roasbeef> ok so action is CL to implement?
19:26:44 <t-bast> SGTM, if CL can have a look at implementing and verifying that nothing's weird, then we should be good to go?
19:26:50 <roasbeef> ok
19:27:00 <cdecker> We'll likely wait until we actually have new TLV fields that require the recast
19:27:10 <cdecker> For now the serialized format is identical
19:27:30 <t-bast> yeah no worries since this can be viewed as an implementation detail
19:27:35 <t-bast> as long as it does work
19:27:39 <cdecker> Exactly :+1:
19:27:40 <t-bast> at the byte level
19:27:46 <roasbeef> yep
19:28:04 <roasbeef> ok, so we're g2g on this then after an approval from lnd?
19:28:16 <t-bast> SGTM
19:28:31 <roasbeef> #action lnd to take final look at PR for approval, g2g after taht
19:28:42 <roasbeef> #topic #740 (avoid stuck channels)
19:28:46 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/740
19:29:01 <roasbeef> last movement seems to be some relaxation on the new proposed guidelines
19:29:01 <t-bast> maybe after that one (or even now) we could move to long-term stuff?
19:29:12 <roasbeef> last thing after this is wumbo conf t-bast
19:29:40 <t-bast> just want to make sure we have time to cover the long-term things too, should be good if we don't spend too much time on this PR
19:29:57 <t-bast> allright so on 740 the wording is really hard to get right
19:30:04 <cdecker> This is the extra reserve to counter (limited) fee spikes as well, correct?
19:30:06 <t-bast> this is much easier to express in code than in english :)
19:30:10 <t-bast> exactly
19:30:17 <t-bast> the current state of the PR is the following:
19:30:29 <joostjgr> i think the pr looks good, now that the multiplier isn't protocol anymore
19:30:41 <cdecker> Ok, this is nicer than the "allow to dip into the hard reserve", but still ugly AF
19:31:03 <t-bast> The funder should keep that extra reserve and we let some leeway on the exact factor
19:31:32 <cdecker> I guess we can't make it much nicer without eltoo, which defers any fee commitment until close time, so I'm ok with this
19:31:44 <t-bast> cdecker: I know, I know, but we do need a short-term fix for that (and we do need other implementers to be careful about that edge case)
19:31:48 <roasbeef> also with anchors as it progresses ;)
19:31:59 <roasbeef> kinda
19:32:01 <cdecker> Yep, +1 for anchors
19:32:02 <t-bast> anchor outputs does unblock that IMO
19:32:05 <joostjgr> anchors + drop the fee to zero indeed
19:32:22 <t-bast> but it's a bit more implementation work (a tiiiny bit)
19:32:26 <roasbeef> ok so ppl like the simpler version of this?
19:32:32 <cdecker> You can't really drop the fee to zero, you always need a minimal fee to enable relay
19:32:35 <roasbeef> has anyone implemented the new guidelines and tested in the wild?
19:32:47 <t-bast> roasbeef: CL and eclair implement it AFAIK
19:32:48 <roasbeef> cdecker: yeh zero assumes p2p packaged relay widespread support
19:32:59 <t-bast> we've deployed it on mainnet and so far, looking good
19:32:59 <cdecker> We have a PR adjusting the 1.5x multiplier we had so far to 2x
19:32:59 <joostjgr> yes, with packaged relay
19:33:10 <cdecker> It seems to work fine for us
19:33:12 <roasbeef> we've recently modified our logic in this area, it may very well be a super set even of what's described here
19:33:42 <roasbeef> ok, will leave to joostjgr and johan to stamp their approval on the PR since they've been working in this area lately
19:33:44 <niftynei> by 'packaged relay' i'm assuming you mean the carve out exception? or something else?
19:33:45 <roasbeef> on our end at least
19:33:57 <roasbeef> niftynei: like a new p2p messages that lets you relay/request a tx package
19:34:09 <roasbeef> so one can actually have near zero fees since the child pays for all/nmost of it
19:34:12 <BlueMatt> niftynei: he means relaying a child tx along with the parent in bitcoin core. I, at least, strongly, strongly disagree that that is neccessary or even helps.
19:34:35 <t-bast> Can you explain Matt?
19:34:42 <cdecker> I think m-schmoock is most familiar with these edge cases, and how well the extra reserve works, maybe he's here?
19:35:04 <BlueMatt> this is a separte convo we can continue after 740
19:35:49 <roasbeef> #action m-schmoock and joostjgr/halseth to continue on PR for approval
19:35:53 <t-bast> gotcha, would be nice if you can share a somewhat detailed write-up about that afterwards
19:35:54 <cdecker> BlueMatt: I take it you're critical of package rely independently of LN, correct?
19:36:05 <roasbeef> #topic https://github.com/lightningnetwork/lightning-rfc/pull/746
19:36:14 <roasbeef> #info (wumbo conf scaling)
19:36:20 <roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/746
19:36:33 <roasbeef> just need to look at this myself on the PR
19:36:42 <cdecker> NACK, not everything needs to be in the spec :-)
19:36:50 <BlueMatt> cdecker: absolutely not, I think it should happen for various reasons not related to lightning (been wanting it for fibre forever), just noting that I think lightning should be willing to do a low fee without it.
19:36:54 <cdecker> (otherwise I don't really care)
19:37:02 <roasbeef> we don't have a wumbo impl yet, need to modify our csv scaling to fit the new bounds
19:37:36 <cdecker> BlueMatt: ah, ok. Agreed on the minfee paying for its own relay at least
19:38:09 <roasbeef> aight we'll just take this to the spec then?
19:38:18 <t-bast> I think 746 needs more eyes on it, we should end with a concise advisory but that stresses the main points
19:38:25 <roasbeef> i think ppl just wanted mention of csv scaling as well
19:38:40 <BlueMatt> I dont think the rule of thumb should be there
19:38:42 <roasbeef> since that's essentially a security param
19:38:51 <BlueMatt> I dont think its correct and I'm not sure we're gonna agree on one
19:38:55 <t-bast> e.g. I'm still unsure whether to_self_delay should really be scaled
19:39:02 <t-bast> and what factor should be used
19:39:05 <BlueMatt> just noting that this is lightning and we can take a long conf time is good.
19:39:07 <roasbeef> it's one paragraph tops, can be high level just should mention to consider scaling those params
19:39:46 <t-bast> yeah the idea is to stay high-level, but make sure we understand what needs to be scaled to avoid security issues
19:39:51 <niftynei> i think i agree with cdecker; this is a bit too advisory for my taste wrt spec addition
19:39:53 <roasbeef> #action to continue on PR, possibly add csv mention as well
19:39:58 <BlueMatt> the current text is not high-level, its very specific
19:40:13 <roasbeef> yeh comment on teh PR with your recommendations for making it more high level
19:40:16 <BlueMatt> even if it pretends to not be by saying "rule of thumb"
19:40:46 <niftynei> it's not a specification rule tho
19:41:04 <roasbeef> we have other recommendations elsewhere in the spec, this isn't too diff
19:41:20 <t-bast> Then let's discuss on the PR, but I think it's useful to at least brainstorm this. We currently don't scale to_self_delay and I'm still not sure whether it's an issue or not, and would like to avoid users losing money!
19:41:31 <roasbeef> #action ppl to continue on spec that want an advisory
19:41:55 <roasbeef> t-bast: imo it is, if you have a 1K BTC channel, you may want longer just in case your system fails for w/e reason, you prob wouldn't accept a 3 block csv for that
19:42:09 <roasbeef> ok we're done with initial PR/issue stuff
19:42:12 <roasbeef> moving onto the next section
19:42:21 <niftynei> this feels like a great medium post topic :P
19:42:24 <roasbeef> #topic anchor outputs
19:42:43 <joostjgr> i can give the update
19:42:44 <roasbeef> lnd has implemented everything, planning to include behing flag in our next major version
19:42:50 * roasbeef gives joostjgr the floor
19:42:56 <joostjgr> hehe ok thanks
19:43:08 <joostjgr> indeed, implemented the new format, channels are produced with anchors
19:43:15 <t-bast> nice, well done!
19:43:22 <joostjgr> pr that is close to merge is the one that actually allows sweeping and cpfp'ing the anchors
19:43:36 <joostjgr> we have a cli command that allows bumping the close tx
19:43:52 <joostjgr> pr is updated with details that were left out previously (weights etc)
19:44:10 <joostjgr> open discussion is still one vs two anchors, initiated by niftinei
19:44:26 <joostjgr> the anchor commitment format is more expensive than our current format, that is clear
19:44:52 <joostjgr> but one vs two anchors is more subtle. it is a trade-off between cost and decoupling between remote output and remote anchor
19:45:25 <joostjgr> we opted for the two anchor format, so that we can still implement anti-gaming tactics later on without fundamentally changing the code again
19:45:37 <BlueMatt> why is decoupling required? (or even helpful?)
19:45:51 <roasbeef> also re the cost: the extra sats committed to the anchor starts to get dwarfed by fee rate scaling above the min
19:46:01 <joostjgr> so that we can later add symmetric csv delay. the same delay for to_local and to_remote
19:46:04 <roasbeef> BlueMatt: helpful from an implementation perspective, the logic is completely distinct
19:46:07 <niftynei> do you have stats on when the feerate becomes dwarfed?
19:46:12 <roasbeef> the logic for remote+local commitment is the same
19:46:44 <BlueMatt> roasbeef: hmmm, dont think it'll be any more or less complicated on our end
19:46:45 <roasbeef> niftynei: not atm, but it's 38 bytes and 660 sats, can python up some graph
19:46:58 <BlueMatt> I think it kinda sucks to add an extra output just cause it simplifies implementation a tad
19:47:08 <roasbeef> BlueMatt: don't know till you try to implement it ;) we found some surprises in our implementation which caused shifts in the spec
19:47:09 <BlueMatt> especially when the other funds are only spendable after 1 conf csv anyway
19:47:14 <joostjgr> 330 sats will be spend anyway. that is with a single anchor. double anchor is +330 sats
19:47:19 <niftynei> that extra output is expensive imo
19:47:40 <BlueMatt> roasbeef: thats true, I've started a bit, but we've cleaned up the output spending logic a bunch, so I'm like 99% sure it wont matter :)
19:47:43 <roasbeef> it's 38 bytes objectively for each, "expsensive" comes as you scale p the fee rate
19:47:50 <roasbeef> up*
19:48:11 <roasbeef> err more like 43
19:48:48 <niftynei> my very rough calculations showed that two anchors make a commitment tx 5x more expensive (at a very low feerate)
19:49:16 <roasbeef> this optimizes for the case where a very low fee rate could possibly mean loss of funds if you can't bump
19:49:18 <joostjgr> i don't think it is very useful to compare no anchors with two anchors. no anchors is not a solution for the problem that we have
19:49:25 <roasbeef> 5x in that case is still just a few hundred satoshis
19:49:27 <niftynei> the majority of that extra cost is from the output value of the anchor outputs
19:49:28 <joostjgr> the discussion one vs two anchors is more interestnig imo
19:49:49 <niftynei> ok so let's talk about why two anchors is better than one
19:50:06 <roasbeef> you still need two anchors in some cases
19:50:13 <roasbeef> where the remote party has an incoming htlc, but no settled funds
19:50:27 <roasbeef> they need one to anchor down
19:50:32 <BlueMatt> but any amount that you could set the anchor to could also be set as minimum push_msat
19:50:34 <joostjgr> going from one to two anchors costs an extra 330 + 43 * fee_rate. so indeed, at high fee rates, the 330 becomes less significant.
19:50:58 <BlueMatt> its also kinda shitty to the bitcoin network to add extra outputs just case
19:51:17 <roasbeef> they can be swept pretty easily and easily recognized also
19:51:39 <BlueMatt> right, but if feerates go up, sweeping will not be economical
19:51:44 <roasbeef> wouldn't categorize it as "just cause"
19:51:49 <BlueMatt> and swept or not, its still extra outputs + inputs that need to process
19:51:56 <roasbeef> it can be it bundled with others
19:52:08 <roasbeef> yeh in our code we handle it, but distinct from the lifetime of the channel mostly
19:52:12 <BlueMatt> yes, still an extra output + input
19:52:35 <BlueMatt> roasbeef: can you be more concrete as to why its really helpful for y'all?
19:52:36 <joostjgr> if we still want to get rid of the situation where one party tricks the other party into force closing, so that it gets sooner access to its funds, we need two anchors. otherwise we can't add the symmetric csv feature.
19:52:43 <roasbeef> which still needs to be there in the case I described above
19:53:09 <BlueMatt> joostjgr: well, we're not doing that now, right? so I think if thats the best argument we have we should weigh one anchor against 2 + symmetric delays
19:53:15 <BlueMatt> which seems like a future discussion
19:53:15 <roasbeef> BlueMatt: it creates no spcial cases, the two anchors are always there, the anchors can be procssesd indepdently of the lifetime of the channel, the code is also isloated
19:53:49 <roasbeef> two anchors also decoupled things from the script/shape of the settled commitment outputs as well
19:54:01 <roasbeef> two always*
19:54:07 <BlueMatt> hmmmm, that doesn't tell me much? I mean its not a "special case" to use a to_remote to cpfp, no?
19:54:44 <roasbeef> special case as in somtimes having it there and sometimes not having it there
19:55:01 <roasbeef> the logic is then also asymmetric, sometimes you use the anchor vs sometimes using your own output
19:55:01 <BlueMatt> right, you already have a ton of code for local-vs-remote broadcasts?
19:55:21 <niftynei> just for posterity's sake, here's my comments on feerates/extra cost https://github.com/lightningnetwork/lightning-rfc/pull/688#issuecomment-591026162
19:55:22 <BlueMatt> the only difference in logic is exact signing format
19:55:30 <roasbeef> yes due to the asymmetric nature of the base commitments, but symmetry in this case simplifies things
19:55:59 <niftynei> simplifies things for .. the developers?
19:56:02 <roasbeef> BlueMatt: there's more than that, sweeping is distinct as well, how you sweep the fee rate, the urgency, etc
19:56:16 <BlueMatt> hmmm, do others have any input here? It doesn't simplify stuff much for us.
19:56:44 <cdecker> Neither for us if I am seeing this correctly
19:56:45 <BlueMatt> roasbeef: right, but in this case there is no sweeping, which is strictly better anyway :)
19:56:47 <roasbeef> may be hard to fully grasp what we're trying to communicate here without actually implementing the entire thing
19:56:59 <BlueMatt> roasbeef: no, I get what you're saying
19:57:21 <roasbeef> niftynei: simpler code. less bugs, less corner cases, decoupled to make room for future changes in to_remote outputs
19:57:27 <BlueMatt> it is more code paths in some ways of implementing on-chain handling, though the way we've been refactoring things it wont be, but in our old implementation i would have been
19:58:00 <BlueMatt> I, however, dont think its worth the social cost on the chain + the fee cost in outputs
19:58:03 <roasbeef> something something devil details
19:58:04 <joostjgr> how do people feel about 'one anchor' vs 'two anchors + sym csv' then?
19:58:19 <niftynei> those are all developer centric rationales, none of which address added utxo footprint or decreasing available channel funds in the short/low network fee situations
19:58:33 <roasbeef> BlueMatt: do you see the case that you need to have two outputs at times in certain cases?
19:58:55 <roasbeef> niftynei: utxo foot print is also inherent in having the anchor or not, we expect ppl to sweep them
19:59:01 <BlueMatt> roasbeef: what do you mean two outputs? you usually have many more outputs than that due to htlcs
19:59:05 <roasbeef> if you channel is tiny, then you're gonn ahave issues with high fee rates
19:59:16 <BlueMatt> roasbeef: its still utxo footprint cause sweeps cost $
19:59:33 <roasbeef> BlueMatt: yeh that's what I mean, htlcs bring you up to teh same cost, doubly if they're tiny htlcs, two outpouts in that if the remote party has an incoming htlc but no funds, they need that second output
19:59:35 <BlueMatt> or, at least, transaction footprint
20:00:46 <BlueMatt> I'm confuse what that has to do with this conversation, though? If your remove have no/dust funds, we'll need to add either a to_remote or add a to_remote_anchor
20:01:01 <BlueMatt> either way you get that extra output, but in the general case, having no remote_anchor means much lower tx cost on-chain
20:01:06 <BlueMatt> which is a big social good
20:02:11 <roasbeef> i g2g
20:02:21 <BlueMatt> ok, we'll continue this another time!
20:02:28 <BlueMatt> maybe it makes sense to schedule a meeting to just get this over the line
20:03:03 <cdecker> I have to agree with BlueMatt, we've so far minimized our on-chain footprint at every point in the protocol, I don't see why we should not minimize this time, just because there's other baggage in the same TX (HTLCs)
20:03:07 <joostjgr> maybe it is useful to think about the importance of gaming resistance and adding symmetric csv. that may inform the one vs two anchor question.
20:03:40 <niftynei> iirc it still requires another implementation to be eligible for inclusion. it seems like a second opinion on this might be helpful, since it seems the crux of the matter deals mostly with implementation details
20:03:40 <BlueMatt> joostjgr: yea, thats a conversation I cant add as much to, but is worth discussing.
20:03:47 <roasbeef> this is a pretty high prio change imo, fees have ticked up a bit due to the recent craziness, and not sure how confident ppl are in their ability to resolve higher value HTLCs w/ congestion particularly w/ wumbo channels/payments
20:03:55 <joostjgr> we wanted to do that initially, but only dropped it because we couldn't agree on how the csv value was negotiated in the channel opening sequence. a relatively minor issue
20:04:03 <t-bast> I agree that the symmetric csv is also something we know we want to have in the future, so we mustn't make this impossible
20:04:26 <BlueMatt> t-bast: right. in theory we can also punt on that and add another output at that time
20:05:04 <joostjgr> or do 2 anchors + sym csv right now. just resolve our minor difference in preference around negotiating the actual value
20:05:12 <joostjgr> commitment formats are definitely not free to add
20:05:14 <t-bast> I admit that without having implemented it, I'm sure I'm missing a lot of the points, so I can't really argue much on that
20:05:51 <roasbeef> also I wouldn't underestimate the amount of work to impl (final parting thought lol)
20:06:02 <BlueMatt> roasbeef: agreed. we can schedule another meeting to get it over the line imo
20:06:07 <roasbeef> i'm gonna end it now, but feel free to continue to discuss, will read the scrollback
20:06:11 <roasbeef> #endmeeting