--- Log opened Mon May 25 00:00:30 2020
00:02 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has joined #lightning-dev
00:06 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
00:06 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
00:26 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
00:29 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
00:34 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
00:37 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
01:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
01:50 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Read error: No route to host]
01:50 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
01:55 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:58 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
02:01 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
02:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
02:04 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Remote host closed the connection]
02:04 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
02:04 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:06 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
03:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
03:21 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
03:21 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
03:21 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
04:04 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #lightning-dev
04:23 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
04:52 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
05:01 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
05:02 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:06 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Remote host closed the connection]
05:06 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
05:06 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:06 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
05:07 -!- drbrule [sid395654@gateway/web/irccloud.com/x-spubiqgnxgdxhodb] has quit [Ping timeout: 260 seconds]
05:10 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:10 -!- drbrule [sid395654@gateway/web/irccloud.com/x-vqcbtdzyxhuumfbq] has joined #lightning-dev
05:12 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
05:13 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
05:13 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:14 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Remote host closed the connection]
05:15 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
05:16 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
05:17 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:17 -!- r1clas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Client Quit]
05:19 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
05:22 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
05:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Quit: Leaving]
05:39 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
05:42 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Ping timeout: 265 seconds]
05:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:48 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Remote host closed the connection]
05:48 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
05:50 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
05:54 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
05:54 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Remote host closed the connection]
05:54 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
05:58 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
05:59 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
06:02 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds]
06:04 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Remote host closed the connection]
06:05 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
06:06 -!- jonatack [~jon@184.75.221.3] has joined #lightning-dev
06:12 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Read error: No route to host]
06:12 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
06:30 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
06:40 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
06:44 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Remote host closed the connection]
06:44 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has joined #lightning-dev
06:45 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:65b6:4d76:a0cb:f02f] has quit [Read error: Connection reset by peer]
06:48 -!- shesek [~shesek@5.102.222.33] has joined #lightning-dev
07:01 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
07:04 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Ping timeout: 240 seconds]
07:05 -!- shesek [~shesek@5.102.222.33] has quit [Quit: Leaving]
07:05 -!- shesek [~shesek@5.102.222.33] has joined #lightning-dev
07:05 -!- shesek [~shesek@5.102.222.33] has quit [Read error: Connection reset by peer]
07:11 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
08:01 -!- Bugz [~pi@035-134-226-003.res.spectrum.com] has quit [Read error: Connection reset by peer]
08:02 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Remote host closed the connection]
08:03 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
08:15 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev
08:16 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
08:17 -!- __gotcha1 is now known as __gotcha
08:18 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
08:24 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
08:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
08:35 -!- shesek [~shesek@5.102.222.33] has joined #lightning-dev
08:35 -!- shesek [~shesek@5.102.222.33] has quit [Changing host]
08:35 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
08:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
08:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
09:01 -!- rdymac [uid31665@gateway/web/irccloud.com/x-epkgwagzngybwfrp] has joined #lightning-dev
09:02 -!- Bugz [~pi@2600-6c67-8880-0168-c71d-66c8-53c5-9584.res6.spectrum.com] has joined #lightning-dev
09:10 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
09:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
09:23 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
09:23 -!- vasild_ is now known as vasild
09:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
09:50 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
10:18 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
10:21 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
10:40 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
10:54 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
10:54 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
10:59 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 260 seconds]
11:24 -!- AbramAde_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
11:26 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Ping timeout: 240 seconds]
11:27 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
11:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
11:31 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
11:59 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
12:03 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
12:06 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
12:08 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
12:27 -!- t-bast [~t-bast@2a01:e34:efde:97d0:b937:9951:b5da:5c06] has joined #lightning-dev
12:33 < drolmer> anyone knows the first (public) LN channel on mainnet?
12:33 -!- farukterzioglu [5f004b8b@95.0.75.139] has joined #lightning-dev
12:36 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
12:41 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 264 seconds]
12:44 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
12:45 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
12:45 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
12:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
12:50 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:00 < t-bast> Good morning/afternoon/evening everyone
13:00 < cdecker> Good evening t-bast :-)
13:00 -!- renepickhardt_nt [54d313e5@cm-84.211.19.229.getinternet.no] has joined #lightning-dev
13:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
13:01 < cdecker> Seems the US has a holiday, and Rusty is taking this morning off, might be a small gathering today
13:01 < ariard> Morning t-bast, cdecker :)
13:01 < cdecker> Morning ariard ^^
13:02 < bitconner> hey everyone!
13:02 < t-bast> Thanks for the trampoline review cdecker, I'll dig more into the possible node_announcement extension for gossip
13:02 < t-bast> Hey bitconner! Morning ariard ;)
13:04 < ariard> I think we can start meeting ?
13:04 < t-bast> shall we wait for more people or shall we start with the (somewhat easy) PRs?
13:05 < cdecker> t-bast: thanks for the quick replies, I think aside from the gossip extensions it looks very good
13:06 < cdecker> Ah, I had missed the new PRs that were added, on the plus side I think I'm caught up with the longer term things 
13:06 < t-bast> cdecker: thanks!
13:06 < cdecker> (well maybe apart from the anchor outputs one, which I'm still trying to stitch together in my mind)
13:07 < t-bast> Yes I added the small PRs that are pending, I think it shouldn't take us much time to review
13:07 < ariard> wrt for the security.d I replied for the high issues I expect this to solve
13:07 < ariard> mainly in case of grey area, being sure implementation coordinates between them
13:08 < ariard> I think to rewrite it according to the framework you linked cdecker, it's clean
13:08 < ariard> just 4. and 5. will redirect to per-implementation policy
13:09 < t-bast> I agree with your latest comment ariard on what this security.md should bring to the table
13:09 < t-bast> I think we can keep making progress on that on the PR directly, right?
13:09 < t-bast> #startmeeting
13:09 < lightningbot> Meeting started Mon May 25 20:09:38 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:09 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:09 < ariard> right, it was just to inform people :)
13:10 < t-bast> agreed, please all have a look at ariard's PR!
13:10 < t-bast> #topic Update test vectors to static_remotekey
13:10 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/758
13:10 < cdecker> Ah found the PR
13:10 < t-bast> Has someone been able to test these updated vectors? Eclair still doesn't support static_remotekey, so I'm bailing out on this one :)
13:11 < cdecker> Not that I know of for c-lightning, we're knee-deep in refactorings at the moment
13:11 < t-bast> bitconner maybe on the lnd side?
13:11 < cdecker> But I think we can count ACKs on the PR and apply directly, looks like an innocent enough change
13:12 < bitconner> i know we have tests, but can't say for sure these have been verified
13:12 < t-bast> Allright, so let's ACK on the PR once implementations are able to test these
13:12 < bitconner> sgtm
13:12 < t-bast> #action ACK on PR when test vectors have been verified by other implementations, then apply
13:12 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
13:13 < t-bast> #topic Clarify TLV record uniqueness in streams
13:13 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/777
13:13 < t-bast> This is a small clarification on the fact that TLV records can occur at most once in a stream
13:13 < t-bast> I think the rationale paragraphs are too dense and unnecessary, but apart from that it looks good to me
13:13 < cdecker> For a second there I was confused why bolt11 advocates for multiple `r` fields, but then I realized it's concatenated in the value
13:13 < bitconner> requirement changes lgtm, the rationale section should prorbably be cut down tho
13:14 < bitconner> the last paragraph is just an expansion of the final bullet above
13:14 < cdecker>  Agreed
13:14 < ariard> yes agree too, wording should be clarified
13:14 < bitconner> maybe i should leave some feedback as to how to condense the first paragraph into another bullet?
13:14 < cdecker> In general I think we should keep rationale to a minimum, and rather have it in proposal texts when necessary due to large changes or interdependencies
13:15 < t-bast> bitconner: SGTM
13:15 < cdecker> Sounds good bitconner ^^
13:15 < bitconner> 👍
13:15 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev
13:15 < t-bast> #action bitconner to comment, condense rationale paragraphs and then apply
13:15 < t-bast> #topic varint / bigsize clarification
13:15 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/778
13:16 < t-bast> This one is almost a spelling one IMO
13:16 < t-bast> Feels like a no-brainer
13:16 < cdecker> Yes, simple enough
13:16 < t-bast> c-lightning trying to have their u8 types invade the spec :D
13:17 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
13:17 < cdecker> Hehe, it makes our wire-code generation easy if we express the spec in C xD
13:17 < t-bast> xD
13:18 < cdecker> Since we're on the topic, I've been brainstorming a new description format with Maxim 
13:18 < bitconner> yeah changes lgtm
13:18 < bitconner> i think there's one paragraph currently removed that we should keep (frist one in bolt-01)
13:18 -!- sstone_ [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
13:19 < cdecker> The goal is to move away from weird markdown list and code markup, and instead move towards a more structured approach, such as yaml code-blocks, that are easier to parse and allow for more expressiveness
13:19 < t-bast> bitconner: why not, it felt fine to me to remove it, but I don't mind keeping it either, can you comment on the PR?
13:19 < t-bast> cdecker: yaml? yikes, that has created issues for many projects
13:20 < bitconner> sure i can do that
13:20 < bitconner> yaml > json
13:20 < cdecker> I know, but the current format is just hell, and anything where we can add type, length, name, and so on is an improvement
13:20 < cdecker> I just landed on yaml because it is slightly more human-readable
13:21 < t-bast> do you have a sample of what it would look like?
13:21 < cdecker> (also nesting datatypes, such as TLVs becomes really easy to do)
13:21 < t-bast> I agree that the current format can definitely be improved
13:21 < cdecker> I'll write up a small meta-proposal and see what the reaction is :-)
13:22 < t-bast> great thanks!
13:22 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Ping timeout: 260 seconds]
13:22 < t-bast> #action Decide whether we want to keep the paragraph mentioning Bitcoin varint or not, then apply
13:22 < bitconner> t-bast: actually i think moving the first paragraph is fine now that i read it more in depth
13:23 < bitconner> approved
13:23 < t-bast> bitconner: allright, I'll give you some time
13:23 < t-bast> that was fast
13:23 < cdecker> Hehe, the branch is called `die-varint-die`, I think Rusty might not like `varint`s
13:23 < t-bast> haha, I always love rusty's branch names
13:24 < t-bast> #action Apply #778
13:24 < t-bast> #topic flip(B) is incorrectly implemented, so we instead fix the spec xD
13:24 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/779
13:25 < t-bast> I discovered this part of our codebase when reacting to this PR, and indeed we don't implement what the spec says
13:25 < t-bast> But it looks like no-one does :D
13:26 < cdecker> That's ... uhm ... a very ancient part of the spec xD
13:26 < t-bast> Haha looks like it, do you remember coordinating to implement the same thing? Or did all three implementation mis-implement the spec the same way?
13:27 < bitconner> probably one of those "you know what i mean not what i say" instances
13:27 < t-bast> And what about rust-lightning ariard? How did you find out that what you had to implement was actually not what was spec-ed?
13:28 < cdecker> Usual "the spec is probably right, let's fiddle until it matches" I think
13:28 < bitconner> the obvious way to do this in english != the obvious way to do it in code lol
13:28 < t-bast> haha indeed, tweak our code until we match the test vectors
13:28 < ariard> t-bast: I'm checking right now, I think like bitconner said 
13:28 < ariard> really likely Matt copy-pasted from c-lightning on this
13:29 < cdecker> And the rust compiler trusted rusty's code :-)
13:30 < t-bast> lol, the secondary spec is c-lightning when the spec isn't clear enough
13:30 < t-bast> I think the clarification in rusty's PR is good enough, WDYT?
13:30 < ariard> Yes, we're doing it right, i.e enforcing the spirit of the spec
13:31 < cdecker> Anyhow, if we all agree that what we actually implemented is described by the change (and the intended characteristics are still met) then I think we should apply
13:31 < t-bast> https://imgflip.com/i/42sldk
13:31 < michaelfolkson> I don't think the secondary spec being c-lightning is in the spec t-bast :)
13:31 < ariard> wrt to this I found a case recently were c-lightning doesn't quote the BOLT like for everything else
13:31 < ja> i stumbled upon this a few years ago: https://stackoverflow.com/q/49928131/309483
13:31 < t-bast> michaelfolkson: but it looks like it works in practice! ;)
13:32 < cdecker> michaelfolkson: if you take the first letter each 13th word of the theme song it spells out that c-lightning is the reference xD
13:32 < t-bast> ja: yes, it looks like this was the old thread rusty resurected and decided to fix :)
13:32 < t-bast> shall we apply this PR?
13:33 < t-bast> Or do you want more time to check/review?
13:33 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has quit [Ping timeout: 256 seconds]
13:33 < t-bast> cdecker: that would be amazing steganography
13:34 < cdecker> I think it's safe to accept, if everyone else is already doing this, which seems to be the case
13:34 <+roasbeef> shows the scheme was a bit too clever...
13:34  * roasbeef recalls elkrem with longing 
13:35  * t-bast waves hello at roasbeef
13:35  * cdecker thinks we're trying to be clever too often :-)
13:35 < t-bast> We need to fix the spellchecker before applying, let's defer to github
13:35 < cdecker> ACK
13:35 < t-bast> #action fix spellchecker, wait for ACKs and apply
13:36 < t-bast> Which long-term thing do you want to discuss?
13:36 < ariard> I can talk on mempool-pinning fix, spent a bit of time thinking about the changes needed
13:36 < t-bast> I'd love to get feedback from lnd on route blinding vs the HORNET debate at some point ;)
13:37 < t-bast> sure, go for it ariard, the floor is yours
13:37 < t-bast> #topic mempool-pinning issues
13:37 <+roasbeef> anchor is more or less the same, we've deployed with lnd 0.10, also super timely imo since fees are pretty high rn, and you need to be able to bump at times to get things in when respecting the cltv delta 
13:37 <+roasbeef> likely the case that clv delta's should rise based on the current fee climate 
13:37 < bitconner> t-bast: yes i promise that's coming :)
13:37 < ariard> coool, basically we want to avoid second-stage transaction malleability to avoid your counterparty leveraging the mempool for pinning
13:38 < t-bast> roasbeef: is it on by default? did you get some interesting user feedback?
13:38 <+roasbeef> t-bast: it's a flag on start up rn, if both have it set then you'll make anchor chans
13:38 < ariard> roasbeef: what do you mean by anchor is more or less the same?
13:38 < bitconner> it's also behind a bulid flag atm
13:38 < t-bast> bitconner: I'm craving for some cryptographic fun, too much implementation recently :)
13:38 <+roasbeef> ariard: I mean no major movement
13:39 < ariard> to fix mempool pinning ? But you still have package size limit even if you somehow mitigate the absolte fee thing
13:40 < michaelfolkson> Jeremy Rubin had some strong views on the mempool at the Socratic last week
13:40 <+roasbeef> I mean on the format itself spec wise, pinning is kinda greater than the scheme itself, and there're a few diff problems being solved here 
13:40 < ariard> wrt to anchor output, I'm actively working on the RL implementation _without_ sighash introduciton, have few miscs to write on the spec
13:40 < michaelfolkson> "The mempool needs a complete rearchitecting and it doesn’t work in the way that anybody expects it to work."
13:41 < ariard> roasbeef: yes I think we can move forward with anchor output, just cutting the sighash thing for htlc input-ouput pair
13:41 < t-bast> michaelfolkson: that looks worrying...
13:41 <+roasbeef> michaelfolkson: yeh either we morph things to side step issues, or some more fundamental fixes need to be rolled out on the mempool layer 
13:41 <+roasbeef> ariard: why no sighash there? let's you combine them and actually bump the fee of the htlc transaction 
13:41 < ariard> michaelfolkson: it's a bit more complex, the mempool hasn't been designed for multiple txn offchain contract with time requirement
13:41 < ariard> roasbeef: because that's the opposite of where we want to go for fixing mempool pinning
13:42 <+roasbeef> current mempool stuff starts to really creak with any sort of transaction trees
13:42 <+roasbeef> ariard: missing context
13:43 <+roasbeef> with the sighash there, and the csv 1, they're forced to make a rbf-able transaction, so it's a race at that point as was covered in that ML thread
13:43 < ariard> roasbeef: okay pinning rely on bip125 rule 3 aka a high absolute fee but low-feerate to avoid eviction
13:43 < cdecker> Well, we can certainly lobby for longer term bitcoin mempool behavior changes, but that's not a solution for now
13:43 < ariard> or building a children branch to reach package size wrt to ancestor and therefore avoi eviction too
13:44 < cdecker> We probably need to go down both the mempool changes for longer term, as well find a good fix for th interim
13:44 <+roasbeef> cdecker: yeh def, big win rn is just even being able to modify the fee when you broadcast, given that fees seem to be sitting at a high-ish level rn 
13:44 < ariard> roasbeef: it solves 1) not 2) https://bitcoinops.org/en/topics/transaction-pinning/
13:44 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
13:45 < cdecker> I'd love to see eltoo's bring-your-own-fees applied to LN, but even eltoo might be vulnerable to tx pinning...
13:45 <+roasbeef> ariard: it's all super contextual imo still, as w/o miner cooperation, they can still end up just paying a high fee themselves which eventually _does_ confirm, if they can't thread the needle
13:45 < ariard> roasbeef: well if we add anchor ouptut to htlc transaction you can bump via CPFP, assuming your htlc tx has a pre-committed feerate high enough to get into network mempool
13:46 <+roasbeef> ariard: mhmm at the cost of a bigger htlc transaction, and inability to aggregrate them
13:46 <+roasbeef> which means more fes for htlcs, which are squeezed out even more size wise 
13:46 <+roasbeef> size as in amt
13:46 < ariard> roasbeef: doing so via maximum package size may have a low absolute fee
13:47 <+roasbeef> ariard: depends right? they'd still need a high total fee for the package right, or oder to have it all be accepted
13:47 < ariard> roasbeef: at the cost of bigger htlc transaction, agree until mempool has an API clear enough to lockdown-off confidently
13:47 <+roasbeef> also we don't really know how symmetric mempools are in the wild, if a large miner is running full rbf then the situation is diff
13:47 < ariard> roasbeef: no, you just need to get first in  network mempools and that's it, feerate is subsumed as a rule here
13:47 <+roasbeef> "first" ? 
13:48 < ariard> roasbeef: yes but I don't think that LN security model to have a boradcast path to a miner being full-rbf
13:48 <+roasbeef> we don't really know what "first" is here, there's no ordering 
13:48 < cdecker> Well, if the tx doesn't make it into the mempool we can't bump it using CPFP
13:48 <+roasbeef> ariard: depends, there're a few problems being solved here, and feels like we're focusing a lot on the tail end when it becomes more murky 
13:48 < ariard> roasbeef: I broadcast my preimage tx with a bigger child atteched to reach package limitation before you broadcast your HTLC-timeout
13:49 <+roasbeef> ariard: yeh I understand that scenario, but there're ordering assumptions here 
13:49 < ariard> roasbeef: if you're malicious and don't respect p2p broadcast you will likely being first in majority of network mempools
13:49 < ariard> roasbeef: right there is ordering scenario but malicious moves first
13:50 < ariard> roasbeef: I wouldn't make that much assumptions on miner mempools, it's sadly kinda a black box
13:50 < ariard> cdecker: right for this case you need package relay
13:50 <+roasbeef> you need to have the commitment confirm first, but all I'm getting at is that it's all pretty imprecise 
13:51 < ariard> roasbeef: honest party broadcast local commitment, it's get confirmed
13:51 <+roasbeef> i understand the scenarios
13:51 < ariard> attacker broadcast a preimage tx + a big child, bypassing p2p tx-relay honest rules to get an advantage
13:52 <+roasbeef> mhmm, and the safety here depends on how long it takes that to confirm
13:52 <+roasbeef> if I get the pre-image from the mempool, then my incoming htlc is ok 
13:52 < ariard> by safety you mean proobabilities of success for the attack
13:52 <+roasbeef> if I time out, then I made money on the outgoing 
13:53 < ariard> roasbeef: yes if I know your full-node, I can throw a conflict in your mempool to blind you
13:53 < ariard> specially if have full-malleability on the 2nd-stage tx
13:53 <+roasbeef> "If I know your full node", quite the assumption 
13:54 < ariard> roasbeef: I know but last time I check there was a consequent number of full-nodes using same IP address that a LN-node
13:54 <+roasbeef> lnd is planning on implementing mempool pre-image watching in our next major release 
13:54 < ariard> roasbeef: it would make attack harder, not impossible
13:54 <+roasbeef> yeh I understand, it's an easy mitigation 
13:55 <+roasbeef> it then escalates things even further to possilby req them to collude w/ a miner 
13:55 < ariard> I do think inter-layers mapping hasn't been studied that much and it's likely far easy than what we think
13:55 < ariard> roasbeef: no it doesnn't had the requirement to collude with miner, just to find your full-node
13:55 <+roasbeef> yeh it's all pretty fuzzy in the end imo, but there're a few low hanging fruits for mitigation, and let's not forget the #1 thing which is to actually be able to bump fees
13:55 <+roasbeef> might be the case that cltv deltas are too low network wide rn 
13:55 < ariard> and for big LN node like ACINQ, you may probe by opening zero-conf channel with them and see a tx propagation on the base layer
13:56 < t-bast> we do get preimages from the mempool though :)
13:56 < ariard> roasbeef: yes I would recommend to increase a bit cltv deltas, that;s an easy mitigation
13:56 < ariard> t-bast: let's me blind your mempool with a well-crafted conflict :)
13:57 <+roasbeef> ok but circling back, you're implementing with an anchor output on the htlcs, ariard ?
13:57 < t-bast> This brings back something I've been wondering: how hard would it be to bind two Bitcoin nodes together, so that one of them is only used as a "read" source by the second one?
13:57 < ariard> roasbeef: the #1 thing is to actually be able to bump fees, right you can RBF the CPFP on anchor
13:57 <+roasbeef> t-bast: elaborate? 
13:57 < t-bast> That would allow you to have a secondary Bitcoin node that can't be easily linked to your lightning node and thus eclipsed
13:57 < harding> t-bast: that's easy, bitcoind -connect=<ip of listening node>
13:57 <+roasbeef> ariard: referring to the commitment, as in just being able to land that, but yeh there're other ways to bumps fees for the htlc transactions 
13:58 < t-bast> harding: yes but if I simply do that, it should be somewhat easy for an eclipse attacker to figure out that this is my secondary node because my tx will show up very quickly on that secondary node, doesn't it?
13:58 < ariard> t-bast: it's doable just need to add few rpc in core with traffic class I guess, like open a block-relay-only connection
13:58 <+roasbeef> t-bast: mhmm, there're a few network configs possilbe to further isolate a not, or just selectively choose its peers, in the end still need e2e and auth to have full confidence if it isn't all on a private network 
13:58 < t-bast> I'd like to ensure that the primary node never directly sends its txes to the secondary node, it only reads from it
13:58 < ariard> roasbeef: yes agree we should move forward for anchor ouput on commitment tx, and defer sighash introduction
13:59 < ariard> t-bast: don't broadcast your transaction to this node, they just do block trafffic
13:59 <+roasbeef> ariard: in the end it's the tradeoff of having it there vs not and if ppl feel comfortable w/ the mitigations 
14:00 < t-bast> ariard: that was a possibility, but if I just get block traffic I can't extract my preimages from the mempool :/
14:00 < cdecker> roasbeef: kind of the point, people don't feel comfortable with it
14:00 < harding> t-bast: -connect by default only makes that single connection; it doesn't connect to any other peers.  So if A is your normal listening node and on B you do -connect=A, then B will only receive txes and blocks from A.  It sounds to me like you want something like https://github.com/laanwj/bitcoin-submittx or a Tor node.
14:00 < ariard> roasbeef: it's better forr security to bump commitment txn stuck in the mempool I agree, for mitigations it maybe not that much state machines depending on lockdown scope
14:00 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
14:01 < ariard> *state machine changes
14:01 < ariard> cdecker: how practical are these attacks is your wondering ?
14:01 <+roasbeef> batching htlc transactions together or w/ other transactions tho....
14:02 < t-bast> harding: thanks for the link, it's still just a random thought right now, I need to make it more precise. Can I send you a few questions directly once I've formalized my ideas?
14:02 < ariard> roasbeef: long-term I hope mempool being clean enough to lock-free htlc txn and batch them together
14:03 < cdecker> ariard: not very tbh, they take quite a bit of sophistication, but the fact that we're discussing them seems proof that people think they pose a risk (especially after blogs have picked it up and are reporting LN as being broken...)
14:03 < harding> t-bast: of course.  You may also want to ping matt as I've heard many miners have similar protections (their concern is having their listening nodes DoS'd by other pools).
14:03 < ariard> t-bast: yes I think you need to come up with a better attack scenario you're trying to mitigate because if you do what harding suggests B is useless for eclipse prevention
14:04 < t-bast> harding, ariard: thanks, I'll formalize that and share some thoughts with you and Matt soon-ish
14:04 < ariard> cdecker: LN isn't broken, LN is in boostrap phase :)
14:04  * cdecker wonders if we could at least strengthen ourselves by gossiping about channel closes and preimages
14:04 < cdecker> It'd only require one node watching the mempool, that raises the alarm for the network
14:05 < cdecker> ariard: damn, I always mix up nomenclature, right :-)
14:05 < ariard> cdecker: that's cleary an extension of security model, you know depend on your connection with them, I don't think it's a wrong fix but need to be analyzed
14:06 < ariard> *now
14:06 < ariard> cdecker: won't work with PTLC introduciton
14:06 < cdecker> Right, my thinking was more that the threat would likely already be sufficient to deter attackers...
14:06 < ariard> btw, the mitigation I was envisioning should be compatible with PTLCs, we will likely need another round-trip 
14:07 <+roasbeef> ariard: round trip for what outside of the extra interation of dlog htlcs? 
14:07 < ariard> cdecker: just blind the mempool of the "preimage-watcher" who has a nice public IP known to let other connecting to
14:07 < cdecker> ariard: it works for PTLCs, we just get xlen(route) the traffic, not optimal but if in the meantime we make progress with the mempool proposals it might just work
14:08 < ariard> roasbeef: you need to exchange partial_sigs before committing need state IIRC ?
14:08 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
14:08 < cdecker> ariard: that's sort of the point, there just need to be multiple, that can't all be blinded
14:08 <+roasbeef> ariard: you mean if you make all the htlc paths multi-sig/ 
14:08 <+roasbeef> ?
14:09 < cdecker> Ouch, that'd be painful for high-latency links...
14:09 < ariard> roasbeef: right, my point we may have to do state machines changes now to fix mempool-pinning but we woudln't have to change them again when we introduce PTLCs
14:09  * t-bast thinks that PTLC will require many more roundtrips than today (multi-hop locks is already quite costly), hope we can engineer this to be efficient enough
14:09 < ariard> just use new messages
14:09 <+roasbeef> ehh yeh idk if that'll work even, you need a lot of changes, as you need a new message before CommitSig
14:09 <+roasbeef> t-bast: depends on which sig scheme we end up using in the end 
14:09 < ariard> cdecker: why they can't all be blinded if we assume they are all publics ?
14:09 <+roasbeef> schnorr version adds the least round trips 
14:10 < t-bast> roasbeef: yes but it's already one more round-trip than today, isn't it?
14:10 <+roasbeef> feels like we've been talking aobut dlog htlcs for years now, with several ways to deploy em (which keep getting better, but there's also the ideal) 
14:10 < ariard> roasbeef: yes it depends if we lockdown HTLC-preimage only or also the remote HTLC-tiemout txn ?
14:10 <+roasbeef> t-bast: possilby we can piggy back the extra state on other messages? haven't worked thru it too much 
14:10 < cdecker> ariard: I'm saying that some LN nodes (public and non-public) watch the mempool, and start a broadcast whenever they see something that looks like a closure with HTLCs
14:11 < t-bast> roasbeef: that's what I'm hoping for, hopefully we can bundle many features in each roundtrip
14:11 < cdecker> Broadcast as in gossip broadcast, staggered and deduplicated, but quick enough to tell the impacted node about the HTLC details
14:11 < ariard> cdecker: how a honest non-watching LN-node do peer discovery of these special nodes to connect to ?
14:11 <+roasbeef> ariard: see my message on the mempool aobut this, if you want to lock down any other htlc path, then before you send a commit to the other party, you already need to have your version of that htlc sig 
14:12 < cdecker> ariard: they're not connecting to those node, the nodes send out a broadcast, just like they do with node_announcements and channel_announcements
14:12 < ariard> roasbeef: yes which means you need update_add_htlc ->, <- update_countersign_htlc, -> commitment_signed
14:12 < ariard> cdecker: I see, and we assume all routing nodes, which are the ones at risk accept all gossips messages
14:12 <+roasbeef> but zooming out, IMO if an implemetnation is able to implement _any_ form of anchors, then they should as soon as possible, given the current fee rates, if a ton of htlcs expire, you're likely to lose many of them 
14:12 < ariard> cdecker: is this a DoS vector ?
14:13 < cdecker> ariard: no, it's rate limited by channel closures
14:13 < cdecker> And deduplicated at each intermediate hop
14:13 < t-bast> cdecker: it's probably quite cheap to implement once we agree on the message, but isn't it also a new way of DoS-ing nodes by sending them many preimages to check against their current payments?
14:13 <+roasbeef> ariard: not sure that fully works, but yeh you need another message, not sure how that works on a concurrent setting too (that specific message) 
14:13 <+roasbeef> you can't send the sig before you nkow what the commitment looks like 
14:14 < t-bast> cdecker: oh you first prove that this is linked to a recent channel_close, something like that?
14:14 < ariard> cdecker: well it may work, I can draft the preimage-watching proposal and the htlc lockdwon and we compare tradeoffs
14:14 <+roasbeef> we use the ack mechanism so I know what to sign based on what you've gotten, so it might require another level of synchronization, idk, but the more I think about it the more the possible set of changes sweels 
14:14 <+roasbeef> swells
14:14 < ariard> roasbeef: it should be good we already assume A may commit state X and B commit state Y then converge
14:14 < cdecker> Yep, we could combine it with an explicit channel_close message to inform nodes that they can remove it from their view at the same time
14:15 < cdecker> ariard: sounds very good ^^
14:15 <+roasbeef> ariard: the devil is in the details ;)
14:15 < t-bast> ariard: ACK I'm ready to read these drafts ;)
14:15 < ariard> cdecker: network-wise garbage-collecting preimage, hmmmm let's try it
14:16 < cdecker> Might be a good use-case to try out `custommsg` facility with ^^
14:16 < ariard> okay will do a draft for both :)
14:16 < ariard> (I'm just not that much comfortable delegating my security to some random peer in the wild)
14:16 < t-bast> #action ariard to draft preimage-watching and htlc lockdown proposals
14:16 <+roasbeef> seems to add more blocking either way, since I need to now wait before I can send a sig, and I need a distinct ack for each htlc added, they all need to be done at once, since you need a stable commitment 
14:16 < ariard> even a swarm of them, that's really sounds like the "watchtower-swarm" idea :p
14:16 <+roasbeef> no_input makes it easier 
14:17 <+roasbeef> since you can send an htlc sig w/o knowing the commitmetn for it 
14:17 < cdecker> Totally agreed, hence the reliance on having anyone be honest in the network, not one specific node
14:17 < t-bast> let's get the ball rolling again on no_input!
14:17 < cdecker> 100%
14:17  * roasbeef snaps his fingers 
14:17  * roasbeef notices nothing happened...
14:17 < ariard> roasbeef: likely to add more latency, you were sayng schnorr PTLC doesn't have a round-trip ?
14:17 <+roasbeef> 5 more years for no_input
14:17 <+roasbeef> kek
14:17 < t-bast> roasbeef: do your magic, I know you can do better than that
14:17 -!- rdymac [uid31665@gateway/web/irccloud.com/x-epkgwagzngybwfrp] has quit [Quit: Connection closed for inactivity]
14:17 < ariard> like do you have scheme showcase
14:17 <+roasbeef> lolol
14:18 < cdecker> Hehe, would love progress on noinput/anyprevout ^^
14:18 -!- jonatack [~jon@184.75.221.3] has quit [Ping timeout: 258 seconds]
14:18 <+roasbeef> ariard: oh idk about that, was just mulling that we could maybe piggy back the state somewhere 
14:18 < ariard> cdecker: I think people expect first to get taproot, before to throw brainpower on eltoo 
14:18 <+roasbeef> i haven't thought about that stuff too much since it just seems to creep further out into the future 
14:19 < cdecker> ariard: yeah, that's my impression too, and I don't want to add noises about noinput that might delay schnorr + taproot
14:19 <+roasbeef> ariard: re blocking above, i was referring to the immediate implications of trying to lock down all htlc spend paths 
14:19 < ariard> roasbeef: I know I was just "if we have to do state machines changes just let be sure they fit with handwawing future features"
14:19 <+roasbeef> mhmm gotcha ariard 
14:19 < cdecker> Anyway, I need to drop off
14:20 -!- jonatack [~jon@37.170.134.59] has joined #lightning-dev
14:20 < cdecker> This was a really productive meeting, thanks everybody, and in particular to t-bast for chairing ^^
14:20 < ariard> yes, I'm going forward with implementing anchor outputs and will do draft to have ab etter opinon on mitigations :)
14:20 < cdecker> Hope to see all of you in person some time soon :-)
14:20 < t-bast> Agreed, loved the discussion at the end on mempool issues, very enlightening
14:21 < t-bast> Thanks everyone, let's keep in touch on github and someday IRL ;)
14:21 < t-bast> #endmeeting
14:21 < lightningbot> Meeting ended Mon May 25 21:21:14 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:21 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-05-25-20.09.html
14:21 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-05-25-20.09.txt
14:21 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-05-25-20.09.log.html
14:21 <+roasbeef> ahh I remember IRL 
14:21 < t-bast> pepperidge farm remembers
14:21 <+roasbeef> lol
14:21 < ariard> roasbeef: it was segwit deployment isn't it ?
14:21 <+roasbeef> we're def overdue for another squad meet up though, really looking forward to whenever that happens again 
14:22 < t-bast> totally agree, would love to see another lightning conf or bitcoin conf to gather us all
14:22 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection]
14:23 <+roasbeef> yeh there's just something about meatspace when it comes to convos/collab/chilling 
14:24 <+roasbeef> I guess we could all wear full body hazmat suits 
14:24 <+roasbeef> and use like straws
14:24 <+roasbeef> and integrated mics with an external speaker 
14:24 <+roasbeef> use the LN gang sign as a greeting 
14:26 < t-bast> I'd love to see that, that'd be something
14:26 -!- slivera [~slivera@103.231.88.27] has joined #lightning-dev
14:27 <+roasbeef> would be pretty bad ass
14:27 <+roasbeef> i can start on some rough sketches on paper 
14:28 <+roasbeef> and a gif for the hand sign 
14:28 < t-bast> haha let me add you an action item for that
14:29 < t-bast> Done, you got some work for the next two weeks: https://github.com/lightningnetwork/lightning-rfc/issues/775
14:30 -!- shesek` [~shesek@185.3.145.28] has joined #lightning-dev
14:30 <+roasbeef> i'll prob start with the naruto hand sign for lightning jutsu, then iterate from there
14:33 < t-bast> oh yeah definitely, get that chidori jutsu going 
14:33 < t-bast> gotta go, see you next time!
14:33 -!- t-bast [~t-bast@2a01:e34:efde:97d0:b937:9951:b5da:5c06] has quit [Quit: Leaving]
14:34 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
14:38 < riclas> weebs ^^
14:40 -!- sstone_ [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
14:55 -!- renepickhardt_nt [54d313e5@cm-84.211.19.229.getinternet.no] has quit [Remote host closed the connection]
15:00 -!- shesek` [~shesek@185.3.145.28] has left #lightning-dev []
15:01 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
15:02 -!- farukterzioglu [5f004b8b@95.0.75.139] has quit [Ping timeout: 245 seconds]
15:43 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
15:44 < dfmb_> is this true ? https://twitter.com/Truthcoin/status/1234535778719539208
15:46 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 256 seconds]
15:46 -!- AbramAde_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Ping timeout: 260 seconds]
15:59 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
16:07 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds]
16:07 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Ping timeout: 246 seconds]
16:07 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
16:11 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #lightning-dev
16:18 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
16:19 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:22 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 272 seconds]
16:39 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
16:57 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 264 seconds]
17:11 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
17:13 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving]
17:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:38 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev
17:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
17:51 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 272 seconds]
18:05 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 264 seconds]
18:17 < ghost43> some nodes on testnet are sending me invalid channel announcement messages in the gossip. anyone else seen this? it's only for one specific channel, but I am getting it from at least 7 distinct peers, at least some of which are running lnd. I have managed to find the correct chan ann for said channel and the malfunctioning peers seem to have zeroed out the 'features' field, so the signature checks all fail.
18:18 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
18:48 -!- bauerj [~bauerj@unaffiliated/bauerj] has quit [Remote host closed the connection]
18:48 -!- bauerj [~bauerj@unaffiliated/bauerj] has joined #lightning-dev
18:55 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 265 seconds]
19:05 < ghost43> I suspect it must be an lnd bug, so now opened: https://github.com/lightningnetwork/lnd/issues/4322
19:28 -!- CCR5-D32 [~CCR5@unaffiliated/ccr5-d32] has quit [Quit: ZZZzzz…]
19:46 -!- AbramAdelmo_ [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Remote host closed the connection]
20:23 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
20:24 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:a52f:3be5:1e66:9f84] has joined #lightning-dev
20:40 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
20:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:57 -!- yzernik_ [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
20:57 -!- yzernik [~yzernik@2600:1700:dc40:3dd0:a52f:3be5:1e66:9f84] has quit [Ping timeout: 260 seconds]
21:01 -!- yzernik_ [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 246 seconds]
21:06 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
21:16 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
21:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
21:23 -!- vasild_ is now known as vasild
21:32 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
22:18 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has joined #lightning-dev
22:22 -!- AbramAdelmo [AbramAdelm@gateway/vpn/protonvpn/abramadelmo] has quit [Ping timeout: 260 seconds]
22:28 -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
22:28 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]
22:45 -!- marcoagner [~user@bl13-226-166.dsl.telepac.pt] has joined #lightning-dev
22:57 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
23:00 -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:11 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
23:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
23:39 -!- wpaulino [~wpaulino@unaffiliated/wpaulino] has quit [Ping timeout: 240 seconds]
23:40 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
23:41 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
23:44 -!- t-bast [~t-bast@2a01:e34:efde:97d0:6553:500a:720a:77c6] has joined #lightning-dev
23:47 -!- wpaulino [~wpaulino@unaffiliated/wpaulino] has joined #lightning-dev
23:56 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
--- Log closed Tue May 26 00:00:31 2020