--- Log opened Mon Jan 21 00:00:26 2019 00:29 -!- foureighttwonine [~foureight@175.158.216.180] has joined #lightning-dev 00:31 -!- foureighttwonine [~foureight@175.158.216.180] has quit [Read error: Connection reset by peer] 00:33 -!- bitonic-cjp [~bitonic-c@a80-100-203-151.adsl.xs4all.nl] has joined #lightning-dev 00:52 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 00:55 -!- foureighttwonine [~foureight@185.103.96.147] has joined #lightning-dev 01:07 -!- foureighttwonine [~foureight@185.103.96.147] has quit [Ping timeout: 250 seconds] 01:11 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev 01:16 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:19 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:28 -!- Amperture [~amp@24.136.5.183] has quit [Ping timeout: 268 seconds] 01:40 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:40 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:41 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:41 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:56 -!- ratonlaveur [~ratonlave@192.230.35.138] has quit [Ping timeout: 268 seconds] 02:03 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 02:04 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 268 seconds] 02:22 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 02:27 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 02:53 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 02:53 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 02:58 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 250 seconds] 03:11 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 03:11 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 03:15 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 03:16 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 03:20 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 03:21 -!- DeanWeen is now known as Dean_Guss 03:29 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds] 03:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 03:35 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 03:39 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 246 seconds] 03:40 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 03:44 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 04:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 04:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 04:07 < cdecker> I prepared today's meeting Agend here: http://bit.ly/ln-agenda-201902 04:08 < cdecker> It's open for anyone to comment on, and I will apply comments and changes as they come in. Please add any discussion point that is not on the agenda before the meeting. 04:08 < cdecker> Rusty will not be joining today, so all participants should have a few hours to go through the list before the meeting 04:32 < cdecker> Ping: AmikoPay bitconner BlueMatt cdecker Chris kanzure lightningbot niftynei ott0disk roasbeef rusty sstone :-) 04:38 -!- riclas [riclas@148.63.37.111] has joined #lightning-dev 04:47 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #lightning-dev 05:19 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 05:23 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 245 seconds] 05:59 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev 06:08 < kanzure> pong, thank you 06:44 < cdecker> No problem, I changed the format of the agenda a bit so it is easier to identify the PRs, hope that helps keeping an overview 07:08 -!- sstone [~sstone@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev 07:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 07:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Client Quit] 07:31 < BlueMatt> cdecker: oh, thanks for the ping 07:31 < BlueMatt> note its a holiday in the us today 07:31 -!- kexkey [~kexkey@173.209.48.131] has joined #lightning-dev 07:53 -!- Amperture [~amp@24.136.5.183] has joined #lightning-dev 08:16 < cdecker> Right, we'll have a small meeting, probably quite a few people missing 08:17 < cdecker> Any decision you'd like to have deferred for the next meeting, should you not be joining today BlueMatt? 08:25 < BlueMatt> cdecker: I commented on everything I care about, only thing I note is the discussion around flapping channels etc, but folks know my opinion there (its useful data, dont just kill it, mobile clients probably want a route subset anyway) 08:26 < BlueMatt> specifically, its useful *to provide a useful route subset*, which is what mobile clients want, so I worry it will end up hurting mobile clients in the long term for a short-term bandwidth/startup-time savings 08:27 -!- bitonic-cjp [~bitonic-c@a80-100-203-151.adsl.xs4all.nl] has quit [Quit: Leaving] 08:28 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 08:34 -!- Sebartsebach_ [95c91d0d@gateway/web/freenode/ip.149.201.29.13] has joined #lightning-dev 08:40 -!- Sebartsebach_ [95c91d0d@gateway/web/freenode/ip.149.201.29.13] has quit [Quit: Page closed] 08:57 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 08:58 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 09:02 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 272 seconds] 09:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 09:18 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 09:46 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev 09:47 < Chris_Stewart_5> In this graphic shouldn't there be 'update_fullfill_htlc' messages between 'commitment_signed' and 'revoke_and_ack'? 09:47 < Chris_Stewart_5> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation 09:59 < ysangkok> Chris_Stewart_5: normally there would never be anything between commitment_signed and revoke_and_ack, why wouldn't you ack as soon as you received a commitment? 10:01 < ysangkok> Chris_Stewart_5: the diagram is just displaying the addition of htlcs, when you have both sides adding htlcs at the same time 10:02 < Chris_Stewart_5> ysangkok: Yes, but the diagram doesn't show fulfilling of the htlcs. The text says that "until the corresponding HTLC is irrevocably committed in both sides' commitment transaction you must not send an update_fullfill_htlc" -- so that seems to be after the revoke_and_ack correct? 10:03 -!- araspitzu [~araspitzu@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Remote host closed the connection] 10:04 < ysangkok> Chris_Stewart_5: well of course the diagram could be bigger, but it is just meant to illustrate how you have one extra commitment in the case of a race such as this. 10:05 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection] 10:05 < Chris_Stewart_5> ysangkok: Understood. Thanks! 10:05 < ysangkok> let's say you are adding a commitment. the commitment will be committed in the opposite sides ctx first, and then your own 10:06 < ysangkok> so in this diagram , the third htlcs only becomes committed to in node B because of message 9 10:07 < ysangkok> so you wouldn't be able to fulfill it before that time 10:07 < ysangkok> ah shucks, i meant "let's say you are adding an htlc" 10:09 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 10:12 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 244 seconds] 10:14 -!- sstone [~sstone@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving] 10:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 10:28 -!- Tralfaz [~none@178.128.106.205] has joined #lightning-dev 10:28 -!- Tralfaz [~none@178.128.106.205] has quit [Remote host closed the connection] 10:30 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has joined #lightning-dev 10:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 10:38 < Chris_Stewart_5> ysangkok: it wouldn't be message 6? 10:42 < ysangkok> Chris_Stewart_5: i don't think so. message 4 would not include the third htlc, since it has not locked into the receiver (A) yet 10:43 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #lightning-dev 10:47 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 10:52 < Chris_Stewart_5> So looking at this "the node only adds those updates to its own commitment transaction when the remote node acknowledges it has applied them via revoke_and_ack." 10:53 < Chris_Stewart_5> it appears that message 7 is when A would "acknowledge" that it has applied message 3? 10:53 < Chris_Stewart_5> so that is when B would add message 3 to it's own ctx? 10:58 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has joined #lightning-dev 10:59 < cdecker> Ok, shall we start the meeting? 10:59 < cdecker> #startmeeting 10:59 < lightningbot> Meeting started Mon Jan 21 18:59:45 2019 UTC. The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:59 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00 < sstone> ok 11:00 < cdecker> #info Meeting agenda can be found here: http://bit.ly/ln-agenda-201902 11:01 < cdecker> Ping AmikoPay_CJP bitconner BlueMatt cdecker Chris_Stewart_5 kanzure niftynei ott0disk roasbeef rusty sstone 11:01 < kanzure> hi. 11:01 < cdecker> Am I missing someone that ought to be pinged? 11:01 < lndbot> hi all 11:02 < cdecker> Hi Johanth :-) 11:02 < BlueMatt> #lightning-dev roasbeef aj BlueMatt cdecker jimpo niftynei rpickhardt I'm sure I missed others... 11:02 < bitconner> hi everyone :) 11:04 < cdecker> Heia, shall we start with #491 and by association #539? 11:04 < cdecker> #topic PR #491: BOLT #2: order htlc_signatures by BIP69 + increasing CLTV. 11:06 < BlueMatt> looks like it needs a rebase, rusty (who is mia today) indicated its waiting on a second implementation, and also we should inline BIP 69 11:06 < BlueMatt> not sure there's anything to talk about except "go implement, author should rebase" 11:06 < cdecker> Right, rebase is trivial, I just checked, but didn't push just yet 11:06 -!- notniftynei [~notniftyn@172.56.22.165] has joined #lightning-dev 11:06 < cdecker> It's sort of the last 1.0 PR it seems, after this we can tag 11:07 < sstone> we also implemented it and also added test vectors in #539 11:07 < BlueMatt> cdecker: can we please inline bip69 before tagging? bip69 is so massively underspecified.... 11:07 < cdecker> Excellent, so not only do we have a second implementation for #491, we also have the a test vector. 11:08 < cdecker> Ok, BlueMatt do you volunteer to inline BIP69 before we tag then? 11:08 < BlueMatt> also it just says "lexicographical ordering" 11:08 < BlueMatt> sure, I can do that 11:08 < BlueMatt> "lexicographical" is undefined as well... 11:08 < cdecker> #action BlueMatt to inline BIP69 into the BOLT to remove ambiguities 11:09 < cdecker> And I assume everybody is happy merging #491 given the second implementation? 11:09 < BlueMatt> yea, its straightforward enough 11:09 -!- enemabandit [~enemaband@16.77.54.77.rev.vodafone.pt] has joined #lightning-dev 11:09 < BlueMatt> even if it doesnt resolve all ambiguities 11:10 < sstone> you mean after test vectors have been verified ? 11:10 < cdecker> Any objections from other implementations? 11:10 < cdecker> sstone: I was going to propose that #539 needs to be verified and then merged, but sure we can bundle the two together 11:10 < bitconner> yep i'm happy with it, also nice to have the test vector! 11:10 < lndbot> lgtm, @bitconner you looked into 491? 11:11 < sstone> no I agree with you verify first then merge 11:11 < lndbot> nice 11:11 < bitconner> we should make moves and implementing that in lnd 11:11 < cdecker> sstone: so merge #491, then verify #539 and then merge #539? 11:11 < bitconner> but in having discussed the changes at length prior, i think we agree 491 is good 11:11 < sstone> yes 11:12 < cdecker> #action cdecker to merge #491 11:12 -!- laurentmt1 [~Thunderbi@176.158.157.202] has joined #lightning-dev 11:12 < cdecker> Good so we will keep #539 open for verification and then discuss that during the next meeting 11:13 < bitconner> excellent, sgtm 11:13 < cdecker> #action The test vectors in #539 need to be verified independently. Decision is to be deferred until the next meeting 11:13 < cdecker> #topic PR #500: BOLT 7: Add note for 'htlc_minimum_msat' being static 11:14 < cdecker> PR #500 opened the pandoras box about some value in the channel updates being static or not. 11:14 <+roasbeef> the name of the message is channel_update, it lets one update attributes of the channel useful when routing 11:15 -!- notniftynei [~notniftyn@172.56.22.165] has quit [Remote host closed the connection] 11:15 <+roasbeef> there're link level values which are static, but hte routing level values can be modified as long as they're within the constraints of the link level values 11:15 < cdecker> We were mostly happy with moving that discussion to a separate issue (#540) since the changes were not introducing the "static" wording, just change it slightly 11:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds] 11:16 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Ping timeout: 268 seconds] 11:16 -!- laurentmt1 [~Thunderbi@176.158.157.202] has quit [Ping timeout: 245 seconds] 11:17 < cdecker> Shall we move the discussion to #540 and merge #500? I'm also happy if someone just opens a PR to remove the static wording btw 11:17 < BlueMatt> roasbeef: was the one with the objection 11:17 <+roasbeef> my self would rather just fix the wording and not take two hops to get there 11:17 <+roasbeef> i can make a PR outlining things a bit more 11:18 < cdecker> Ok, do you want to amend the PR (add another commit) that fixes that wording? 11:18 < BlueMatt> roasbeef: There will almost certainly be some disagreement about allowing nodes to set an htlc_minimum_msat below the remote peer's defined level 11:18 -!- YSqTU2XbB [~smuxi@5.170.48.41] has joined #lightning-dev 11:18 < cdecker> (It'll end up being the same in the commit history, whether we open a new PR or amend the existing one) 11:19 < lndbot> Bluematt: I believe that can be done today? 11:20 < cdecker> Ok, I'll let roasbeef decide whether to amend the PR or open a new one 11:20 < cdecker> #action roasbeef to amend PR #500 to remove the static definition or open a new PR to do that 11:20 < cdecker> roasbeef: is that ok with you? 11:21 <+roasbeef> sgtm 11:21 < cdecker> Excellent, onwards then 11:21 < cdecker> #topic PR #519: BOLT 7: add extended channel queries 11:21 < cdecker> We had some back and forth about this, and I think I'm the only one complaining about this. 11:22 < cdecker> To give some color to my objection: I absolutely loathe the hacked up gossip protocol that we have right now, and I don't want it to have yet another incremental change that may make things worse. 11:22 < sstone> I think that with a few changes it can be made compatible with current impls without adding new messages (as is the case currently) 11:22 <+roasbeef> totally 11:23 <+roasbeef> i don't think client sshould be trying to "sync all the channel updates" it's super wasteful, and someone can always spam you if you want to fetch each update, instead you can prioritize the channels you're likely to take given past payment history, and upon failure you get the channel update anyway 11:23 < BlueMatt> yea, I'm still kinda hoping all the current gossip query stuff dies and we add a new feature and all move on 11:23 < cdecker> After discussing this with sstone, I think we found a middle ground by amending the existing short_id message with an optional field that adds the extra information, in a backwards compatible way 11:23 <+roasbeef> which message? 11:24 < sstone> Basically all the existing channel queries 11:24 < lndbot> Will this still be relevant after the move to INV? 11:24 < cdecker> query_short_channel_ids_extended can be translated into query_short_channel_ids with the extra info appended as optional field, that was my proposal 11:24 <+roasbeef> this is for cartch up, taht would be once synced 11:25 < cdecker> That way we don't need a feature flag, we don't have new messages and all just keeps working 11:25 <+roasbeef> ah rather than adding a new message, that seems nice 11:25 < sstone> If the encoding type is interpreted as a bit field then yes it becomes easy to add optional data 11:25 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 11:25 < cdecker> For the long term we might want to look into minisketch and IBLT very soon, that way we can throw the existing protocol out of the window 11:26 < bitconner> specifically, which additional data from the proposal would be carried over? 11:26 < cdecker> sstone: we can also just add a new flag field after the ids which tells us which other optional fields are there 11:27 < cdecker> The proposal proposes timestamp and checksum for each channel id that is being transferred iirc 11:27 < sstone> yes but this works is everyone keeps the extra data that they're received (I think it's fairly easy for c-lightning) 11:27 < bitconner> gotcha, my onee concern in using a checksum is that it seems to be overfitting to the existing message fields 11:28 <+roasbeef> which is how optional fields work in generael atm sstone, but then again should we tack this on or wait for our overloads from the TLV clan 11:28 < cdecker> sstone: how so? I think it is trivial to reconstruct checksums and timestamps from the local view, isn't it? 11:29 < cdecker> roasbeef: good point, we also need to discuss TLV, since that's blocking some more things in the queue, but let's defer that to after the PRs 11:30 < sstone> cdecker: sorry I meant keep the extra data at the end of the message you've received (what roasbeef said) 11:30 < bitconner> presumably, we will need to add more fields in the future that are dynamic. when that happens, do we define a new checksum field for every possible optional field combination? 11:30 -!- laurentmt [~Thunderbi@62.112.9.237] has joined #lightning-dev 11:31 < cdecker> Wait, isn't this just query_short_channel_ids which isn't getting gossiped anyway? 11:31 < sstone> My view is that for now it's a simple addition to a feature that no-one has implemented but us, and which yields massive gains 11:31 < bitconner> just seems a little brittle for forwards compatibility 11:32 < cdecker> bitconner: my proposal was to just blank signature and timestamp and otherwise checksum everything that is covered by the signature, since that's an atomic transfer unit anyway 11:32 < cdecker> I think we all have implemented the gossip query mechanism 11:32 <+roasbeef> yeh 11:32 <+roasbeef> i think he means this addition w/ timestamps 11:33 < cdecker> Ah, ok, sorry for misreading it 11:33 <+roasbeef> sstone: eclair nodes in the wild will serve and signal this? 11:33 < sstone> yes I don't think anyone has toyed with it so changing it does not impact others 11:34 < sstone> roasbeef: no just ours for now 11:34 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has quit [Ping timeout: 268 seconds] 11:34 <+roasbeef> as in the main aqinc node? 11:34 <+roasbeef> acinq* 11:34 < cdecker> Ok, I misunderstood you in that case, I thought you were making a case for the current draft to be kept, instead you are saying it's ok to change that since it's eclair only? 11:34 < sstone> roasbeef: yes on mainnet/testnet 11:35 < cdecker> sstone: would you be ok with going through one more iteration on the design with us then? 11:35 < sstone> cdecker: yes, and I was planning to change it to use optional fields instead of new messages to make it more acceptable 11:36 < cdecker> Excellent, thanks ^^ 11:36 < cdecker> #action sstone to rework #519 with the feedback on the PR 11:37 < cdecker> Making good progress :-) 11:37 < sstone> I also think that the underlying problem will also be an issue for INV based solutions and minisketch/IBLT 11:37 < cdecker> #topic PR #538: BOLT 4: Report outgoing HTLC values when appropriate 11:38 <+roasbeef> sstone: not if you give up on trying to sync every update from every channel on the network... 11:38 <+roasbeef> mo bandwidth, mo queries, mo problems 11:39 <+roasbeef> for #538, perhaps we should send both? 11:41 < sstone> roasbeef: why both ? 11:41 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection] 11:42 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #lightning-dev 11:42 <+roasbeef> to maintain backwards compat 11:42 < bitconner> seems like the second change is just a clarification, while the first is breaking wrt how routers interpret failures? 11:43 < BlueMatt> no, look at the line above the second change 11:43 <+roasbeef> either way, you get the latest channel_update, if it was a msitake on the sender (logic wise), then this doesn't really help, but if it was just a statel channel_update, then you get the latest one 11:43 < BlueMatt> cltv_expiry clearly implies the incoming 11:43 < bitconner> ah you're right, thanks BlueMatt 11:43 < sstone> bitconner: I'm not following you sorry how does it break routers ? 11:44 < BlueMatt> roasbeef: we cant just "send both" cause the channel_update goes second. I mean we could append it *after* the channel_update 11:44 <+roasbeef> yeh append, old nodes just discard the rest, new nodes know to keep reading 11:45 < cdecker> The phrasing used above the second change is in contradiction to the sentence above (cltv_expiry is applicable on the incoming side, the outgoing side is referred to as outgoing_cltv_value) 11:45 <+roasbeef> but then it's implicit that way rather than explicit 11:45 < bitconner> sstone, existing routers will be expecting the incoming value, returning the outgoing means now means they will apply this to the wrong channel from their PoV 11:45 -!- shesek [~shesek@141.226.144.195] has joined #lightning-dev 11:46 -!- shesek [~shesek@141.226.144.195] has quit [Changing host] 11:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 11:46 < bitconner> indeed appending seems like a good option 11:46 < cdecker> Re: routers not understanding the changed payload: this does not apply since the payload is onion wrapped and opaque to the routing nodes 11:47 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 246 seconds] 11:47 < bitconner> cdecker, i'm referring to the sender's router in particular 11:47 < cdecker> This is only an issue if the sender tries to be smart and do something based on the value 11:47 <+roasbeef> well depends on which channel_update they inclose I guess (respond to myself above), the incoming or outgoing 11:47 < cdecker> Ok, wasn't aware you were calling that one router as well :-) 11:47 < bitconner> cdecker, haha i can see why that's confusing, sorry :) 11:48 < sstone> the channel_update does not change, just the value that is reported as a hint. Are you also using it to recompute a new route ? 11:48 < cdecker> No prob, thanks for the clarification bitconner 11:49 <+roasbeef> sstone: use the channel_update? yeh 11:49 < sstone> the values 11:49 <+roasbeef> atm no, are y'all? 11:49 <+roasbeef> if not, then this is just for better logs? 11:49 < lndbot> does the "hint" actually give you anything the channel update doesn't? 11:50 < sstone> no so I don't see what it breaks ? 11:50 <+roasbeef> it gives you the context 11:50 <+roasbeef> the spec ;) 11:51 < cdecker> Ok, it seems more discussion is needed on this one? 11:51 <+roasbeef> appending lets ppl do clever stuff with that value and keeps things the same for existing nodes, q there is how to signal it or if it shuold just be appended 11:51 < sstone> yes but since noone is using the value it's cleaner to change now 11:51 < cdecker> Shall we defer to the tracker again? 11:53 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 11:53 < cdecker> Ok, I take it we need to do some iterations on this on the list/tracker then 11:53 <+roasbeef> lol checked and we actually send the outgoing atm :p 11:53 < cdecker> Let's move on to #544, since #539 already has the check-and-commit decision above 11:54 < sstone> roasbeef: so we can merge #538 ? 11:54 < sstone> :) 11:54 < lndbot> lol 11:54 < cdecker> roasbeef: I'll let you have the last word before switching topics :-) 11:55 <+roasbeef> yeh since we do it already no contest on my end lol 11:55 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has joined #lightning-dev 11:55 < cdecker> Ok, any objections to merging #538? 11:55 < bitconner> nice discovery lol, merge away! 11:55 < sstone> yes 11:56 * cdecker looks into BlueMatt's direction 11:56 < BlueMatt> nah, if its confused already might as well clarify 11:56 < cdecker> So your verdict is merge or !merge? 11:56 < BlueMatt> merge is fine with me 11:57 < cdecker> #action sstone to merge #538 11:57 < cdecker> #topic PR #544: BOLT 4: remove incorrect_payment_amount altogether. 11:57 < cdecker> Fewer error message = less information leakage I guess :-) 11:58 < BlueMatt> well we already "removed it" this just removes it 11:58 < BlueMatt> and, yea, the second hunk there was just missed in the first removal 11:58 < cdecker> Ok, so any objections to merging it PR #544? 11:58 < sstone> no 11:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:58 < cdecker> #action cdecker to merge #544 11:59 < bitconner> lgtm 11:59 < cdecker> We're almost at time, are we at risk of losing quorum, or does everybody agree to stick around a few more minutes? 11:59 < BlueMatt> hey-o, there's a rusty! 11:59 * BlueMatt is hungry, but if we move quick I can delay :p 12:00 < sstone> I can stick around 12:00 < bitconner> same 12:00 < bitconner> can stick around for a few minutes 12:00 < cdecker> Excellent 12:00 < cdecker> Moving on 12:00 < cdecker> #topic PR #545: BOLT 4: include `channel_update`'s message type 12:01 < cdecker> We discussed this one before, and decided to drop the message type since there were 2 impls already doing it that way, but it seems we had a misunderstnading there? 12:02 <+roasbeef> imo we already know it's a channel_update so no need to add the type, length alone can be enough to distinguish that there're extra fields there (optional channel_update stuff, or append stuff to the error message like was discussed above) 12:02 < cdecker> c-lightning currently supports both ways 12:02 <+roasbeef> yeh we parse both ways 12:02 <+roasbeef> but write w/o the type 12:03 < lndbot> Would including the type leave room for another message at a later time? 12:03 <+roasbeef> another message? 12:03 < lndbot> If something better than channel update comes along :p 12:03 * BlueMatt prefers without, only reason to define it *with* imo would be if most folks already serialize with 12:03 < cdecker> Same with us, I kind of like the type with type prefix since it allows us to reuse the parsing without any changes, cropping means we have to reallocate and copy it over 12:04 <+roasbeef> we still re-use the parsing logic, as it's separated into the brontide unpacking then the inner message, inner message knows what it is, so it doesn't need a type hint 12:04 < sstone> it's much cleaner to include the type, and saving one byte here is not really useful (see I don't always obsess over bandwidth :)) 12:05 < BlueMatt> then we need to also specify what to do if the type is wrong 12:05 < lndbot> Let's say we define channel update v2 at some point, how would you signal that without the type? 12:05 < cdecker> It's 2 bytes, but that shouldn't matter 12:05 < BlueMatt> currently it says you have to send a channel_update, but we need to clarify that it means you have to send a channel update *right now*, and should ignore other type messages 12:05 < BlueMatt> johanth's point sways me enough to not care 12:06 < BlueMatt> but would need clarification on the recv end 12:06 -!- ratonlaveur [~ratonlave@67.215.14.198] has joined #lightning-dev 12:06 <+roasbeef> if we want to swap out what's ecnlosed therein the future, we'd need a diff error msg 12:06 < BlueMatt> not if we include the type... 12:07 < cdecker> Ok, am I right in counting it this way: opposed=[roasbeef], abstained=[BlueMatt], infavor=[cdecker,sstone,johanth]? 12:07 < bitconner> i'm in favor of having the type byte, gives us more flexibility 12:07 < BlueMatt> I'm opposed to patch as-is 12:07 < BlueMatt> I'm fine with adding type, just need to clarify that we have to ignore other messages right now 12:07 < BlueMatt> so that we can swap it out in the future if we want 12:08 < sstone> we can update the PR to reflect that 12:08 < cdecker> Ok, makes sense 12:08 < lndbot> i dont see any cons in adding it.. other than that we have to rewrite our serialization slightly... :P 12:08 < cdecker> roasbeef: would you like to have a more in-depth discussion about this on the tracker? 12:09 <+roasbeef> sure 12:09 < cdecker> johanth: I'll write the patch for you :-) 12:09 < BlueMatt> yea, gotta rewrite my shit for it too 12:09 < BlueMatt> cdecker: ewww. go. 12:09 < cdecker> Ok, everybody happy with amending PR and moving the discussion on the tracker 12:10 < BlueMatt> sounds like it, lets move forward 12:10 < cdecker> #action sstone to rephrase the PR to include what to do when type is unknown, everybody to discuss lively on the PR 12:10 < cdecker> #topic PR #546: Clarify behavior of id field in update_add_htlc 12:10 < cdecker> This one should be easy, I had no idea one could misread it, but here we are 12:10 < lndbot> cdecker: I'll remember 12:11 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has quit [Remote host closed the connection] 12:11 * cdecker starts frantically reading go code 12:11 < BlueMatt> yea, I'm not actually sure that the async nature of the protocol works out if you misread the id field, but, either way, obvious ACK 12:11 < cdecker> I think the last few are mostly spelling mistakes so that should go quick 12:12 < cdecker> Any opposition to merging it, other than making the document very verbose? 12:12 <+roasbeef> above says it shuld icnrease after each offer, but can't hurt to specify i guess 12:12 < cdecker> #action cdecker to merge PR #546 12:12 < cdecker> Done :-) 12:12 < bitconner> ack, can't hurt to be more specific :) 12:12 < cdecker> #topic PR #547: Keep HMAC case consistent 12:13 < cdecker> I think this should be deferred since as sstone points out it makes it even less consistent :-) 12:13 < BlueMatt> 547 ack, shed's not my favorite color, but thats ok, I can live with eyesores :p 12:13 <+roasbeef> should be upper 12:13 < BlueMatt> or that, whatever 12:13 <+roasbeef> hash based message authentication code 12:13 < BlueMatt> yea, my favorite color is upper case 12:14 < cdecker> Mine too, we have soooooooooo much in common :-) 12:14 <+roasbeef> https://tools.ietf.org/html/rfc2104 12:14 < sstone> yes but all other message fields are lowercase ? (very weak objection) 12:14 < cdecker> Ok, let's note that on the PR and move on then 12:14 < cdecker> #action BlueMatt to comment about the shed color not being uppercase 12:15 < cdecker> #topic PR #548: Align offered and received HTLC scripts similarly 12:15 < cdecker> Is this just a spelling change? IMHO it is, so single ACK is sufficient :-) 12:15 <+roasbeef> easy yeh, it' strivial 12:15 < bitconner> 548 ack 12:15 < BlueMatt> next 12:16 < cdecker> #action cdecker to merge #548 12:16 < lndbot> strivial it is :) 12:16 < cdecker> #topic PR #550: dpl: concretely define `my_current_per_commitment_point` 12:16 -lightningrfc:#lightning-dev- [lightning-rfc] sstone closed pull request #538: BOLT 4: Report outgoing HTLC values when appropriate (master...bolt4-outgoing-values) https://git.io/fh3xn 12:16 < cdecker> Can you guys confirm that this is the correct interpretation? 12:17 < cdecker> The sending node: 12:18 < cdecker> - MUST set `my_current_per_commitment_point` to its commitment point for 12:18 < cdecker> the last signed commitment it received from its channel peer. 12:18 < cdecker>  12:18 <+roasbeef> it shuld be the latest point used for the last commitment for the other peer, so the one that's unrevoked 12:18 <+roasbeef> as you need that to sweep your non-delay funds on chain if the other party broadcasts 12:19 < rusty> roasbeef: yes, it should correspond to the commitment tx you're going to broadcast. 12:20 < cdecker> Do we need more time to verify the correctness here? 12:20 <+roasbeef> i think wording has right intent, but can be specified further 12:20 < cdecker> Ok, would you volunteer to improve the wording? That'd be a great help 12:20 <+roasbeef> "point used in last commitment signed for the peer" 12:20 <+roasbeef> ok 12:21 < rusty> I think everyone assumes we immediately revoke previous so there's no case where you have two possible commitment txs. 12:21 < cdecker> #action roasbeef to help with the wording of the PR to remove any remaining uncertainty 12:21 < cdecker> #topic PR #552: Demand revoke_and_ack before more updates 12:21 <+roasbeef> there is before you revoke the previous ;) 12:22 < BlueMatt> another one that I didn't know you could misread, but, yea, nodes that dont wait for an RAA and get a CS are busted 12:22 < cdecker> This seems to have gotten quite a bit of feedback during the last few hours so I propose we should defer it, especially since this tries to address #526 which was opened by nayuta-co which is not currently present 12:22 <+roasbeef> they can't do that even, you can't sign again before you get a revoke 12:22 < BlueMatt> yea, I mean you *could* but dont, cause you'll break everything 12:22 <+roasbeef> they're leaning towards the prior multiple unrvoked 12:23 <+roasbeef> but you can't do that w/o making a "revocation window" so pre-send 12:23 * BlueMatt -> food 12:23 <+roasbeef> yeh i think defer, they seem to be musing about extending the design in the linked issue 12:23 * cdecker -> soon food 12:24 < cdecker> #action Defer #552 to the tracker 12:24 < cdecker> Ok, so that's the PRs done 12:24 < cdecker> I'd just like to talk 2 minutes about the TLV proposal for 1.1 12:25 * BlueMatt ventures out into -10 C weather to get food, see y'all 12:25 < cdecker> roasbeef: you guys are doing the spontaneous payment thing already right? That was/is blocked by the TLV proposal, so could you share what your current method is? 12:25 < cdecker> See you BlueMatt, and thanks for sticking with us for overtiem 12:25 <+roasbeef> method is that the TLV is a diff packet type, as there're cases where yuo can't fit what you want into 1 or two hops due to teh overhead of the tlv 12:25 <+roasbeef> as that also pushes the interpretation of what the tlv is above 12:26 <+roasbeef> so the upper layer sees "ok i'll try to parse kv's from this blob" 12:26 < cdecker> Right, but that means you have a working multi-onion-layer implementation and at least an idea on how TLV should look like right? 12:26 < rusty> cdecker: no,, they fit into one per_hop IIUC. 12:26 <+roasbeef> other diff thign than ML is realm is left in place, instead there's a "more bit + length" byte and a type byte 12:26 <+roasbeef> this ignores tlv and leaves it to the upper layer to define that it looks like 12:26 < bitconner> cdecker, i've started working on a tlv impl/proposal separately 12:26 <+roasbeef> it just says "boss says this is a tlv, figure it out" 12:26 < cdecker> Oh, ok, was hoping you had a prototype that you could share 12:27 <+roasbeef> conner has some tlv code 12:27 < bitconner> i do have a tlv prototype 12:27 <+roasbeef> here's the onion PR https://github.com/lightningnetwork/lightning-onion/pull/31 12:27 < bitconner> it's really not bad at all 12:27 < cdecker> bitconner: awesome, would love to see that so I can start working on rendez-vous as well 12:27 -!- hiroki [7c9aaff8@gateway/web/freenode/ip.124.154.175.248] has joined #lightning-dev 12:27 < rusty> Yeah, let's do it properly... lower 4 bits == extra hops. upper 4 bits = WTF (like now). 12:27 <+roasbeef> most of it is packing the bytes into diff hops, then unwrapping multiple hops on the receiver 12:27 <+roasbeef> rusty: bits of what? 12:27 < rusty> roasbeef: realm byte. 12:27 < cdecker> Ok, I'll review lightning-onion#31 then 12:27 < rusty> "byte formally known as the realm byte" 12:28 <+roasbeef> that PR does: first padding bytes is (1 bit more, 7 bits length), second padding byte is type 12:28 < bitconner> cdecker, will do! i can send out a link with the WIP branch later today 12:28 < cdecker> Awesome thanks 12:28 <+roasbeef> that's only for the "pivot hop" (the first hop no extra hops), full hops just have the (1 bit more, 7 bits length) 12:28 < cdecker> That's my mind about TLV put at ease :-) 12:28 < cdecker> #topic TLV format and multi-hop onion 12:28 <+roasbeef> the tlv format might be diff of wire vs onion 12:29 < cdecker> #action cdecker to review lightningnetwork/lightning-onion#31 12:29 <+roasbeef> as in # of bytes for type and value 12:29 <+roasbeef> you can pack 700 ish bytes, so you need a 2 byte length 12:29 <+roasbeef> err type and length soz 12:29 <+roasbeef> while 1 byte type may be enough 12:29 <+roasbeef> the wrie protocol on the otherhand may want diff values there 12:29 < bitconner> roasbeef, indeed. i think it'd be possible to reuse most of the logic and change some constants for different use cases if necessary 12:29 < cdecker> Right, I'll need to catch up there and then we can discuss in depth :-) 12:30 < cdecker> Any other topics that we need to address before we end the meeting? 12:30 <+roasbeef> nope, planning to reply to the existing eob thread to outline how waht i implemented works and to brdige the gap of the diff 12:31 < cdecker> Excellent, thank you very much everybody, and sorry for the overtime :-) 12:31 < cdecker> #endmeeting 12:31 < lightningbot> Meeting ended Mon Jan 21 20:31:22 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:31 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-21-18.59.html 12:31 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-21-18.59.txt 12:31 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-21-18.59.log.html 12:31 < rusty> cdecker: thanks! 12:31 < bitconner> thanks for moderating cdecker :) 12:32 < sstone> thanks cdecker! 12:32 < cdecker> Anytime, had a lot of time, hope I didn't cut anybody off 12:32 < cdecker> s/time/fun/ :-) 12:35 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has joined #lightning-dev 12:36 -!- YSqTU2XbB [~smuxi@5.170.48.41] has quit [Ping timeout: 246 seconds] 12:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:37 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving] 12:41 -!- YSqTU2XbB [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #lightning-dev 12:45 -!- YSqTU2XbB [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Remote host closed the connection] 12:46 -!- pav [~pavle_@195.181.160.173.adsl.inet-telecom.org] has joined #lightning-dev 13:15 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection] 13:16 -!- hiroki [7c9aaff8@gateway/web/freenode/ip.124.154.175.248] has quit [Quit: Page closed] 13:16 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #lightning-dev 13:20 -!- pav [~pavle_@195.181.160.173.adsl.inet-telecom.org] has quit [] 13:26 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 13:27 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 13:35 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 13:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds] 14:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 14:06 -!- thomasan_ [~thomasand@2605:a601:b021:f00:3de3:3c69:c8b0:c715] has quit [Remote host closed the connection] 14:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.9.1] 14:29 -!- rusty [rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:29 -!- rdymac [uid31665@gateway/web/irccloud.com/x-yjakmlvthxlwrpnt] has joined #lightning-dev 14:44 -!- kexkey [~kexkey@173.209.48.131] has quit [Quit: Scaling pentatonically] 14:51 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 14:58 -!- thomasan_ [~thomasand@136.52.18.22] has joined #lightning-dev 15:06 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 246 seconds] 15:08 -!- Murch [~murch@ip-173-109-32-60.chcgil.spcsdns.net] has joined #lightning-dev 15:11 -!- thomasan_ [~thomasand@136.52.18.22] has quit [Remote host closed the connection] 15:11 -!- laurentmt [~Thunderbi@62.112.9.237] has quit [Quit: laurentmt] 15:34 -!- rusty [rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 15:34 -!- ratonlaveur [~ratonlave@67.215.14.198] has quit [Ping timeout: 268 seconds] 15:43 -!- Murch [~murch@ip-173-109-32-60.chcgil.spcsdns.net] has quit [Quit: Snoozing.] 15:56 < lndbot> Sorry guys maybe a stupid question: The returning txid from https://api.lightning.community/?shell#sendcoins, is that txid the same as the tx_hash returned by https://api.lightning.community/?shell#subscribetransactions ? 15:57 < lndbot> I need to implement a way to check if a tx has been confirmed 15:57 < lndbot> is that the approach for on-chain tx ? 16:03 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 16:06 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Quit: Leaving] 16:20 -!- rusty [rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:30 -!- ratonlaveur [~ratonlave@132.205.230.13] has joined #lightning-dev 16:30 -!- ratonlaveur_ [~ratonlave@67.215.14.198] has joined #lightning-dev 16:34 -!- ratonlaveur [~ratonlave@132.205.230.13] has quit [Ping timeout: 246 seconds] 16:36 -!- rusty [rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 16:39 -!- rdymac [uid31665@gateway/web/irccloud.com/x-yjakmlvthxlwrpnt] has quit [Quit: Connection closed for inactivity] 16:43 -!- Murch [~murch@ip-173-154-133-49.kscymo.spcsdns.net] has joined #lightning-dev 16:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 17:06 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 17:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 17:10 -!- Murch [~murch@ip-173-154-133-49.kscymo.spcsdns.net] has quit [Quit: Snoozing.] 17:18 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 17:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 17:24 -!- thomasan_ [~thomasand@2605:a601:b021:f00:17a:37e8:6654:8146] has joined #lightning-dev 17:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 17:30 -!- thomasan_ [~thomasand@2605:a601:b021:f00:17a:37e8:6654:8146] has quit [Remote host closed the connection] 17:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.9.1] 18:07 -!- riclas [riclas@148.63.37.111] has quit [Ping timeout: 245 seconds] 18:17 -!- thomasan_ [~thomasand@136.52.18.22] has joined #lightning-dev 18:19 -!- thomasan_ [~thomasand@136.52.18.22] has quit [Remote host closed the connection] 18:32 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Read error: Connection reset by peer] 18:42 -!- unixb0y [~unixb0y@p5B029CE8.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 18:43 -!- unixb0y [~unixb0y@p5B02988E.dip0.t-ipconnect.de] has joined #lightning-dev 18:59 -!- Murch [~murch@ip-184-250-205-232.sanjca.spcsdns.net] has joined #lightning-dev 18:59 -!- Murch [~murch@ip-184-250-205-232.sanjca.spcsdns.net] has quit [Client Quit] 19:02 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 250 seconds] 19:07 -!- foureighttwonine [~foureight@175.158.218.41] has joined #lightning-dev 19:11 -!- foureighttwonine [~foureight@175.158.218.41] has quit [Ping timeout: 246 seconds] 19:18 -!- ratonlaveur_ [~ratonlave@67.215.14.198] has quit [Ping timeout: 268 seconds] 20:21 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 250 seconds] 20:23 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #lightning-dev 20:47 -!- foureighttwonine [~foureight@175.158.217.151] has joined #lightning-dev 20:51 -!- foureighttwonine [~foureight@175.158.217.151] has quit [Ping timeout: 245 seconds] 20:54 -!- foureighttwonine [~foureight@82.102.28.107] has joined #lightning-dev 20:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 20:59 -!- foureighttwonine [~foureight@82.102.28.107] has quit [Remote host closed the connection] 21:07 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 21:11 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 244 seconds] 21:13 -!- foureighttwonine [~foureight@82.102.28.107] has joined #lightning-dev 21:35 -!- MrPaz [~MrPaz@c-71-57-73-68.hsd1.il.comcast.net] has joined #lightning-dev 21:42 -!- ratonlaveur_ [~ratonlave@67.215.14.198] has joined #lightning-dev 21:44 -!- Kostenko [~Kostenko@185.183.106.227] has quit [Ping timeout: 268 seconds] 22:00 -!- Kostenko [~Kostenko@185.183.106.228] has joined #lightning-dev 22:27 -!- foureighttwonine [~foureight@82.102.28.107] has quit [Ping timeout: 240 seconds] 22:28 -lightningrfc:#lightning-dev- [lightning-rfc] nayuta-ueno opened pull request #555: BOLT 4: Clarify final_incorrect_cltv_expiry data (master...final_incorrect_cltv_expiry_data) https://git.io/fhg6F 22:43 -!- shesek [~shesek@141.226.218.90] has joined #lightning-dev 22:43 -!- shesek [~shesek@141.226.218.90] has quit [Changing host] 22:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 23:04 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 23:08 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 23:09 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 23:13 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 245 seconds] 23:34 -!- foureighttwonine [~foureight@175.158.217.151] has joined #lightning-dev 23:37 -!- foureighttwonine [~foureight@175.158.217.151] has quit [Read error: Connection reset by peer] 23:44 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 23:57 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev --- Log closed Tue Jan 22 00:00:23 2019