--- Log opened Mon Jan 04 00:00:05 2021 00:39 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 00:40 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 00:44 -!- da39a3ee5e6b4b0d [~da39a3ee5@49.228.238.173] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:45 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.] 00:46 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 00:46 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 00:47 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds] 00:48 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 00:49 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 00:49 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Quit: Quit] 00:49 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #lightning-dev 00:50 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined #lightning-dev 01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 02:03 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev 02:07 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds] 02:08 -!- belcher_ is now known as belcher 02:18 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds] 02:22 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 02:31 -!- laptop [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 02:33 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:143:71ff:303a:4980:438c] has joined #lightning-dev 02:36 -!- CCR5-D32 [~CCR5@unaffiliated/ccr5-d32] has joined #lightning-dev 03:00 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 03:36 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:143:71ff:303a:4980:438c] has quit [Read error: Connection reset by peer] 03:37 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.] 03:39 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 04:12 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 04:31 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds] 04:43 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 04:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.] 05:15 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 05:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 05:19 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 05:19 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 05:19 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:25 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 05:25 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 05:29 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 05:31 -!- __gotcha1 [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds] 06:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:22 -!- CCR5-D32 [~CCR5@unaffiliated/ccr5-d32] has quit [Quit: CCR5-D32] 06:32 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 06:41 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 06:41 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 06:45 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-bamhammylzdpvfhb] has quit [Ping timeout: 260 seconds] 06:46 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Ping timeout: 260 seconds] 06:47 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-fqmqdesvfbargkli] has joined #lightning-dev 06:59 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev 07:02 -!- EdgarsB[m] [ebmatrixbi@gateway/shell/matrix.org/x-dqwmwpznqxkwbbsl] has left #lightning-dev [] 07:18 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 07:28 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in] 07:29 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev 07:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 07:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Client Quit] 07:37 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 07:37 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Client Quit] 07:38 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 07:50 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:15 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 08:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 08:48 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 08:49 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:53 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 08:54 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 08:59 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 09:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:04 -!- kexkey [~kexkey@static-198-54-132-155.cust.tzulo.com] has joined #lightning-dev 09:17 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in] 09:20 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev 09:23 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds] 09:25 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in] 09:25 -!- alko89 [~alko89@unaffiliated/alko89] has joined #lightning-dev 09:37 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Remote host closed the connection] 09:38 -!- laptop [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 09:39 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 09:44 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 09:51 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 09:57 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Quit: The Lounge - https://thelounge.chat] 10:01 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:01 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Remote host closed the connection] 10:05 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:05 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Remote host closed the connection] 10:06 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #lightning-dev 10:08 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:08 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Client Quit] 10:09 -!- niftynei_ is now known as niftynei 10:09 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:10 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Client Quit] 10:11 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:11 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Remote host closed the connection] 10:12 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:12 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Remote host closed the connection] 10:16 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 10:50 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev 10:54 -!- mably [uid99779@gateway/web/irccloud.com/x-hfgkgvehibzegecx] has joined #lightning-dev 10:58 -!- bmancini55 [26460b74@38.70.11.116] has joined #lightning-dev 11:01 < cdecker> Good evening 11:02 < niftynei> hello hello 11:02 < t-bast> Hey guys! 11:02 < ariard> happy nye folks :) 11:03 < jkczyz> hey 11:03 < cdecker> Happy new spec season :-) 11:03 < ariard> what the color of the new spec season ? 11:04 * cdecker is hoping for magenta 11:04 < t-bast> It's going to be bright 11:05 < t-bast> Suspense, is the meeting bot back in 2021? 11:06 < t-bast> As usual, tentative agenda is pinned on the repo: https://github.com/lightningnetwork/lightning-rfc/issues/830 11:06 < lndbot> hi all 11:06 < t-bast> hey johanth 11:06 < t-bast> Shall we start? 11:07 < ariard> yep 11:07 < t-bast> #startmeeting 11:07 < t-bast> It's not back :) 11:07 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/830 11:08 < t-bast> #topic additional transaction test vectors 11:08 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/539 11:08 < t-bast> Did someone have time to test these new vectors? 11:09 < jkczyz> my attempt ran into a hurdle in the RL uses vectors produced with static remote key 11:09 < jkczyz> but getting there 11:09 < niftynei> afaik no one from clightning has; rusty has been out for the holiday 11:09 < BlueMatt> why are we adding tests that *dont* use static remote key 11:10 < BlueMatt> given IIRC most implementations are moving towards requiring it/already have 11:10 < jkczyz> BlueMatt: Good question. I think it predates https://github.com/lightningnetwork/lightning-rfc/pull/758 11:11 < t-bast> Exactly, it predates static remote key, but I can also duplicate them for the static remote key case if you want (I still think it may be useful to keep the existing ones around) 11:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:11 <+roasbeef> well it's part of the spec, so might as well add it 11:11 < BlueMatt> the old ones will always be in git, if people arent supporting non-static-remotekey, we should just drop it from the spec, including the test vectors. 11:11 <+roasbeef> for eaxmple afaik, eclair doesn't actually spport static key? 11:11 < t-bast> roasbeef: only eclair-mobile 11:12 < t-bast> but I think it's too early to remove this entirely from the spec TBH 11:12 < jkczyz> t-bast: I found Eclair's test vectors so have been working off them 11:12 < BlueMatt> not worth fighting over it, but, yes, it would be nice to have a version with static-remotekey 11:13 < t-bast> jkczyz: great 11:13 <+roasbeef> ah gotcha, but y'all plan on adding it for anchors right t-bast ? 11:13 < cdecker> Heya rusty :-) 11:13 < rusty> Hi! 11:13 < t-bast> roasbeef: yes, but we don't know when anchor will make it to eclair-mobile though... 11:13 * t-bast waves at rusty 11:13 <+roasbeef> intresting, we had to implement a work around for eclair-mobile, since we've flipped out static key bit to required 11:14 < t-bast> #action t-bast to also add these test vector for the static remote key case 11:14 <+roasbeef> also made us reailize, that we should advertise channel level feature bits differntly, since rn we're forced to _downgrade_ in order to maintain the connection if a node has a legacy channel open t-bast 11:14 <+roasbeef> which ofc isn't ideal, and shows how we need to make channel negotiation explicit to avoid inadvertent downgrades which could cause security issues in the fturue 11:14 < t-bast> roasbeef: yes I see what you mean here, I've thought about this too 11:15 < rusty> I'm really surprised that static remotekey isn't universal. Yech. 11:16 <+roasbeef> lnd 0.12 won't make channels that don't use it, which caused us to discover the way we implemented it would fragment connections 11:16 < t-bast> in fact we'd like to relax dropping the connection on unsupported mandatory channel features when previous channels don't have this feature set, or something like it 11:16 < cdecker> Yep, can't wait to strip that code (and special cases) out of c-lightning 11:17 <+roasbeef> so you need to advertise the "lowest" existing chanenl feature bit, tho this isn't a problem for CL since they don't suport multiple chans to a peer, in that case they'd still need to advertise that old bit htho 11:18 < rusty> Technically your implementation has to advertize it. Ofc channels may predate it. 11:19 < t-bast> In that case it's quite painful: an lnd node wants to require static_remote_key, but has channels with an eclair-mobile that doesn't support the feature at all 11:19 < t-bast> We're quite cornered because the spec makes this case impossible (we'd disconnect immediately) 11:20 <+roasbeef> rusty: so the issue was we want to make the bit required, but they don't understand the bit (have legacy v1 channels), so we need extra logic to downgrade that bit for them 11:20 <+roasbeef> yeh 11:20 <+roasbeef> so we want to _maintain_ the connection, but just not allow new channels to be created ideally in that context 11:20 < rusty> Yeah, you can't make it required if a peer doesn't support it. Y'know, unless you never want to talk to them again. 11:20 < BlueMatt> if you want to require it, you need to force-close the channel anyway. if you just dont want to create new channels without it, then you can just reject channels, not announcing the bit as required? 11:21 <+roasbeef> mhmm, we didn't anticipate needing that dynamic implicit negotiation logic initially rusty 11:21 < BlueMatt> you can always reject a channel for any reason you want. 11:21 < rusty> Yeah, I assumed everyone would just support it before we force it on. 11:21 <+roasbeef> auto force closing a channel for users isn't a very good idea 11:21 < BlueMatt> sure, but you have to do that either way if you dont support the code to run such a channel 11:21 < BlueMatt> in any other case, you can set the bit optional and reject all new channels to such peers 11:22 < BlueMatt> sucks for nodes seeking out to connect to you based on your lack of unknown required bits, but shouldnt be too painful for them, an immediate error message and maybe disconnect should make them go away. 11:22 < rusty> Well, why make it compulsory? Seems premature (unf) 11:22 <+roasbeef> rusty: make static key cumpulsory? it's waaay safer 11:22 <+roasbeef> bout time 11:23 <+roasbeef> we're also making the mpp payload reqwuired as well 11:23 < rusty> Yeah, but we need Eclair mobile to upgrade first. 11:23 < BlueMatt> right, I'm not suggesting any specific point, only noting that its not really an issue with the way the bits are set afaiu 11:24 < t-bast> I agree with BlueMatt, having a small logic to set the bit as only optional when connecting to a peer you have old channels with, and simply rejecting new channels should work fine 11:24 <+roasbeef> yeh that's what we do 11:24 <+roasbeef> just pointing out that it isn't explicitly mentioned in the spec sincew e don't have a specific section for how to handle channel upgrades 11:25 < t-bast> true, it's an edge case that's a bit painful to handle :/ 11:25 <+roasbeef> do y'all aready have logic for that? we had to add it as a special case 11:25 <+roasbeef> live in lnd 0.12rc3 11:26 < t-bast> we don't have that in eclair, we should add it - we do have the ability to configure feature bit overrides per-peer, so node operators can work around this manually though 11:27 <+roasbeef> ok cool, what we have downgrades properly and has been tested with users running eclair-mobile that have a legcay channel w/ an lnd node 11:27 < niftynei> should i know what a channel upgrade is? 11:28 < t-bast> niftynei: this refers to roasbeef's ML proposal a few months back to upgrade channels without needing a close 11:28 < t-bast> for example going from legacy commitments to anchor outputs by re-signing new commit txs after pausing the channel 11:28 < niftynei> right. thank you. 11:28 <+roasbeef> or even what can happen rn: you have old channel with node, and want to open new channel with node, how do you do that? 11:28 <+roasbeef> rn it's implicit, but my goal is to make it explicit 11:29 <+roasbeef> some of the issues rn arise since things are implicit, and it being implicit means a peer can make you downgrade essentially based on its feature bits 11:29 <+roasbeef> short path to explicit, is adding a new tlv to open/accpt that's just chan_type, and we back value everything to make it work properly 11:29 < t-bast> let's move on to the next topic, I'll add static remote key test vector to the PR before next time 11:29 <+roasbeef> woudl also make testing protocl stuff easier as well, rn we use build flags to force old behavior 11:30 <+roasbeef> +1 11:30 < t-bast> #topic sync complete 11:30 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/826 11:31 < t-bast> I haven't had time to implement it, but it should be quite straight-forward. Before I go into that direction, are all on the same page that implementations are willing to at least do the first bullet point in a next release (correctly set the `complete` boolean flag)? 11:31 -!- Luc21 [4770bb1e@pool-71-112-187-30.pitbpa.fios.verizon.net] has joined #lightning-dev 11:31 <+roasbeef> lnd already sets it ;) 11:31 <+roasbeef> since it never even did anything with the "proper" interpretation of the spec, and we needed to leave it around for our older nodes 11:31 < t-bast> great, that's one down ;) 11:31 < rusty> t-bast: yeah. We don't currently use the flag, though we were going to set it appropriately (particularly for the case where we're only connected with one node). 11:32 < t-bast> allright, then I'll start implementing it re-using the `full_information` field 11:32 < rusty> But IIRC that gave lnd issues, so we always set it to True right now. 11:32 < t-bast> you mean in each reply or only the last one? 11:33 < rusty> t-bast: we set it always. But we won't notice if someone doesn't. 11:33 < rusty> So ack from me. 11:33 < t-bast> ok, roasbeef do you know why setting it to `false` caused issues with lnd? 11:36 < rusty> (I could be misremembering, ofc: pretty sure modern lnd will be fine) 11:36 < t-bast> #action t-bast to implement in eclair for real 11:37 < t-bast> allright, let's start with implementing the part where we correctly set this to `sync_complete` and see where that takes us when doing cross-impl tests 11:37 < t-bast> #topic anchor outputs 0-fee feature bits 11:37 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/828 11:38 < t-bast> Looks like this has ACKs all over the place, shall we just merge it and then we can wait for cross-compatibility tests for #824? 11:38 < lndbot> I say yes :) 11:40 < rusty> Ack (embarrassingly, I've gotten logged out of GH and my phone required for 2fa is sitting next to my sleeping wife, so I can't log back in right now!) 11:40 < t-bast> xD 11:41 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 11:41 < lnd-bot> [lightning-rfc] t-bast merged pull request #828: bolt-09: reserve feature bits for option_anchors_zero_fee_htlc_tx (master...zero-fee-htlc-feature-bits) https://github.com/lightningnetwork/lightning-rfc/pull/828 11:41 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 11:41 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev 11:41 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/d0c83854de7e...a00418f5f9f1 11:41 < lnd-bot> lightning-rfc/master a00418f Johan T. Halseth: bolt-09: reserve feature bits for option_anchors_zero_fee_htlc_tx (#828) 11:41 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev [] 11:41 < t-bast> Done! 11:41 < t-bast> #topic advertize compression algorithms in init 11:41 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/825 11:42 < t-bast> I've reworked the approach since last spec meeting for this PR, I now suggest using a new `init` tlv field to advertize what compression algorithms we support 11:42 < t-bast> Then wherever compression may be used this will apply (currently only for gossip queries) 11:42 <+roasbeef> t-bast: false only affects older versions, as they think there's more to send, the latest version of lnd (since a few ago) won't even look at the field and only uses the block markers 11:43 < t-bast> roasbeef: great, so we should be fine making progress on this 11:43 <+roasbeef> t-bast: bit behind on this but why this route over feature bits? 11:43 <+roasbeef> re tlv in init 11:43 < rusty> Why the feature bit? Non-existence of the field should provide the same, no? 11:43 <+roasbeef> also wasn't there some older proposal to use this for something else by Z? 11:44 <+roasbeef> rusty: don't follow the second part 11:44 < t-bast> roasbeef: the issue with the feature bit route is that if we want to support multiple compression algorithms, we'd need one feature bit per algorithm? And since old nodes that do support zlib don't set this feature bit, it won't help with non upgraded nodes 11:44 <+roasbeef> oh yeh this already exists lol 11:45 < t-bast> rusty: I added it so that you can see it in node_announcement 11:45 < rusty> roasbeef: if the field doesn't exist, you can behave as now. If it does, you know (1) they understand the feature, and (2) don't do zlib if not present in it. 11:45 < rusty> t-bast: ah, right. 11:45 < t-bast> and choose to connect only to those peers that you know will actively tell you what they support 11:45 < t-bast> otherwise there's still a hole for the case where you don't want to support any compression (what RL wants to do) 11:46 <+roasbeef> ahh I see 11:46 <+roasbeef> i'd also forgotten that we'd already added init tlvs as well 11:46 < t-bast> they could try connecting and then fail if the tlv isn't set, but that's wasteful 11:49 < t-bast> also there's a nit for the case where no compression is supported: the absence of the field, a 0-length byte array or any array with all 0s have the same meaning 11:49 < t-bast> I don't know if we should explicitly state what should be set in that case (I currently chose having the tlv field with a 0-length array) 11:50 < t-bast> Or if we should allow all 11:51 < rusty> t-bast: I believe it's logically consistent to say "missing === empty". 11:51 <+roasbeef> rusty: +1 11:52 <+roasbeef> one of those empty byte array vs nil array type tings 11:52 < BlueMatt> you could mention that it should be minimally-encoded, which would imply missing if no compression algs are supported, but not sure it matters 11:54 < t-bast> Ok, I'll re-work that part a bit then, I'll relax the requirements and add `SHOULD` recommandations 11:54 <+roasbeef> g2g early, something came up, will read scrollback (also last week's) 11:54 < t-bast> #action t-bast to re-work the requirements for no compression case 11:54 * t-bast waves at roasbeef 11:55 < t-bast> Since I'm chair, let's shill a bit my own long-term thing :) 11:55 < t-bast> I have opened a trampoline 2021 edition PR 11:55 < t-bast> a bit simpler and more flexible than the previous one, mostly since electrum has implemented it and wanted to interoperate 11:55 < t-bast> #topic Trampoline 2021 edition 11:55 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/829 11:55 < cdecker> Nice, I was worried that we wouldn't get to discuss it so I added my thoughts as a comment before 11:56 < t-bast> I see that cdecker already added interesting comments :) 11:56 < t-bast> Regarding your first point (size of the total route), we could impose a maximum size on the trampoline onion; however I'm not sure it can be used as a very effective multiplier, since the attacker doesn't control what happens between trampoline nodes 11:57 < t-bast> And if we make progress on fighting spam, do we even need to address this issue? 11:57 < cdecker> t-bast: that's why I'm using the network diameter, there is no shorter path between those nodes than through the entire network 11:57 < t-bast> I like the flexibility of the size, in case we need to add more tlvs in the onion for route blinding / rendezvous types of things 11:58 < cdecker> Agreed, but I think a simple argument as to what a trampoline hop's size looks like and giving an upper bound is already enough 11:58 < t-bast> cdecker: there is no path *that you know of* but there may be unannounced channels 11:58 -!- Luc21 [4770bb1e@pool-71-112-187-30.pitbpa.fios.verizon.net] has quit [Remote host closed the connection] 11:58 < BlueMatt> I admittedly havent gotten to look yet, but the second bullet seems scary - is the intent here that users can send to a node with a next-hop node that supports trampoline and no other information by letting the recipient specify middle nodes? I mean in many cases you likely cant avoid letting users do that, but implementations actively chosing to do that seems like we've given up on privacy. 11:59 < BlueMatt> bits being in gossip was nice cause then at least you could in the future ask your trampoline-supporting next-hop to give you gossip info but only the top N nodes it knows about that support trampoline 11:59 < cdecker> Yeah, I'm struggling with the recipient-defined trampoline nodes tbh 11:59 < BlueMatt> and you could ask around for more copies of the same and then at least build routes with a few trampoline hops 11:59 < t-bast> BlueMatt: I don't follow why: the reason here is that we let the recipient choose how you'd get to them, it seems good for privacy rather than bad? 12:00 < cdecker> That's assuming route blinding though, isn't it? 12:00 < t-bast> I removed the gossip part because I think 1) it's the one that will take the longest to agree one and 2) it can be added in a second phase 12:00 < t-bast> cdecker: not necessarily, it's exactly like the current routing hints 12:01 < cdecker> Which leak the existence of private channels to nodes that would otherwise not learn about them 12:01 < t-bast> yes and here with trampoline it's better, because you only leak that you're close to a node_id (but without specifying exactly how close) 12:02 < t-bast> not even necessarily close, but rather that you're reachable from that node 12:02 < cdecker> I'd much rather stick with route hints, and just pass them along to the last trampoline. We're not leaking more info that way, and we don't assume the trampoline is either the destination or knows how to get there 12:02 < BlueMatt> t-bast: I always assumed the only reasonable way to do trampoline was similar to tor onions - specify at least two-ish trampoline hops between you and some middle node, then take a few hops from the recipient's hints 12:02 < t-bast> BlueMatt: you can still add more trampoline nodes before the recipient's (or choose to ignore his recommendations) 12:02 < cdecker> BlueMatt: that'd make only sense with rendez-vous routing imho 12:03 < BlueMatt> t-bast: only if trampoline info is in gossip info, though 12:03 < t-bast> cdecker: if we pass the route hints to the trampoline node, we're doxxing the recipient 12:03 < BlueMatt> cdecker: right, eventually we'd need that as well. 12:03 < t-bast> cdecker: because the trampoline node know clearly knows that the next node is the final recipient 12:04 < cdecker> Not if you use decoy route hints xD 12:04 < t-bast> BlueMatt: it will be advertized in `node_announcement`, nodes will be able to set the trampoline feature bit 12:04 < cdecker> Which is what I'm doing here https://github.com/lightningd/plugins/pull/193 btw :-) 12:04 < t-bast> BlueMatt: so you still have a way of finding trampoline nodes yourself 12:05 < t-bast> cdecker: true :) 12:05 < BlueMatt> t-bast: ah, ok, i didnt understand what "any new gossip mechanism" meant, then 12:06 < t-bast> BlueMatt: it's because I clearly put too many things in my first trampoline PRs, and focused on many gossip optimizations that can be done in a second phase 12:06 < BlueMatt> ok, fair 12:06 < t-bast> BlueMatt: I removed them from that one to focus on the core of the proposal (which in itself is enough and quite flexible, allows choosing your perf/privacy trade-off) 12:07 < BlueMatt> right. well gotta get nodes out there that support trampoline before we can get any privacy for trampoline users :) 12:07 < t-bast> exactly! 12:07 < rusty> (BTW, tangentially related: I dropped my idea of using x-only pubkeys for onion messages, since it means we don't get to reuse the current onion code) 12:07 < t-bast> and implementing the set of functionality in this PR is not too hard, should be a 3-5 dev days I believe, which would get the ball rolling 12:08 < t-bast> rusty: good to know, I didn't have time to try them so I can cross that off my todo list xD 12:08 < t-bast> cdecker: I'll think a bit more about the routing hints, it may work better than I thought 12:08 < t-bast> cdecker: it takes a lot of space in the onion but well, that happens 12:09 < cdecker> Agreed that we should get the trampoline base functionality out, but the trampoline hints need some work 12:09 < cdecker> That being said, my main concern is the size impact to the invoices, not really privacy (there is none imho) 12:10 < t-bast> I'll work on those and see where it takes me, meanwhile don't hesitate to look at the rest of the PR and let me know if something feels off! 12:10 < t-bast> #action t-bast to re-work trampoline routing hints 12:10 < cdecker> Personally I've been thinking about unannounced channels much more as an optimization (lowering the gossip traffic on the network) rather than a privacy enhancement (which is a shaky argument in any case with today's routing) 12:11 < t-bast> cdecker: we're doing this as well already: no need to advertize 10 channels to the same peer for example, a portion of them can be unannounced 12:12 < t-bast> and having unannoucned "shortcut" channels can also be useful, just to throw off graph analysis 12:12 < cdecker> Hehe, we optimize by only ever having one channel xD 12:12 < t-bast> xD 12:12 < t-bast> Looks like we're already over 1 hour, do you want to discuss another topic? 12:13 < cdecker> t-bast: shortcuts that don't match exising channels can't be used due to the onion construction, unless you retroactively tear down an HTLC once you realize that two of your nodes are part of the payment. 12:14 < t-bast> cdecker: they're useful with trampoline, but you're right that they're not usable for normal channel-relay 12:14 < cdecker> This has been (wrongfully) called wormhole attack, however I agree that it's hardly an attack if the end-to-end security is maintained, we're just more efficient, involving fewer channels, and getting a bit more fees for it xD 12:15 < cdecker> Anyway, I better be off soon :-) 12:16 < t-bast> Let's end now then, thanks everyone for your time! 12:16 < cdecker> Thanks t-bast for chairing and setting up the agenda ^^ 12:16 < t-bast> #endmeeting 12:17 < BlueMatt> thanks t-bast 12:17 * jkczyz waves 12:17 < t-bast> Have a good 2021 start, lot of development ahead of us ;) 12:18 -!- t-bast [~t-bast@5.50.145.86] has quit [Quit: Leaving] 12:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 12:28 -!- bmancini55 [26460b74@38.70.11.116] has left #lightning-dev [] 12:47 <+roasbeef> btw was the bot never resurrected? the meeting one 12:47 <+roasbeef> oh also I think we need to switch over the rfc repo CI from travis.org to travis.com 12:48 <+roasbeef> as the .org variant should be shut down now 13:07 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer] 13:08 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev 13:35 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 13:51 < queip> roasbeef: on mailing list quite visible post when someone spread things that seem to be FUD about LN, perhaps needs a reply 13:51 < queip> https://www.metzdowd.com/pipermail/cryptography/2020-December/036510.html 13:51 < queip> I mean, if you or someone wants 13:51 < queip> s/when/in which 13:58 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds] 14:12 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection] 14:13 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 14:30 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 14:31 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #lightning-dev 14:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds] 14:35 < Setherson> Looks to me like the rantings of someone who has issues with the fundamentals of Bitcoin's intrinsic properties and doesn't understand it entirely... 14:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 14:43 -!- mably [uid99779@gateway/web/irccloud.com/x-hfgkgvehibzegecx] has quit [Quit: Connection closed for inactivity] 14:44 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 14:51 -!- Setherson [~Setherson@108-255-110-61.lightspeed.tukrga.sbcglobal.net] has quit [Ping timeout: 256 seconds] 14:57 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 14:58 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 15:06 <+roasbeef> queip: /shrug why spend time on ppl that seem to have already made up their mind years ago, and don't attempt to seek out new information to update their beliefs and world view? 15:08 < aj> https://satoshi.nakamotoinstitute.org/posts/bitcointalk/287/ 15:09 <+roasbeef> I know of basically one generation of "cypherpunks" that have actually deployed things at scale that matter (and created an entirely new industry along the way!), and many of them participated in the IRC meeting we had earlier today. There're those that write code, and those that don't 15:10 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 15:12 -!- laptop [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 15:35 -!- laptop_ [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev 15:38 -!- laptop [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 265 seconds] 15:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 15:58 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev 15:59 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev 16:11 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 16:12 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 16:27 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 16:28 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 16:43 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 17:09 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:f4f0:d2c0:3ecf:a408] has joined #lightning-dev 17:56 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 17:57 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev 18:01 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 18:01 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 18:19 -!- laptop_ [~laptop@ppp-1-11.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 246 seconds] 18:20 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 18:20 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 18:51 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 18:53 -!- unauvum [~unauvum@134.122.10.34] has quit [Ping timeout: 260 seconds] 18:54 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds] 18:57 -!- unauvum [~unauvum@134.122.10.34] has joined #lightning-dev 19:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 20:07 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev 21:29 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 22:17 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:18 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 22:31 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 22:35 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 22:47 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer] 22:47 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev 22:58 -!- leetspete1 [~none@cpe-172-113-49-227.socal.res.rr.com] has quit [Ping timeout: 260 seconds] 23:08 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 23:08 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 23:19 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 23:20 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 23:30 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 23:32 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 23:34 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 23:37 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 23:37 -!- DeadWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev --- Log closed Tue Jan 05 00:00:06 2021