--- Log opened Mon Sep 02 00:01:01 2019 00:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 00:10 -!- michaelfolkson [~textual@141.226.39.63] has joined #lightning-dev 00:42 -!- michaelfolkson [~textual@141.226.39.63] has quit [Quit: Sleep mode] 00:46 -!- laptop500 [~laptop@92.118.153.193] has joined #lightning-dev 00:50 -!- michaelfolkson [~textual@141.226.39.63] has joined #lightning-dev 00:57 -!- laptop500 [~laptop@92.118.153.193] has quit [Remote host closed the connection] 00:57 -!- laptop500 [~laptop@92.118.153.193] has joined #lightning-dev 00:58 -!- michaelfolkson [~textual@141.226.39.63] has quit [Quit: Sleep mode] 01:01 -!- laptop500 [~laptop@92.118.153.193] has quit [Remote host closed the connection] 01:02 -!- laptop500 [~laptop@92.118.153.193] has joined #lightning-dev 01:18 -!- michaelfolkson [~textual@141.226.39.63] has joined #lightning-dev 01:22 -!- michaelfolkson [~textual@141.226.39.63] has quit [Client Quit] 01:41 -!- michaelfolkson [~textual@141.226.39.63] has joined #lightning-dev 01:45 -!- michaelfolkson [~textual@141.226.39.63] has quit [Client Quit] 01:53 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 02:43 -!- michaelfolkson [~textual@bzq-109-66-42-46.red.bezeqint.net] has joined #lightning-dev 02:47 -!- michaelfolkson [~textual@bzq-109-66-42-46.red.bezeqint.net] has quit [Remote host closed the connection] 02:56 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 02:56 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev 03:22 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 03:43 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 03:43 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 03:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 04:08 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-lscjehmtoqorwlyv] has quit [Write error: Connection reset by peer] 04:08 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-cbtlnfdfdgaepqxu] has quit [Write error: Connection reset by peer] 04:08 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-mokvbclrqwgttjpo] has quit [Remote host closed the connection] 04:08 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-sedqzsdjmvnktesl] has quit [Remote host closed the connection] 04:08 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-ornbxnwjhaeenhuz] has quit [Remote host closed the connection] 04:11 -!- cdecker [~cdecker@mail.snyke.net] has quit [Quit: WeeChat 0.4.2] 04:11 -!- cdecker [~cdecker@mail.snyke.net] has joined #lightning-dev 04:17 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-lsexfshlqnefvfrm] has joined #lightning-dev 04:23 -!- shesek [~shesek@5.102.212.239] has joined #lightning-dev 04:23 -!- shesek [~shesek@5.102.212.239] has quit [Changing host] 04:23 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 04:39 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 05:18 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-higpbvwbhieguaam] has joined #lightning-dev 05:18 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-pcubfumteriswxhc] has joined #lightning-dev 05:18 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-xyjavuxaplvunjsz] has joined #lightning-dev 05:18 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-iawfoivkqcotnszu] has joined #lightning-dev 05:24 -!- shesek [~shesek@5.102.212.239] has joined #lightning-dev 05:24 -!- shesek [~shesek@5.102.212.239] has quit [Changing host] 05:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 05:26 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 05:27 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 258 seconds] 05:35 -!- farmerwampum [~farmerwam@195.206.105.2] has quit [Ping timeout: 268 seconds] 05:48 -!- farmerwampum [~farmerwam@185.236.201.215] has joined #lightning-dev 05:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 06:05 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 06:10 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 06:38 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 06:42 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 246 seconds] 06:49 -!- noxx [~noxx@p200300E6172A1900019837361B985760.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 06:50 -!- noxx [~noxx@p200300E6172A1900DC6AFBA1728F81A4.dip0.t-ipconnect.de] has joined #lightning-dev 06:56 -!- noxx [~noxx@p200300E6172A1900DC6AFBA1728F81A4.dip0.t-ipconnect.de] has quit [Quit: Leaving] 06:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 06:59 -!- noxx [~noxx@p200300E6172A19003DF493CDF18DF455.dip0.t-ipconnect.de] has joined #lightning-dev 06:59 -!- noxx [~noxx@p200300E6172A19003DF493CDF18DF455.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:00 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Read error: No route to host] 07:01 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 07:02 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 07:02 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 07:15 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 07:16 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 07:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 258 seconds] 07:33 -!- _Sam-- [~greybits@unaffiliated/greybits] has joined #lightning-dev 07:37 -!- kam270 [~kam270@183.182.104.69] has quit [Ping timeout: 245 seconds] 07:46 -!- noxx [~noxx@p200300E6172A19003449E1BFC8BA288E.dip0.t-ipconnect.de] has joined #lightning-dev 07:53 -!- noxx [~noxx@p200300E6172A19003449E1BFC8BA288E.dip0.t-ipconnect.de] has quit [Quit: Leaving] 08:03 -!- noxx [~noxx@p200300E6172A190068F77DB625AB73C8.dip0.t-ipconnect.de] has joined #lightning-dev 08:03 -!- elhamess is now known as hamess 08:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 08:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 08:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 08:58 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 09:01 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 09:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 09:17 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 09:29 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection] 09:34 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds] 09:50 -!- noxx [~noxx@p200300E6172A190068F77DB625AB73C8.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 09:51 -!- noxx [~noxx@p200300E6172A19009925210513261524.dip0.t-ipconnect.de] has joined #lightning-dev 09:53 -!- noxx [~noxx@p200300E6172A19009925210513261524.dip0.t-ipconnect.de] has quit [Client Quit] 10:10 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 11:07 -!- shesek [~shesek@5.102.212.239] has joined #lightning-dev 11:07 -!- shesek [~shesek@5.102.212.239] has quit [Changing host] 11:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 11:16 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 245 seconds] 11:27 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 260 seconds] 11:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 11:38 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 11:50 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has quit [Read error: Connection reset by peer] 11:51 -!- vtnerd [~Lee@173-23-103-30.client.mchsi.com] has joined #lightning-dev 12:11 -!- laptop500 [~laptop@92.118.153.193] has quit [Quit: Leaving] 12:22 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 12:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 244 seconds] 12:37 -!- t-bast [~t-bast@2a01:e34:ec2c:260:f0b4:ac3b:9c3f:6386] has joined #lightning-dev 12:50 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1967:8e38:f46a:3c52] has joined #lightning-dev 12:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:58 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 12:58 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Client Quit] 12:59 < t-bast> Hi everyone! 13:00 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 13:02 < rusty> Hello! Who is chairing today BTW? 13:02 < cdecker> Hi :-) 13:02 < niftynei> hello! 13:02 <+roasbeef> oy, it's a holiday here in the U.S so dunno if the others will be on 13:03 < t-bast> I can chair if no-one else wants 13:05 -!- hiroki_ [0e0c0742@M014012007066.v4.enabler.ne.jp] has joined #lightning-dev 13:06 < cdecker> roasbeef: what's that h-o-l-i-d-a-y-s? :-) 13:06 < rusty> t-bast: that's an ACK I think! 13:06 < t-bast> let's do this then 13:06 < t-bast> #startmeeting 13:06 < lightningbot> Meeting started Mon Sep 2 20:06:48 2019 UTC. The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:06 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:06 < rusty> cdecker: it's when you take time off of typing out new code to think about spec issues :) 13:07 < cdecker> Ah, I see, maybe I should try some 13:07 < t-bast> let's warm up with a small PR that was almost accepted last time 13:07 < t-bast> #topic 657 13:07 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/657 13:08 < t-bast> a small clarification on the ordering of messages around funding_locked (we have a few PRs open on those subjects) 13:08 < t-bast> we ack-ed it last time asking for a small change that has been done 13:09 < rusty> t-bast: Ack, apply. Though "turbo channels" would require this, I think. 13:09 < t-bast> Allright, let's merge this. 13:10 < cdecker> rusty: well turbo channels just send locked-in immediately 13:10 < cdecker> So there should not be any issue here 13:10 < t-bast> a few small things around onion encryption now (should be fast too) 13:10 < t-bast> #topic 663 13:10 < cdecker> They just consider 0-conf as depth reached 13:10 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/663 13:11 < t-bast> This PR proposed changing the short channel id tlv to save a few bytes, mentioning the last hop 13:11 < t-bast> as Rusty points out, the last hop will completely omit this tlv field, so we probably don't need this PR 13:12 <+roasbeef> should be called "zero conf chans" ratehr than "turbo chans", the turbo part over sells a bit, ppl should think twice about the implications of accepting a zero conf channel 13:12 <+roasbeef> iirc it optionally can, we still put it tehre since the main termination signal is the hmac 13:13 < t-bast> yeah but if it can be removed and it's useless, just remove it to save bytes :) 13:13 < cdecker> roasbeef: totally agreed, it's a hack 13:13 < rusty> roasbeef: agreed, zero-conf. 13:13 < t-bast> switching to tu64 would save a few bytes for intermediate hops though 13:13 < cdecker> t-bast: re 663 we only save anything if the short_channel_id fits into 32 bits, right? So nowhere :-) 13:14 < t-bast> hum no, tu64 can be any size smaller than 8 13:14 <+roasbeef> yeh originally I thought since we always utilize the full 64-bits, we decided to not also truncate this one 13:14 < cdecker> With the current height any short_channel_id requires 59 bits to represent, i.e., 64 13:14 <+roasbeef> or nearly the full 13:14 < t-bast> ah ok, if we're already using 59 bits then it's useless indeed :D 13:15 < cdecker> At least if my math doesn't abandon me (log2(590000 << 40) >= 59 bits) 13:15 < cdecker> Shall we add a quick comment to that effect and close then? 13:16 <+roasbeef> well would want to give conner a chance to chime in 13:16 < cdecker> Right, I'll comment and leave it open ^^ 13:16 <+roasbeef> for those that _do_ include it would still be a savings 13:16 < t-bast> I agree, let's summarize this as a comment in the PR and bitconner will close 13:16 < t-bast> roasbeef: but wouldn't you just stop including it instead? 13:16 < cdecker> roasbeef: where would you include it and it'd require fewer bytes? 13:17 <+roasbeef> t-bast: it's more uniform on our end code wise if it's always included 13:17 <+roasbeef> the last hop 13:17 < rusty> No, you can't include it. It's even, and it's a protocol violation. 13:18 < cdecker> roasbeef: if we switch to tu64 we suddenly encode the short_channel_id as 9 bytes (length byte + 8 payload bytes), so an overall loss 13:19 < rusty> The writer: ... - MUST NOT include `short_channel_id` for the final node. 13:19 < rusty> It's right there in the spec. 13:19 < t-bast> cdecker: but the length byte is already there since it's a TLV field 13:19 < cdecker> Oh right, sorry my confusion ^^ 13:20 < t-bast> Sounds like the spec has spoken: the protocol already says this field shouldn't be included (even though our implementation currently just ignores it if it's included). 13:20 <+roasbeef> ok, soudns like mis comms somehere there, iirc there was talk of adding a tlv bool to indicate the final hop, but then we just decided that omitting it amounted to the same 13:20 < t-bast> roasbeef: we instead kept the empty HMAC to signal termination 13:20 <+roasbeef> but i think we can move on, and allow conner to chie in once he's back 13:20 < cdecker> rusty: where is that quote from so I can add it to the comment on the PR? 13:21 < rusty> cdecker: the same PR... 13:21 < t-bast> roasbeef: totally agree, let's move on 13:21 <+roasbeef> tbh things get lost at time when there's like a 30 comment deep thread on a PR 13:21 < t-bast> #action comment why we think it's not useful, let bitconner close the PR and chime in 13:21 < t-bast> #topic 627 13:21 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/627 13:22 < t-bast> This is the "generic" error code for invalid onion payloads (decryption was fine, but we're missing content or receive an invalid tlv stream) 13:22 < cdecker> roasbeef: same here :-) I tend to get cross-eyed the longer the PR thread 13:22 < t-bast> I added two fields to help debug what we dislike in the tlv stream: joost proposed using a tlv format which could be interesting 13:23 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 13:24 < t-bast> I think the onion failure code and the NODE, PERM, BADONION and UPDATE bits are useful so I wouldn't migrate all errors to using just TLV. But for the content of failures, should we use TLV instead of a fixed structure? 13:25 < lndbot> hi all. yes, i see advantages of converting the failure message to tlv. it would also allow us to have a custom reply, just as we have can have a custom record in the hop payload. 13:25 <+roasbeef> we don't have much space on the errors to being with, so do we really want the extra signalling over head/ 13:25 <+roasbeef> ? 13:25 < lndbot> can't those bits be reconstructed using a simple mapping? 13:26 <+roasbeef> how do you know if the sender understands this new format/ 13:26 <+roasbeef> ? 13:26 < cdecker> Hm, I get browser user-agent flashbacks with this sort of thing tbh 13:26 < t-bast> roasbeef: I agree that this is where we're the most space-constrained, so maybe we want to keep the current format 13:26 < lndbot> introduce a new failure code now that will contain a tlv stream with everything that is defined from now on 13:26 <+roasbeef> (if talking of replacing the current bits w/ new types) 13:26 < rusty> I think this is useful for diag, but it's a "shouldn't happen" kinda case, so it's hard to get too upset about the format detals. 13:26 < cdecker> I think errors ought to be short and concise, and hints at best, not a fully fledged debugging facility 13:27 < t-bast> I agree with cdecker 13:27 < t-bast> And the parsing should always be very simple, so maybe we shouldn't mix TLV into it? 13:27 < cdecker> If a node errors out we just drop it from future communication (would also incentivize people to build robust networks and update their nodes in time) 13:27 < lndbot> we now already have variable length failure messages because of older versions. checking EOF whether to keep on reading. that could disappear with tlv 13:28 < cdecker> By EOF you mean the framing of the message? 13:28 < lndbot> some errors like invalid_payment_details, we have been adding new fields over time 13:29 < lndbot> in reading those errors, we need to be aware that there are multiple versions of it 13:29 <+roasbeef> cdecker: EOF as in if there's any bytes left in the steam 13:29 < t-bast> But we're still constrained by the fixed size of the failure message, which adds some complexity when putting TLV inside it 13:29 < lndbot> v0 had no params, v1 had an amt and v2 an amt and height 13:29 < lndbot> eof, no bytes left 13:29 < lndbot> and we cannot get rid of params that we don't use anymore 13:30 < t-bast> I think that using tlv here will make less obvious that messages don't overflow the failure message size 13:30 < lndbot> like amt for invalid_pay_details, which is redundant really 13:30 < cdecker> Hm, I see your point 13:30 < lndbot> overflow check could be done at any point 13:32 < t-bast> I like the fact that when you read the spec, you easily see that all the failure messages are well below the 256 bytes limit. If we use TLV, it's going to be less obvious... 13:32 < lndbot> and the idea of a custom failure message also has some merit i think. suppose you send an htlc with a custom 'exchange deposit address'. the recipient could add a custom app-specific failure to the tlv stream like 'deposit limit exceeded' 13:32 < lndbot> (defined in the 2^16+ range) 13:33 < t-bast> I honestly don't have a strong position for either choice 13:33 <+roasbeef> so sounds like you're talking aobut an entirely new custom failure message now joost? 13:34 < lndbot> imo flexbility in the format, saving bytes by not being forced to encode legacy fields and the ability to add custom data outweighs an easy length verification in the spec 13:34 < cdecker> Ok, that'd be a more involved change though 13:34 < lndbot> no, not entirely new. just a new failure code within the current msg format 13:34 < cdecker> Let's focus on the specific case at hand here 13:34 <+roasbeef> we can't remove any of those legacy fields at this point 13:34 <+roasbeef> ok a new failure code for custom messages, but seems out of the scoep of this new error for invalid tlv payloads 13:34 < lndbot> not those, but any new fields that we'd add to the tlv stream that may become legacy later on can be removed 13:34 < cdecker> roasbeef: we could try, and then start crying when we see how many nodes crash xD 13:35 < lndbot> strictly speaking out of scope, but when is a good time to do this otherwise? i think it is a nice opportunity now that a new failure code with the current drawbacks is about to be added 13:35 < lndbot> especially if people want to add some custom debugging tlv data 13:36 < t-bast> Ok I think there's a will to start using tlv in the future in onion errors as Joost points out, which could make sense. So I'm proposing to update my PR to use a tlv stream in the error code I'm adding to go in this direction, and another PR can introduce a more generic TLV error code for the use-cases Joost mentions. What do you think? 13:36 < t-bast> This way we solve the current issue (which is a specific error code for onion invalid payloads) and we open the door for more changes later. 13:36 < cdecker> t-bast: how about we merge your PR, without the hint fields and then we can bikeshed the payload to add? 13:37 < cdecker> Adding fields is always allowed :-) 13:37 < cdecker> And we'd just be adding a single TLV-stream field 13:37 < lndbot> ending up with two failure codes that have tlv stream associated may be less desirable 13:37 < cdecker> (once we nail down the specifics) 13:37 <+roasbeef> changing the error code fro this would be a bigger divergence, as all the existing error messages use this bitfield format, this can be considered a "core set" 13:37 < t-bast> cdecker: I like that proposal 13:37 <+roasbeef> and we also don't know how to know if the sender supports the new error codes 13:37 < t-bast> joost: I disagree, I don't think the tlv field should replace the current error code 13:38 < t-bast> the current error code (first two bytes) is really useful to aggregate common failure scenario (like just probing for the PERM bit to be set) 13:38 < lndbot> t-bast, you want to add a tlv stream to every future failure code that has additional data? 13:39 < t-bast> exactly instead of fixed encoding 13:39 < cdecker> I agree with t-bast, we can talk about making the payload after the type a TLV, not replace the entire error with just a TLV bag 13:39 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 13:39 < lndbot> it is a nice intermediate step. doesn't allow for custom failure message though. or at least not in the same way 13:40 < cdecker> joost: not sure we _want_ custom failures at all tbh 13:40 < rusty> The only purpose for these error codes is to print in a debugger. 13:40 < cdecker> I want to avoid at all costs that LN becomes a general purpose communication network 13:41 <+roasbeef> if that's all y'all use them for, then you're not integrating some useful information into your path finding attempts 13:41 < t-bast> rusty: what do you think of Joost's comment to use onion error to forward an application-level error to the sender? I think it could make sense in the future for lightning apps. 13:41 <+roasbeef> cdecker: pretty long distance from a custom error to general purpose communication 13:41 < lndbot> haven't brainstormed much about use cases, but it is the complementary in a way of a custom record in the updateadd payload. 13:41 < rusty> roasbeef: the broad error codes, yes, the sub erorr codes, like which TLV field failed to parse? 13:42 < t-bast> I think we may be spending a bit too much time on this, I'll update the PR to go in the direction cdecker proposed, and we can re-visit a broader change in another PR. Sounds good? 13:42 < cdecker> rusty: we also use the channel_updates in the errors :-) 13:42 < rusty> t-bast: see cdecker's point about creating a general comms mechanism... 13:42 < rusty> Meanwhile, I 13:43 <+roasbeef> not comms, just additional erroc context, comms would be adding an opauqe payload to each htlc or error 13:43 < rusty> I think I've decided that our feature bits are too complex for any human, and am trying to simplify them into one set of feature bits, re 557. 13:43 <+roasbeef> but i'm for just proceeding with that error as is, then later on examining allowing axtra daata at the end of errors 13:43 < cdecker> Ok, shall we go with the minimal viable PR (error code, without payload) now and bikeshed the payload in a new PR? 13:43 <+roasbeef> for the ones that have chan upddates, there isn't much room anyway fwiw 13:43 < rusty> roasbeef: "t-bast: rusty: what do you think of Joost's comment to use onion error to forward an application-level error to the sender? I think it could make sense in the future for lightning apps." 13:44 < rusty> cdecker: ack 13:44 < t-bast> cdecker: ack 13:44 <+roasbeef> ? 13:44 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 13:44 < t-bast> #action t-bast to simplify the PR - broader change deferred 13:44 <+roasbeef> what simplification? 13:44 <+roasbeef> looks fine as is to me 13:45 < t-bast> only add the error code but no content yet 13:45 <+roasbeef> the content is useful for debugging 13:45 <+roasbeef> otherwise you get no feedback 13:45 < t-bast> yes but if we want to switch it to use TLV later it's a breaking change and has to use another error code... 13:45 < cdecker> roasbeef: but we have a competing proposal for a different encoding, hence we postpone decision on the format of the content 13:45 <+roasbeef> but then it woudl go in, defined as having no payload? 13:46 < cdecker> Exactly, but adding fields is allowed 13:46 < rusty> I somewhat agree with roasbeef here. If we're not enclosing any info, why bother merging it 13:46 <+roasbeef> yeh we just use invalid onion versino atm in place of this 13:46 < t-bast> But then do you want that content to be TLV or fixed-encoding as currently proposed? 13:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 13:47 < lndbot> the problem with invalid onion version is that it isn't clear which node to blame. this error can be trigger by node x+1 sending a malformed htlc error to node x, who passes it back to the origin 13:47 < rusty> t-bast: fixed encoding is fine, TBH. I mean, TLV is nice in theory, but it's overkill AFAICT. 13:48 < t-bast> allright, so should we then even merge it as-is? Or do you see something that should change roasbeef / rusty ? 13:48 <+roasbeef> i'm good w/ it as is, and also think that custom error is an interesting direciton that warrants it's own PR 13:48 < rusty> Yes, I would have voted to merge as-is. Frankly, if we decide TLV is the ONE TRUE WAY later, I think we'll find that no implementation is relying on this format for anything meaningful. 13:49 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 13:49 < rusty> I mean, you're not supposed to be using it to probe what TLVs the node understands... 13:49 < t-bast> Good! So let's merge this and work on another proposal to integrate TLV in there. 13:49 < t-bast> #action merge 627, re-visit TLV in onion failures later 13:49 < t-bast> #topic 557 13:49 < cdecker> ack 13:49 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/557 13:50 < t-bast> Rusty you started mentioning something about 557? 13:50 <+roasbeef> as far as prbing, nodes already signal what they understand in feature bits, unless they're trying to be sneaky... 13:50 < rusty> t-bast: yes. I was reworking it with the new naming, and it got horribly confusing. 13:50 < t-bast> By new naming you mean feature bit unification? 13:51 < rusty> t-bast: yes. 13:51 < t-bast> Can you share why it becomes confusing? 13:51 < rusty> t-bast: we have three places where feature bits are used. In the init msg there are two distinct sets. In the channel_announce there is one, in the node_announce there is one. 13:51 < t-bast> And those don't map cleanly to one of the two feature types? 13:52 < rusty> t-bast: yeah. 13:52 < rusty> t-bast: I think we should simply have one set of feature bits. And each one specifies whether it's places in the channel_ann and/or node_ann. 13:52 < rusty> t-bast: we leave the "global feature set" in initmsg as an empty set. 13:53 < t-bast> If we have only one set of feature bits, then shouldn't we always include them in both channel_ann and node_ann? 13:53 < rusty> This solves the naming problem: we jsut have "feature bits"/ 13:53 < t-bast> Heh, nice way of avoiding picking different names xD 13:53 < cdecker> Simplification you say? Count me in ^^ 13:53 <+roasbeef> how's this related to 557? 13:54 < rusty> roasbeef: sorry, #571 oops 13:54 < t-bast> ah ok, switching the topic 13:54 < t-bast> #topic 571 13:54 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/571 13:54 < t-bast> I thought channel queries feature bits made you realize that :) 13:56 < rusty> So anyway, I'll create a replacement for 571 after the meeting with this simplification, and some examples of how various proposed features would work. But generally a feature wants to be in node_ann (so people can find you), and *may* want to be in channel_ann if it effects how you use that channel. 13:56 <+roasbeef> yep, like tlv stuff for example 13:56 <+roasbeef> as rn we don't have very good ways of syncing node anns either 13:56 <+roasbeef> tlv onion stuff* 13:57 < rusty> roasbeef: exactly. 13:57 < t-bast> Ok, curious to see that new PR then 13:57 < rusty> Yeah, sorry I didn't get it done in time. 13:57 < rusty> OK, let's move on? 13:57 < t-bast> #action rusty to create a new PR to supercede 571 13:57 < t-bast> #topic 557 13:57 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/557 13:58 < niftynei> need to hop off :wave: 13:58 * t-bast waves at niftynei 13:58 < t-bast> sstone has tested CL and Eclair compatibility for 557 13:58 < t-bast> With the latest changes applied, it seems everything is working fine 13:58 < t-bast> Rusty, did you have time to test it yourself? 13:59 < rusty> Yes, I have tested it against our updated protocol tests, and it's all good. 13:59 < rusty> It's quite a simple change really. 13:59 < t-bast> Ok, so shall we merge this spec PR and LL can implement later? 13:59 < rusty> It's running right now on my mainnet and testnet test nodes. 13:59 < t-bast> roasbeef does that sound good to you? 13:59 < rusty> t-bast: ack. 13:59 < t-bast> rusty: great! 14:00 <+roasbeef> sgtm, it isn't very high on our prio list, would want to give conner a chance to sign off since he's been reviewing it though (haven't been following the PR too closely myself) 14:01 < t-bast> I think he signed off last time. I'll double-check the logs from last IRC meeting. If he did sign-off on it, let's merge it, otherwise let's wait for him to ACK. 14:01 < rusty> roasbeef: it's nice because it gives a way of querying node_ann as a side-effect. 14:01 < t-bast> exactly ;) 14:02 < rusty> t-bast: agreed. merge pending confirmation from bitconner 14:02 < t-bast> #action get conner's ACK and then merge 14:02 < t-bast> #topic 656 14:02 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/656 14:02 < t-bast> This is the feature bits in the payment invoice 14:03 < t-bast> It seems to me that we all agree on it and reproduced the test vectors, so should be ready to be merged? 14:03 < t-bast> There are small PR comments on wording though. 14:03 < rusty> t-bast: ack. The wording review is separate, since that "fail the payment" wording is used throughout. 14:04 < t-bast> ok, it all looks fine to me so I would merge it. roasbeef did you have a look at it? conner signed off last week. 14:04 < rusty> t-bast: I'd like to get it merged, since until it's merged we can't have compulsory bolt11 upgrades. 14:04 < t-bast> rusty: agreed 14:05 < t-bast> but roasbeef is conner's boss so maybe he doesn't trust conner's sign-off :D 14:05 <+roasbeef> nope haven't looked at it, but looks like johan has some comments on it 14:06 <+roasbeef> I think our PR is up to date tho 14:06 <+roasbeef> the one implementing in lnd 14:06 < t-bast> yeah sounds like conner reproduced the test vectors last time I checked 14:06 <+roasbeef> oh it's merged :o 14:06 < t-bast> oh really? 14:06 <+roasbeef> so looks to be g2g 14:06 < t-bast> so we should definitely merge the PR spec then ;) 14:06 <+roasbeef> lehdoit 14:06 < t-bast> #action rusty to merge 656 14:06 < rusty> Yay! 14:07 < t-bast> what do you want to discuss next? static_remote or AMP? 14:07 < rusty> I think we'll only have time for one, we're already over. static_remote? 14:07 < t-bast> static_remote is probably faster 14:07 < t-bast> roasbeef that ok for you? 14:08 <+roasbeef> static sgtm 14:08 < rusty> I have it implemented, with protocol tests. I think we're waiting on interoperation tests? 14:08 < t-bast> #topic 642 14:08 <+roasbeef> final on static is if to remove or not 14:08 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/642 14:08 < t-bast> we had one comment on static_remote 14:08 <+roasbeef> not remove the field imo as it makes parsing more context dependent 14:08 <+roasbeef> as you now need to know the feature bits advertised to parse it, as we still need to support both version s 14:08 < t-bast> Pierre-Marie mentioned on the mailing list that we could leverage this to do symmetric CSV delays 14:09 < t-bast> and brute-force csv values (but drawback is no way to use this in a bitcoin wallet directly, needs a dedicated tool) 14:09 <+roasbeef> final thing on mpp/amp seems to be a partial unification a la conner's last commnet: https://github.com/lightningnetwork/lightning-rfc/pull/658#issuecomment-525564887 14:09 <+roasbeef> leverage what? 14:09 < t-bast> leverage this opportunity to change the scripts 14:10 < t-bast> since we're changing the key derivation slightly 14:10 < rusty> t-bast: but there's going to be another chance to do that with dual-funding anyway... 14:10 < t-bast> rusty: is that coming soon? 14:10 < t-bast> soon-ish? 14:11 < rusty> t-bast: yes, niftynei is implementing and testing now. Lots of variables there to bikeshed though. 14:11 < t-bast> It felt like a good opportunity to fix this incentive mis-alignment 14:11 <+roasbeef> t-bast: it's been segmented, many weeks ago 14:12 <+roasbeef> doing csv here also makes the recoveyr case that this PR strengthens less compelling 14:12 < t-bast> that's great to hear, I'm curious to see the dual-funding proposal 14:12 <+roasbeef> would imagine many wouldn't enable dual-funding until the privacy leaks are patched, or mitigated somewhat 14:12 <+roasbeef> but stopic is static right now... 14:12 <+roasbeef> or we're ending/ 14:13 <+roasbeef> ? 14:13 < t-bast> So it sounds like both LL and CL would like to fix symmetric delays in another change right? And have static_remote not bother with that? 14:13 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 14:13 < rusty> roasbeef: shall we assign feature 12/13 to static? That's next one I think. 14:13 < rusty> t-bast: indeed, defer. BUt maybe indefinitely. 14:13 < t-bast> heh 14:13 < t-bast> ok, apart from that the current proposal for static_remote sounded good to us 14:14 < rusty> t-bast: OK, shall we assign proper feature bit so we can move to compat testing? 14:14 <+roasbeef> also, I think i'm gonna start having a call concurrently w/ this meeting that ppl can optionally jump on, let's no kid ourselves IRC is a horrble discussion medium for something like this and has slowed down progress since communication is always so ambgiuous and requires many clarifications 14:14 <+roasbeef> the change to channel reest is still unresovled rusty 14:14 <+roasbeef> see my last comment there? 14:14 <+roasbeef> 12/13 sgtm 14:14 < t-bast> rusty: sgtm 14:15 < rusty> roasbeef: you mean reconnect without the feature bit? 14:15 < t-bast> roasbeef: totally agree, and that brings me to another general point: do we want to have a spec meeting IRL during the LNConf? I think this would be invaluable. 14:15 < rusty> t-bast: ack! 14:16 < rusty> roasbeef: I'm confused as to what the unaddressed comment is? I hit reload.... 14:17 <+roasbeef> rusty: https://github.com/lightningnetwork/lightning-rfc/pull/642#discussion_r319622705 14:17 <+roasbeef> removing the field or not 14:18 < rusty> roasbeef: no way, that field was a huge underspecified mistake and must go. 14:18 <+roasbeef> it adds additional parsing complexity 14:19 <+roasbeef> as we we can't remove these legacy fields in a clean way 14:19 <+roasbeef> you'd just continue to write those 32 bytes, and everythign else follows and is uniform 14:19 <+roasbeef> vs needing to conditionally know the current set of feature bits, to know when to start reading/writing w/e future tlv extensions 14:20 < rusty> roasbeef: but this is true of the current parsing, since you need to know feature bits as to whether those fields are valid. 14:20 <+roasbeef> no today you just read them all 14:21 <+roasbeef> since we don't have optional fields 14:21 <+roasbeef> our parsing doesn't have any feature bit awareness as is 14:21 < rusty> And in the long run, it's neater. We have a *lot* of confusing logic to try to get that field correct, and deleting it is the entire point of this change. 14:21 <+roasbeef> deleting it adds _more_ code 14:21 < rusty> roasbeef: for now, sure. 14:21 <+roasbeef> yeh you don't need to udnerstand it, jsut to be able to read it out 14:21 <+roasbeef> understand as in the entire dlp protocol, this is just about making parsing uniform 14:22 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 14:23 < rusty> roasbeef: you already need to know the features so you know what to do if field is missing. You need to allow missing fields, UNLESS option_dataloss is negotiated. 14:23 <+roasbeef> if it sin't there, you know becuase the stream just terminates, if it is, you continue 14:23 <+roasbeef> if tlv data is added you need additional context to parse 14:23 <+roasbeef> we've never revmoed a field yet for a reason 14:23 < rusty> roasbeef: if it isn't there, you need to abort the channel, since they're cheating. 14:24 < rusty> In our case, we use different parse routines for dataloss_protect and for non-dataloss_protect. So this simply adds another. 14:25 < rusty> TBH I'd rather replace it with all zeroes than leave it intact. 14:25 <+roasbeef> yep which adds more code vs keeping it unfirm 14:25 <+roasbeef> yeh you can write all zeros even 14:26 < rusty> IN a few years' time that's gonna be really ugly. I guess we all get scars though, and I can blame you :) 14:27 < rusty> OK, so shall we say "reader MUST ignore my_current_per_commitment_point iff option_static_remotekey is negotiated"? 14:27 < rusty> That lets you put anything in there, wahtever is easiest. 14:28 < t-bast> Sounds like a good compromise 14:28 -!- hiroki_ [0e0c0742@M014012007066.v4.enabler.ne.jp] has quit [Remote host closed the connection] 14:28 <+roasbeef> sgtm 14:28 <+roasbeef> should be ready to do interop testing this week 14:28 < t-bast> great! 14:29 < cdecker> ack 14:29 < rusty> #action rusty to update #642 with new feature bit, restore (and ignore) my_current_per_commitment_point 14:29 < t-bast> rusty: do we need to connect with someone to reserve a time slot / meeting space during the LN Conf for a spec meeting? 14:29 < rusty> roasbeef: cool, I'll do that PR today, then update node. 14:29 < rusty> t-bast: I'll ask... 14:29 < t-bast> rusty: thx 14:30 < t-bast> Ok we've done a lot tonight, thanks all! Is there something else you'd like to discuss? 14:30 < cdecker> We can just subvert one of the panels ^^ 14:30 < t-bast> cdecker: or hide in a dark room and do secret stuff 14:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 14:32 < t-bast> ok sounds like we're good to go then 14:32 <+roasbeef> heading off now to smoke some meats, but would be nice to continue to make progress on the mpp/amp stuff in their respective PRs 14:32 < cdecker> Wait, panels aren't in dark secretive rooms? 14:32 < t-bast> I agree with roasbeef 14:32 < cdecker> roasbeef++ 14:33 < t-bast> #action make progress on the AMP and MPP PRs 14:33 < t-bast> #endmeeting 14:33 < lightningbot> Meeting ended Mon Sep 2 21:33:20 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 14:33 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html 14:33 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.txt 14:33 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.log.html 14:33 < t-bast> cdecker: sounds like this is going to be a lot of fun 14:34 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 14:35 < cdecker> Thanks t-bast for chairing ^^ 14:35 < cdecker> And thanks everybody for making this a productive meeting ^^ 14:35 < t-bast> My pleasure, thanks all for the work done! 14:35 < t-bast> Lots of cool stuff coming soon, the road is paved for AMP/MPP now 14:36 < t-bast> Good morning/afternoon/night everyone 14:36 -!- t-bast [~t-bast@2a01:e34:ec2c:260:f0b4:ac3b:9c3f:6386] has quit [Quit: Leaving] 14:40 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds] 14:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 14:52 -!- reallll is now known as belcher 15:13 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:1967:8e38:f46a:3c52] has quit [] 15:32 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Ping timeout: 245 seconds] 15:41 -!- shesek [~shesek@141.226.218.61] has joined #lightning-dev 15:41 -!- shesek [~shesek@141.226.218.61] has quit [Changing host] 15:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 15:45 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 16:07 -!- kam270 [~kam270@183.182.104.69] has joined #lightning-dev 16:11 -!- _Sam-- [~greybits@unaffiliated/greybits] has quit [Quit: Leaving] 16:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 16:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 16:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 17:24 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-iawfoivkqcotnszu] has quit [Write error: Connection reset by peer] 17:24 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-lsexfshlqnefvfrm] has quit [Remote host closed the connection] 17:24 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-pcubfumteriswxhc] has quit [Write error: Connection reset by peer] 17:24 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-higpbvwbhieguaam] has quit [Read error: Connection reset by peer] 17:24 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-xyjavuxaplvunjsz] has quit [Remote host closed the connection] 17:35 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-jldzwmdqcynkpxpd] has joined #lightning-dev 17:40 -!- mdunnio [~mdunnio@208.59.170.5] has joined #lightning-dev 17:45 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #lightning-dev 17:50 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 250 seconds] 17:55 -!- Relaed [~yuan.yao@49.80.198.104.bc.googleusercontent.com] has left #lightning-dev [] 17:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 18:11 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 260 seconds] 18:14 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 258 seconds] 18:14 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Read error: Connection reset by peer] 18:28 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-bkomdyuoeqxxshvc] has joined #lightning-dev 18:28 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-akbppcwlwevhyflc] has joined #lightning-dev 18:28 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-rkneqrjmlanzakpu] has joined #lightning-dev 18:28 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-lcxytzskzardsomp] has joined #lightning-dev 18:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 19:15 -!- adiabat [~adiabat@63.209.32.102] has joined #lightning-dev 19:16 -!- adiabat [~adiabat@63.209.32.102] has left #lightning-dev [] 19:38 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 19:38 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 19:40 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 19:40 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 19:45 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 19:45 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 19:48 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 19:49 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 19:54 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has joined #lightning-dev 19:56 -!- noxx [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 20:03 -!- noxx_ [~noxx@p200300E6172A1900D06BEC8C3A6B0C9C.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 20:20 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 20:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:28 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 252 seconds] 20:34 -!- noxx [~noxx@p200300E6172A1900D071A4AC4ECBBB1D.dip0.t-ipconnect.de] has joined #lightning-dev 20:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 20:44 -!- jimmy_chien_feng [~jimmy_lo@122.147.213.16] has joined #lightning-dev 20:48 < jimmy_chien_feng> What is evely-typed message? I see this in lightning message format. 20:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 21:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 21:06 < rusty> jimmy_chien_feng: every message has a 16-bit type. If you don't know what a msg is, the rule is simple: it's OK to be odd. So if you see an even msg you don't understand, it's fatal. 21:29 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 244 seconds] 21:35 -!- kam270_ [~kam270@183.182.104.69] has joined #lightning-dev 21:37 -!- kam270 [~kam270@183.182.104.69] has quit [Ping timeout: 245 seconds] 21:42 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev 21:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 23:26 < jimmy_chien_feng> rusty: you mean if a message you don't know which is an odd number, like 1, 3, 5, etc., then it is ok. But if the number is even, 0, 2, 4, etc., then it is fatal. Right? 23:26 < rusty> jimmy_chien_feng: exactly! 23:27 < jimmy_chien_feng> Where does the rule come from? 23:27 < jimmy_chien_feng> rusty: do you know? 23:27 < rusty> https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#lightning-message-format 23:28 < jimmy_chien_feng> rusty: I mean the "it's ok to be odd". Or only lightning network uses this rule? 23:28 < rusty> jimmy_chien_feng: it's lightning-specific, yes. https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md#its-ok-to-be-odd\ 23:29 < jimmy_chien_feng> rusty: thank you 23:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 23:57 -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 23:59 -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] --- Log closed Tue Sep 03 00:00:59 2019