--- Log opened Mon Mar 16 00:00:24 2020 00:23 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Quit: Leaving] 00:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 00:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 00:44 -!- vasild_ is now known as vasild 01:25 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 01:25 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 02:11 -!- marcoagner [~user@2001:8a0:6a5f:a900:6d3e:1158:b50:97b6] has joined #lightning-dev 02:18 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:31 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 03:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 04:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 04:44 -!- _tnull [~tnull@gateway/tor-sasl/tnull/x-89080035] has joined #lightning-dev 04:49 -!- slivera [~slivera@37.120.218.148] has quit [Remote host closed the connection] 05:31 -!- gleb1 [~gleb@cpe-67-244-100-77.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 06:06 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:12 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer] 06:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 06:28 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 06:37 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 06:39 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 06:40 -!- Amperture [~amp@65.79.129.113] has joined #lightning-dev 06:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:44 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds] 06:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 06:50 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 07:01 -!- _tnull [~tnull@gateway/tor-sasl/tnull/x-89080035] has quit [Quit: _tnull] 07:14 -!- harding_ is now known as harding 07:34 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 07:39 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 07:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 08:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 08:16 -!- Sajesajama_ [Salsa@gateway/vpn/protonvpn/sajesajama] has joined #lightning-dev 08:17 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 08:18 -!- Sajesajama [Salsa@gateway/vpn/protonvpn/sajesajama] has quit [Ping timeout: 240 seconds] 08:22 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Ping timeout: 246 seconds] 08:33 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 08:35 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 08:40 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 08:50 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 08:54 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 08:58 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 08:58 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 08:59 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 09:00 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 09:00 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 09:04 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Ping timeout: 246 seconds] 09:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:07 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 10:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 10:19 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 10:23 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 10:23 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 10:24 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 10:24 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 10:25 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 10:25 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 10:26 -!- mol [~molly@unaffiliated/molly] has quit [Client Quit] 10:27 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 10:30 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Ping timeout: 256 seconds] 10:48 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:49 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev 10:50 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 10:53 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 10:55 -!- rdymac [uid31665@gateway/web/irccloud.com/x-iqsiapzcldnvnnwv] has joined #lightning-dev 10:56 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 250 seconds] 10:56 -!- __gotcha1 is now known as __gotcha 10:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 11:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 11:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 11:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 11:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 11:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 11:08 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Quit: __gotcha] 11:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 11:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 11:27 -!- Netsplit *.net <-> *.split quits: so 11:27 -!- Netsplit over, joins: so 11:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:56 -!- t-bast [~t-bast@2a01:e34:ec2c:260:c34:dd47:ddf3:8590] has joined #lightning-dev 11:56 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 11:59 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev 12:00 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 12:00 < niftynei> hello 12:00 < t-bast> hello! 12:01 < sstone> hello everyone! 12:02 < niftynei> cdecker did you put together an agenda for today? 12:03 < t-bast> I created https://github.com/lightningnetwork/lightning-rfc/issues/756 with mostly carry-overs from last time 12:03 < niftynei> awesome! 12:03 < t-bast> And maybe we could start with long-term updates / more interesting discussions than PR review, otherwise we spend too much time reviewing things IMO :) 12:04 < t-bast> It would be nice to use this time to discuss more long-term efforts and align a bit 12:04 < niftynei> sounds great to me 12:04 < t-bast> At least to get concept acks on the long-term things 12:05 < niftynei> just as an fyi, rusty mentioned he won't be able to join us today 12:05 < t-bast> allright no problem, let's wait for a bit more people to join? 12:06 * niftynei checks her watch disapprovingly 12:06 < bitconner> hola 12:07 < t-bast> hey conner! 12:08 < BlueMatt> heyhey 12:08 < t-bast> shall we start? Can someone chair? I feel like I've been doing it too often recently, don't want to hold the chair too much ;) 12:08 < BlueMatt> I've been here 12:08 < BlueMatt> I swear 12:08 < t-bast> Hey Matt! 12:10 <+roasbeef> #startmeeting 12:10 < lightningbot> Meeting started Mon Mar 16 19:10:11 2020 UTC. The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:10 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:10 <+roasbeef> #topic #737 (reply channel range simplification) 12:11 <+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 12:11 <+roasbeef> i see the PR has an approval from t-bast now 12:11 < t-bast> yep, all good on the eclair front 12:11 < ysangkok> #link https://github.com/lightningnetwork/lightning-rfc/pull/737 12:12 <+roasbeef> on the lnd side, we haven't yet checked so see if things sync up, I suspect they do though... 12:12 <+roasbeef> or do you know off the top wpaulino? 12:13 <+roasbeef> dunno if he's around 12:13 < t-bast> heh no worries, this can carry over if you want wpaulino to double check 12:13 <+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 12:14 < t-bast> yeah I think we can carry over, maybe have a ping for wpaulino to look at the PR? 12:14 <+roasbeef> sure 12:14 <+roasbeef> #action lnd to have peeps take a look at #737, to resolve before next meeting in PR unless major discussion 12:14 <+roasbeef> #topic #736 (BOLT 11 negative+positive tests) 12:14 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/736 12:15 < t-bast> This one needs a small rebase (should be simple though) 12:15 < t-bast> Did you have time to add these tests to lnd? Does rust-lightning have full Bolt 11 support? 12:16 < 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. 12:16 < 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 12:17 -!- arshbot [~arshbot@136.55.47.176] has quit [Ping timeout: 268 seconds] 12:17 < bitconner> t-bast yes i've double-checked the test vectors w/ lnd, should be gtg 12:17 < t-bast> bitconner: cool! just needs a rebase then 12:18 < t-bast> BlueMatt: good, probably worth pinging sebastian to add these tests and potentially fix some missing negative cases 12:18 -!- arshbot [~arshbot@136.55.47.176] has joined #lightning-dev 12:18 <+roasbeef> #action rebase #736 for merge 12:18 < t-bast> wpaulino: the change now is that it's disallowed to have next reply resuming the same block as the previous one 12:19 <+roasbeef> why? you can make a response to is the same block but consumes two messages 12:19 < 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? 12:19 <+roasbeef> feels like we covered this last time? 12:19 < t-bast> but the PR states that right now, Rusty said "a single block's channels are always in the same response" 12:19 < cdecker> Oh, looks like I got tricked by DST changes again... 12:20 < cdecker> Sorry for being late everyone 12:20 < t-bast> maybe it's still unclear in the PR? 12:20 < t-bast> Hey cdecker! :) 12:20 <+roasbeef> t-bast: yeh on avg they are, but it's possible to construct a block where that's no longer true 12:21 <+roasbeef> maybe let's continue this on taht PR so we can go thru the rest of the agenda 12:21 < t-bast> roasbeef: sounds good, let's raise that on the PR then 12:21 <+roasbeef> added by approval to #736, g2g after rebase 12:21 <+roasbeef> #topic #754 (tlv everywhere message extensions) 12:22 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/754 12:22 <+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 12:22 < t-bast> TLV everywheeeeere 12:22 <+roasbeef> hehe 12:22 -!- arshbot [~arshbot@136.55.47.176] has quit [Ping timeout: 246 seconds] 12:23 < t-bast> neat, FWIW it's implemented in eclair too and deployed on the acinq node if you want to test E2E 12:23 * BlueMatt probably wont bother implementing it until there is actually data worth reading as tlv on messages, fwiw. 12:23 <+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 12:23 < 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 12:23 < BlueMatt> as it is strictly a smaller set of accepted messages. 12:23 < t-bast> thanks roasbeef, I'll add the small comment you mentioned 12:24 < BlueMatt> dunno why its worth implementing anywhere until then, but whatever 12:24 < t-bast> BlueMatt: good idea, do you support upfront_shutdown_script? 12:24 < BlueMatt> yea, of course. 12:24 < 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 12:24 < 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) 12:24 < BlueMatt> ah, cause that can be mis-interpreted? 12:24 < cdecker> But it shouldn't be too hard to implement (and it'd simplify our message parsing for that case too) 12:25 < BlueMatt> right, well we're about to make those fields mandatory for static_remotekey anyway 12:25 -!- arshbot [~arshbot@136.55.47.176] has joined #lightning-dev 12:25 < t-bast> cdecker: good thanks 12:25 < cdecker> Overall going TLV only for the future was a big plus on our side 12:25 < BlueMatt> (and make static_remotekey mandatory) 12:25 < t-bast> BlueMatt: perfect then, should be easy to make those mandatory from the start on your side 12:25 <+roasbeef> yeh really smoothes things out from here on 12:26 <+roasbeef> ok so action is CL to implement? 12:26 < t-bast> SGTM, if CL can have a look at implementing and verifying that nothing's weird, then we should be good to go? 12:26 <+roasbeef> ok 12:27 < cdecker> We'll likely wait until we actually have new TLV fields that require the recast 12:27 < cdecker> For now the serialized format is identical 12:27 < t-bast> yeah no worries since this can be viewed as an implementation detail 12:27 < t-bast> as long as it does work 12:27 < cdecker> Exactly :+1: 12:27 < t-bast> at the byte level 12:27 <+roasbeef> yep 12:28 <+roasbeef> ok, so we're g2g on this then after an approval from lnd? 12:28 < t-bast> SGTM 12:28 <+roasbeef> #action lnd to take final look at PR for approval, g2g after taht 12:28 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 12:28 <+roasbeef> #topic #740 (avoid stuck channels) 12:28 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/740 12:29 <+roasbeef> last movement seems to be some relaxation on the new proposed guidelines 12:29 < t-bast> maybe after that one (or even now) we could move to long-term stuff? 12:29 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 12:29 <+roasbeef> last thing after this is wumbo conf t-bast 12:29 < 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 12:29 < t-bast> allright so on 740 the wording is really hard to get right 12:30 < cdecker> This is the extra reserve to counter (limited) fee spikes as well, correct? 12:30 < t-bast> this is much easier to express in code than in english :) 12:30 < t-bast> exactly 12:30 < t-bast> the current state of the PR is the following: 12:30 < joostjgr> i think the pr looks good, now that the multiplier isn't protocol anymore 12:30 < cdecker> Ok, this is nicer than the "allow to dip into the hard reserve", but still ugly AF 12:31 < t-bast> The funder should keep that extra reserve and we let some leeway on the exact factor 12:31 < 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 12:31 < 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) 12:31 <+roasbeef> also with anchors as it progresses ;) 12:31 <+roasbeef> kinda 12:32 < cdecker> Yep, +1 for anchors 12:32 < t-bast> anchor outputs does unblock that IMO 12:32 < joostjgr> anchors + drop the fee to zero indeed 12:32 < t-bast> but it's a bit more implementation work (a tiiiny bit) 12:32 <+roasbeef> ok so ppl like the simpler version of this? 12:32 < cdecker> You can't really drop the fee to zero, you always need a minimal fee to enable relay 12:32 <+roasbeef> has anyone implemented the new guidelines and tested in the wild? 12:32 < t-bast> roasbeef: CL and eclair implement it AFAIK 12:32 <+roasbeef> cdecker: yeh zero assumes p2p packaged relay widespread support 12:32 < t-bast> we've deployed it on mainnet and so far, looking good 12:32 < cdecker> We have a PR adjusting the 1.5x multiplier we had so far to 2x 12:32 < joostjgr> yes, with packaged relay 12:33 < cdecker> It seems to work fine for us 12:33 <+roasbeef> we've recently modified our logic in this area, it may very well be a super set even of what's described here 12:33 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Ping timeout: 246 seconds] 12:33 <+roasbeef> ok, will leave to joostjgr and johan to stamp their approval on the PR since they've been working in this area lately 12:33 < niftynei> by 'packaged relay' i'm assuming you mean the carve out exception? or something else? 12:33 <+roasbeef> on our end at least 12:33 <+roasbeef> niftynei: like a new p2p messages that lets you relay/request a tx package 12:34 <+roasbeef> so one can actually have near zero fees since the child pays for all/nmost of it 12:34 < 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. 12:34 < t-bast> Can you explain Matt? 12:34 < cdecker> I think m-schmoock is most familiar with these edge cases, and how well the extra reserve works, maybe he's here? 12:35 < BlueMatt> this is a separte convo we can continue after 740 12:35 <+roasbeef> #action m-schmoock and joostjgr/halseth to continue on PR for approval 12:35 < t-bast> gotcha, would be nice if you can share a somewhat detailed write-up about that afterwards 12:35 < cdecker> BlueMatt: I take it you're critical of package rely independently of LN, correct? 12:36 <+roasbeef> #topic https://github.com/lightningnetwork/lightning-rfc/pull/746 12:36 <+roasbeef> #info (wumbo conf scaling) 12:36 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/746 12:36 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 12:36 <+roasbeef> just need to look at this myself on the PR 12:36 < cdecker> NACK, not everything needs to be in the spec :-) 12:36 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has joined #lightning-dev 12:36 < 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. 12:36 < cdecker> (otherwise I don't really care) 12:37 <+roasbeef> we don't have a wumbo impl yet, need to modify our csv scaling to fit the new bounds 12:37 < cdecker> BlueMatt: ah, ok. Agreed on the minfee paying for its own relay at least 12:38 <+roasbeef> aight we'll just take this to the spec then? 12:38 < t-bast> I think 746 needs more eyes on it, we should end with a concise advisory but that stresses the main points 12:38 <+roasbeef> i think ppl just wanted mention of csv scaling as well 12:38 < BlueMatt> I dont think the rule of thumb should be there 12:38 <+roasbeef> since that's essentially a security param 12:38 < BlueMatt> I dont think its correct and I'm not sure we're gonna agree on one 12:38 < t-bast> e.g. I'm still unsure whether to_self_delay should really be scaled 12:39 < t-bast> and what factor should be used 12:39 < BlueMatt> just noting that this is lightning and we can take a long conf time is good. 12:39 <+roasbeef> it's one paragraph tops, can be high level just should mention to consider scaling those params 12:39 < t-bast> yeah the idea is to stay high-level, but make sure we understand what needs to be scaled to avoid security issues 12:39 < niftynei> i think i agree with cdecker; this is a bit too advisory for my taste wrt spec addition 12:39 <+roasbeef> #action to continue on PR, possibly add csv mention as well 12:39 < BlueMatt> the current text is not high-level, its very specific 12:40 <+roasbeef> yeh comment on teh PR with your recommendations for making it more high level 12:40 < BlueMatt> even if it pretends to not be by saying "rule of thumb" 12:40 < niftynei> it's not a specification rule tho 12:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 12:41 <+roasbeef> we have other recommendations elsewhere in the spec, this isn't too diff 12:41 < 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! 12:41 <+roasbeef> #action ppl to continue on spec that want an advisory 12:41 <+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 12:42 <+roasbeef> ok we're done with initial PR/issue stuff 12:42 <+roasbeef> moving onto the next section 12:42 < niftynei> this feels like a great medium post topic :P 12:42 <+roasbeef> #topic anchor outputs 12:42 < joostjgr> i can give the update 12:42 <+roasbeef> lnd has implemented everything, planning to include behing flag in our next major version 12:42 * roasbeef gives joostjgr the floor 12:42 < joostjgr> hehe ok thanks 12:43 < joostjgr> indeed, implemented the new format, channels are produced with anchors 12:43 < t-bast> nice, well done! 12:43 < joostjgr> pr that is close to merge is the one that actually allows sweeping and cpfp'ing the anchors 12:43 < joostjgr> we have a cli command that allows bumping the close tx 12:43 < joostjgr> pr is updated with details that were left out previously (weights etc) 12:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 12:44 -!- vasild_ is now known as vasild 12:44 < joostjgr> open discussion is still one vs two anchors, initiated by niftinei 12:44 < joostjgr> the anchor commitment format is more expensive than our current format, that is clear 12:44 < joostjgr> but one vs two anchors is more subtle. it is a trade-off between cost and decoupling between remote output and remote anchor 12:45 < 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 12:45 < BlueMatt> why is decoupling required? (or even helpful?) 12:45 <+roasbeef> also re the cost: the extra sats committed to the anchor starts to get dwarfed by fee rate scaling above the min 12:46 < joostjgr> so that we can later add symmetric csv delay. the same delay for to_local and to_remote 12:46 <+roasbeef> BlueMatt: helpful from an implementation perspective, the logic is completely distinct 12:46 < niftynei> do you have stats on when the feerate becomes dwarfed? 12:46 <+roasbeef> the logic for remote+local commitment is the same 12:46 < BlueMatt> roasbeef: hmmm, dont think it'll be any more or less complicated on our end 12:46 <+roasbeef> niftynei: not atm, but it's 38 bytes and 660 sats, can python up some graph 12:46 < BlueMatt> I think it kinda sucks to add an extra output just cause it simplifies implementation a tad 12:47 <+roasbeef> BlueMatt: don't know till you try to implement it ;) we found some surprises in our implementation which caused shifts in the spec 12:47 < BlueMatt> especially when the other funds are only spendable after 1 conf csv anyway 12:47 < joostjgr> 330 sats will be spend anyway. that is with a single anchor. double anchor is +330 sats 12:47 < niftynei> that extra output is expensive imo 12:47 < 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 :) 12:47 <+roasbeef> it's 38 bytes objectively for each, "expsensive" comes as you scale p the fee rate 12:47 <+roasbeef> up* 12:48 <+roasbeef> err more like 43 12:48 < niftynei> my very rough calculations showed that two anchors make a commitment tx 5x more expensive (at a very low feerate) 12:49 <+roasbeef> this optimizes for the case where a very low fee rate could possibly mean loss of funds if you can't bump 12:49 < 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 12:49 <+roasbeef> 5x in that case is still just a few hundred satoshis 12:49 < niftynei> the majority of that extra cost is from the output value of the anchor outputs 12:49 < joostjgr> the discussion one vs two anchors is more interestnig imo 12:49 < niftynei> ok so let's talk about why two anchors is better than one 12:50 <+roasbeef> you still need two anchors in some cases 12:50 <+roasbeef> where the remote party has an incoming htlc, but no settled funds 12:50 <+roasbeef> they need one to anchor down 12:50 < BlueMatt> but any amount that you could set the anchor to could also be set as minimum push_msat 12:50 < 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. 12:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 12:50 < BlueMatt> its also kinda shitty to the bitcoin network to add extra outputs just case 12:51 <+roasbeef> they can be swept pretty easily and easily recognized also 12:51 < BlueMatt> right, but if feerates go up, sweeping will not be economical 12:51 <+roasbeef> wouldn't categorize it as "just cause" 12:51 < BlueMatt> and swept or not, its still extra outputs + inputs that need to process 12:51 <+roasbeef> it can be it bundled with others 12:52 <+roasbeef> yeh in our code we handle it, but distinct from the lifetime of the channel mostly 12:52 < BlueMatt> yes, still an extra output + input 12:52 < BlueMatt> roasbeef: can you be more concrete as to why its really helpful for y'all? 12:52 < 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. 12:52 <+roasbeef> which still needs to be there in the case I described above 12:53 < 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 12:53 < BlueMatt> which seems like a future discussion 12:53 <+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 12:53 <+roasbeef> two anchors also decoupled things from the script/shape of the settled commitment outputs as well 12:54 <+roasbeef> two always* 12:54 < BlueMatt> hmmmm, that doesn't tell me much? I mean its not a "special case" to use a to_remote to cpfp, no? 12:54 <+roasbeef> special case as in somtimes having it there and sometimes not having it there 12:55 <+roasbeef> the logic is then also asymmetric, sometimes you use the anchor vs sometimes using your own output 12:55 < BlueMatt> right, you already have a ton of code for local-vs-remote broadcasts? 12:55 < niftynei> just for posterity's sake, here's my comments on feerates/extra cost https://github.com/lightningnetwork/lightning-rfc/pull/688#issuecomment-591026162 12:55 < BlueMatt> the only difference in logic is exact signing format 12:55 <+roasbeef> yes due to the asymmetric nature of the base commitments, but symmetry in this case simplifies things 12:55 < niftynei> simplifies things for .. the developers? 12:56 <+roasbeef> BlueMatt: there's more than that, sweeping is distinct as well, how you sweep the fee rate, the urgency, etc 12:56 < BlueMatt> hmmm, do others have any input here? It doesn't simplify stuff much for us. 12:56 < cdecker> Neither for us if I am seeing this correctly 12:56 < BlueMatt> roasbeef: right, but in this case there is no sweeping, which is strictly better anyway :) 12:56 <+roasbeef> may be hard to fully grasp what we're trying to communicate here without actually implementing the entire thing 12:56 < BlueMatt> roasbeef: no, I get what you're saying 12:57 <+roasbeef> niftynei: simpler code. less bugs, less corner cases, decoupled to make room for future changes in to_remote outputs 12:57 < 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 12:58 < BlueMatt> I, however, dont think its worth the social cost on the chain + the fee cost in outputs 12:58 <+roasbeef> something something devil details 12:58 < joostjgr> how do people feel about 'one anchor' vs 'two anchors + sym csv' then? 12:58 < 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 12:58 <+roasbeef> BlueMatt: do you see the case that you need to have two outputs at times in certain cases? 12:58 <+roasbeef> niftynei: utxo foot print is also inherent in having the anchor or not, we expect ppl to sweep them 12:59 < BlueMatt> roasbeef: what do you mean two outputs? you usually have many more outputs than that due to htlcs 12:59 <+roasbeef> if you channel is tiny, then you're gonn ahave issues with high fee rates 12:59 < BlueMatt> roasbeef: its still utxo footprint cause sweeps cost $ 12:59 <+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 12:59 < BlueMatt> or, at least, transaction footprint 13:00 < 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 13: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 13:01 < BlueMatt> which is a big social good 13:02 <+roasbeef> i g2g 13:02 < BlueMatt> ok, we'll continue this another time! 13:02 < BlueMatt> maybe it makes sense to schedule a meeting to just get this over the line 13: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) 13:03 < 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. 13:03 < 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 13:03 < BlueMatt> joostjgr: yea, thats a conversation I cant add as much to, but is worth discussing. 13:03 <+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 13:03 < 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 13:04 < 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 13:04 < BlueMatt> t-bast: right. in theory we can also punt on that and add another output at that time 13:05 < joostjgr> or do 2 anchors + sym csv right now. just resolve our minor difference in preference around negotiating the actual value 13:05 < joostjgr> commitment formats are definitely not free to add 13:05 < 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 13:05 <+roasbeef> also I wouldn't underestimate the amount of work to impl (final parting thought lol) 13:06 < BlueMatt> roasbeef: agreed. we can schedule another meeting to get it over the line imo 13:06 <+roasbeef> i'm gonna end it now, but feel free to continue to discuss, will read the scrollback 13:06 <+roasbeef> #endmeeting 13:06 < lightningbot> Meeting ended Mon Mar 16 20:06:11 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:06 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-03-16-19.10.html 13:06 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-03-16-19.10.txt 13:06 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-03-16-19.10.log.html 13:06 < t-bast> a dedicated meeting would be useful IMO 13:06 < t-bast> and I think it would be helpful to have a written document, not in spec format, this highlights the design, pain points where there's been a lot of back and forth, et 13:06 < t-bast> *etc 13:07 < t-bast> something like the "proposal" format cdecker is testing with rendezvous 13:07 < joostjgr> right, so to be continued. we are planning to roll out the format as we have it currently (2 anchors) with an experimental feature bit in lnd 0.10 btw. it is experimental, so we can still deprecate it in the next major 13:07 < t-bast> that would be really helpful to make the discussion progress on the concept/high level, it's hard to do that on the spec PR 13:07 <+roasbeef> t-bast: idk how much help that would be given we all have every diff codebases 13:08 < t-bast> roasbeef: the goal is to have it described in a "design doc" form, where the intent between each technical decision is easier to express and comment on than spec format 13:09 < t-bast> I feel like we're going over the same points over and over again, maybe having that summary document will help us make progress faster 13:09 < joostjgr> i think we should stick to the spec. i don't think it is bad to elaborate on the rationale a bit more in there 13:09 < BlueMatt> t-bast: nah, we've agreed on static values, so thats progress :p 13:09 < t-bast> hehe 13:09 < t-bast> ok the majority has spoken, let's at least do a dedicated meeting then! 13:09 < niftynei> " simpler code. less bugs, less corner cases, decoupled to make room for future changes in to_remote outputs" these all seem like things that would be worth writing a design doc about imo 13:11 < cdecker> Sorry, notebook froze. 13:11 * BlueMatt -> back to work. enjoy quarantine, friends in sf 13:11 <+roasbeef> we're really just dragging this on, for something that's pretty critical to security, the spec has dragged on for a while now, happy to get more feedback but could've come at an earlier time 13:12 < niftynei> til next timeeeee! thanks for chairing roasbeef 13:12 < BlueMatt> roasbeef: I've been saying that for six+ months, and suddenly you care cause fees have gone up. We should get this right, not rush it just cause fees suddenly went up and something we've been dragging actually matters now. 13:13 < cdecker> I've been pushing for a proposal format for a while, but got no responses. I think it makes sense to have a design doc that describes the entire proposed change so we can discuss at a high level, and not have to stitch things back together from the changes that are going to be applied to the living spec 13:13 <+roasbeef> BlueMatt: yeh, we think it's important given we're the only ones that've implemented the entire thing 13:14 <+roasbeef> if ppl don't care about symmetric csv at all in the future, then that's a critical design saddle 13:14 < t-bast> I agree that it's an important topic and we've had troubles making progress; I believe that cdecker's proposal format would have helped discuss the higher level design more efficiently (and isn't too late to add) while keeping a summary of discussions/reasons between each trade-off/etc 13:14 < BlueMatt> personally, I dont really, but others can chime in and I'm happy to be overruled there 13:16 < t-bast> It's true that the fact we haven't all been implementing it at the same time makes it harder to review, and we should probably put more effort into it, but most of the teams are a lot smaller than lightning labs so it's hard to do everything at once ;) 13:17 <+roasbeef> hehe primarily 2 ppl have been working on this on our end (johan+joost) 13:17 < t-bast> Thanks for chairing roasbeef, I think we still did make progress tonight and we should continue with a follow-up meeting 13:17 * BlueMatt admits we've gotten mired a bit in "way more resources all of a sudden" slowing us down, but its starting to pick back up so we should be on it soonish 13:17 < t-bast> Ideally in some higher bandwidth tool than IRC 13:17 < BlueMatt> that plus refactoring our on-chain handling to be wayyyy simpler 13:18 < t-bast> Can we borrown johan and joost to implement in eclair? 13:18 < t-bast> I'm sure at least johan knows the JVM given his previous jobs :D 13:18 < joostjgr> Why don't you just fork LND? 13:18 < t-bast> lolz 13:19 < BlueMatt> oof lol 13:19 < t-bast> allright gotta go too, stay safe everyone! 13:20 < joostjgr> See you all! 13:20 -!- t-bast [~t-bast@2a01:e34:ec2c:260:c34:dd47:ddf3:8590] has quit [Quit: Leaving] 13:20 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving] 13:22 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving] 14:04 -!- captjakk [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [] 14:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:16 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:22 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:25 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 14:25 -!- __gotcha1 is now known as __gotcha 14:27 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:30 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 14:31 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:32 -!- __gotcha1 [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 14:32 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 14:35 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 14:35 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 14:37 -!- __gotcha1 [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 14:50 -!- iangregsondev [~textual@182.red-213-97-71.staticip.rima-tde.net] has joined #lightning-dev 14:50 -!- iangregsondev [~textual@182.red-213-97-71.staticip.rima-tde.net] has quit [Client Quit] 14:53 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 15:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:40 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 16:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 17:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:34 -!- tryphe_ is now known as tryphe 17:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 17:43 -!- marcoagner [~user@2001:8a0:6a5f:a900:6d3e:1158:b50:97b6] has quit [Ping timeout: 272 seconds] 18:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 19:09 -!- shibshop [~shop@204.232.243.35.bc.googleusercontent.com] has left #lightning-dev [] 19:09 -!- captjakk_ [~captjakk@75-166-188-3.hlrn.qwest.net] has quit [Remote host closed the connection] 19:32 -!- DeanWeen is now known as DeanGuss 20:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 20:32 -!- treehug88 [~textual@pool-71-105-170-196.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 20:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 21:11 -!- RonNa [~quassel@60-251-129-61.HINET-IP.hinet.net] has quit [Quit: No Ping reply in 180 seconds.] 21:12 -!- RonNa [~quassel@60-251-129-61.HINET-IP.hinet.net] has joined #lightning-dev 21:34 -!- zerogue [~irc@138.197.175.130] has quit [Quit: Goodbye Cruel World] 21:53 -!- zerogue [~irc@138.197.175.130] has joined #lightning-dev 21:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 21:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:11 -!- zerogue [~irc@138.197.175.130] has quit [Quit: Goodbye Cruel World] 22:12 -!- zerogue [~irc@138.197.175.130] has joined #lightning-dev 22:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 23:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 23:18 -!- rdymac [uid31665@gateway/web/irccloud.com/x-iqsiapzcldnvnnwv] has quit [Quit: Connection closed for inactivity] 23:45 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] --- Log closed Tue Mar 17 00:00:24 2020