--- Log opened Mon Jan 07 00:00:13 2019 00:27 -!- Abdoulaye [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 00:28 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev 00:37 -!- bitonic-cjp [~bitonic-c@a80-100-203-151.adsl.xs4all.nl] has joined #lightning-dev 00:55 -!- Abdoulaye is now known as diackca 01:10 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:11 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:29 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 01:29 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 01:33 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:33 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 01:33 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 01:36 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:39 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 01:39 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 01:43 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 01:43 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 01:49 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 01:50 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 01:54 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 246 seconds] 02:01 < rusty> Friendly reminder that meeting will be held HERE in in 9 hours: https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco/edit# 02:14 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 02:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 02:23 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 02:23 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 02:28 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds] 02:40 -!- cmdpwnd [aec4814d@gateway/web/freenode/ip.174.196.129.77] has joined #lightning-dev 02:46 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev 02:49 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 02:49 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 02:51 -!- cmdpwnd [aec4814d@gateway/web/freenode/ip.174.196.129.77] has quit [Quit: Page closed] 02:52 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 02:58 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 02:58 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 03:30 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 03:44 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 03:44 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 03:48 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 03:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 03:49 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 03:58 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 04:05 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 04:10 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 244 seconds] 04:14 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 04:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 04:23 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 04:23 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 04:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 04:42 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 252 seconds] 04:53 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 05:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 05:03 -!- deusexbeer [~deusexbee@079-170-137-113-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds] 05:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:15 < lndbot> A question regarding LN UX: At the moment there is no easy way to send a LN payment from PC to mobile LN wallets, since it is necessary to send the invoice somehow from the mobile LN wallet app to the PC, before the payment can be sent. Is there anything planned in the Lightning protocol to ease this process? So for example "ask for invoice" via QR code? 05:22 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 05:25 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 05:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 05:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 05:38 < cdecker> That's already possible today, wallets just don't implement it yet 05:39 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 250 seconds] 05:41 < cdecker> Alternatively all the built-in share functionality in Android and iOS will also work 05:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 05:50 -!- jungly [~quassel@79.8.200.97] has quit [Ping timeout: 250 seconds] 05:51 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev 05:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 06:02 < lndbot> Cool. So what is this feature called, so I can read about it? 06:04 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 06:06 < lndbot> So on a protocol level a node can ask the target node to create an invoice? 06:14 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 06:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:18 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 06:19 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:24 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 06:24 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:33 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 06:34 -!- booyah [~bb@193.25.1.157] has joined #lightning-dev 06:38 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 06:39 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:54 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 06:54 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:56 -lightningrfc:#lightning-dev- [lightning-rfc] araspitzu opened pull request #539: Add test vectors for htlc-transactions for the case when the CLTV is used as tie-breaker for sorting (master...ordering_CLTV_tiebreaker_test_vectors) https://git.io/fhGnF 06:58 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 06:58 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 06:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 07:02 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 07:03 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 07:04 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 07:04 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 07:07 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 258 seconds] 07:09 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 07:13 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 07:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 07:19 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 07:27 -!- MTelh91IeZNU5d5l [23b4d8ee@gateway/web/freenode/ip.35.180.216.238] has joined #lightning-dev 07:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 07:35 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #lightning-dev 08:08 -!- jungly [~quassel@79.8.200.97] has quit [Ping timeout: 268 seconds] 08:10 -!- MTelh91IeZNU5d5l [23b4d8ee@gateway/web/freenode/ip.35.180.216.238] has quit [Quit: Page closed] 08:13 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 08:24 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 08:24 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 08:24 -!- bitonic-cjp [~bitonic-c@a80-100-203-151.adsl.xs4all.nl] has quit [Quit: Leaving] 08:28 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 08:29 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 08:34 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev 08:40 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 08:44 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev 08:46 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 08:48 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 08:48 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #lightning-dev 08:54 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 08:54 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 08:58 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 08:58 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:04 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 09:04 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:08 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 09:09 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:10 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 09:11 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 09:19 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 09:19 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:20 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 09:23 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 09:24 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:25 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 268 seconds] 09:26 < cdecker> Ah, no I misunderstood. I thought you'd be meeting and you'd exchange an invoice via QR code displayed on the phone and scan it on the computer 09:34 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 09:34 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:35 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev 09:39 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 09:43 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 09:48 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 09:48 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 09:56 < lndbot> Joule has a way to get invoices, but this would be a good addition to the standard 10:05 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection] 10:09 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 10:09 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 10:12 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 10:12 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 10:13 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 10:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 10:15 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 10:17 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 10:17 -!- melvin_ [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer] 10:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 10:29 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 10:29 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 10:29 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 10:29 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 10:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 10:33 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 10:33 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 240 seconds] 10:34 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 10:34 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 10:36 < cdecker> Doesn't Joule just grab lnweb tags from the webpage, or generate new ones from the attached lnd node? 10:40 < lndbot> I haven’t used it but I think it creates an interface so a webpage can control the lnd to create new invoices 10:40 < lndbot> With user confirmation 10:44 < cdecker> Uhm, how does the website controlling the sender lnd help in this case? Or are we talking about refunds? 10:46 < lndbot> For mobile it probably doesn’t help except in demonstrating a flow 10:46 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Read error: Connection reset by peer] 10:47 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 10:49 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 10:50 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #lightning-dev 10:51 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 240 seconds] 10:51 < cdecker> Speaking of which, the refund flow seems interesting imho 10:54 -!- ott0disk [~ott0disk@5.170.48.40] has joined #lightning-dev 10:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds] 10:58 -!- pipp8 [~pipp8@unaffiliated/pipp8] has joined #lightning-dev 10:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:00 < rusty> Hello all! Let's see how well this meeting thing works. https://wiki.debian.org/MeetBot has some notes on the bot, BTW. 11:00 < AmikoPay_CJP> Nice timing. 20:00:11 11:00 < cdecker> Hello everyong, happy new year!!! 11:00 < rusty> #startmeeting 11:00 < lightningbot> Meeting started Mon Jan 7 19:00:44 2019 UTC. The chair is rusty. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:01 < AmikoPay_CJP> Happy new year! Has the orthodox new year already started? 11:01 < cdecker> Uh, we have a meetbot, excellent 11:01 < rusty> I expect some chaos, but fortunately things are fairly quiet on the spec front. The main aim is to get the v1 stuff out of the way. 11:02 < rusty> #info https://docs.google.com/document/d/1Clbw41wY7hNbfMPozH0IRhmqO4ERDR6FdnBGp79VJ3M/edit# Agenda 11:02 < cdecker> I propose we go through the spelling PRs first, and then dig into the meatier stuff 11:03 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has joined #lightning-dev 11:03 < AmikoPay_CJP> Do we note down presence (and how do we determine that)? 11:03 < rusty> Any which now have two acks can be applied and removed from the list... 11:04 < cdecker> Well, do mine and yours count as two independent acks? 11:04 < rusty> AmikoPay_CJP: I think it's unfair to assume everyone lurking is "present". 11:04 -!- rpickhardt [5f5bdc3d@gateway/web/freenode/ip.95.91.220.61] has joined #lightning-dev 11:04 < AmikoPay_CJP> I'd say, to be present, you have to say something? 11:04 < rusty> cdecker: not usually, but I'm tempted to waive this rule given how long it's been. 11:04 < cdecker> Right, #bitcoin-core-dev usually pings a list of regular people, maybe we can do something similar? 11:05 < rusty> AmikoPay_CJP: agreed, I'll note presence retrospectively :) 11:06 -!- grubles [~grubles@unaffiliated/grubles] has joined #lightning-dev 11:06 < Chris_Stewart_5> meta stuff: is this monthly or biweekly? 11:06 < cdecker> biweekly 11:06 <+roasbeef> bi weekly 11:06 < cdecker> Hi roasbeef 11:06 < rusty> #lightning-dev roasbeef aj BlueMatt cdecker jimpo niftynei rpickhardt I'm sure I missed others... 11:06 < bitconner> hi all, happy new year! 11:06 < cdecker> Are pm7 and sstone also present 11:07 <+roasbeef> we'll see how well it works out, idk i feel like it'll be less productive than the reg, the bitcoind are working on an impl and just so happen to always hook in protocol stuffs, while we all have diff impls and work together on protocol 11:07 < rusty> pm7 sstone 11:07 < BlueMatt> huh 11:07 < AmikoPay_CJP> Do we keep a complete IRC log or only the BOT minutes? 11:07 < BlueMatt> wat 11:07 <+roasbeef> main upside i guess is more participation 11:07 < sstone> present, pm won't be joining us today 11:07 < BlueMatt> oh meeting? 11:07 <+roasbeef> i think kanzure logs this channel? 11:07 < niftynei> hello and happy new year 11:07 <+roasbeef> i have some of by own, but they aren't to be counted on 11:07 < rusty> roasbeef: bot lots, so do I... 11:08 < rusty> AmikoPay_CJP: I think bot logs everything, also provides minutes summary. 11:08 < cdecker> Ok, shall we get going on the PRs? Seems we have quorum 11:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.9.1] 11:08 < AmikoPay_CJP> cdecker: ok 11:08 < rusty> OK, I move that we accept any typo changes which have two acks, even if from cdecker and me. Since you didn't all do your homework :) 11:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 11:08 < cdecker> +1 on merging spellings 11:08 < rusty> (I usually prefer we get two independent acks, but...) 11:08 < BlueMatt> spellings, sure 11:09 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 11:09 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 11:09 < rusty> https://github.com/lightningnetwork/lightning-rfc/milestone/2 gives most of them... 11:09 <+roasbeef> rusty: bot bot isn't a thing anymore 11:10 < rusty> roasbeef: :( But in this case we have a lightningbot for the meeting records. 11:10 <+roasbeef> where doe sit store them? 11:10 < cdecker> #action Merge #514 #515 #518 #520 #521 under the spelling rule with two acks 11:10 < rusty> roasbeef: AJ's server I think, same as bitcoin-core-dev. 11:10 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 11:11 < sstone> cdecker: ok 11:11 < cdecker> Seems the meeting chair (rusty) needs to record actions 11:11 < BlueMatt> 514 looks wrong 11:12 < cdecker> We have been using mutual closing and closing as synonyms for the longest time IIRC 11:12 < cdecker> This just cleans up the aliasing 11:12 < BlueMatt> ehh, whatever, then, just reads weird 11:12 <+roasbeef> mutual close seems more precise? there're multiple ways to close 11:12 < AmikoPay_CJP> "unilateral close" sounds like a subset of "close". 11:13 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 11:13 < cdecker> In the glossary in BOLT#0 the closing transaction is defined as being the mutual close 11:13 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 11:14 < cdecker> So if we're not happy with going just with "closing transaction" we need to amend the glossary as well 11:14 < rusty> We can certainly replace the phrase "closing transaction" as "mutual close transaction", which is slightly clearer IMHO. 11:14 < BlueMatt> ok, that sounds wholly separate, the change is fine as-is, and we can look into replacing it separately 11:14 < rusty> #action accept 514 11:14 < AmikoPay_CJP> agree 11:15 < BlueMatt> kool 11:15 -!- hiroki [7c9aaff8@gateway/web/freenode/ip.124.154.175.248] has joined #lightning-dev 11:15 < sstone> ack 11:15 <+roasbeef> is this process even defined or written down anywhere? are there docs on the bot? 11:15 < rusty> #action Merge #515 #518 #520 #521 under the spelling rule with two acks 11:15 <+roasbeef> approved em all on gh, sgtm 11:15 < rusty> roasbeef: https://wiki.debian.org/MeetBot 11:16 < rusty> cdecker: want to merge them live, to cut down the list :) 11:16 < cdecker> +1 11:17 < AmikoPay_CJP> rusty: you mean, outside the meeting? 11:17 < kanzure> hi. 11:17 < BlueMatt> next topix 11:17 < BlueMatt> ? 11:17 < kanzure> biweekly is ambiguous; do you mean fortnightly? 11:17 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #lightning-dev 11:17 < kanzure> roasbeef: http://gnusha.org/lightning-dev/ 11:18 < AmikoPay_CJP> "Biweekly means either occurring every two weeks, or occurring twice every week." lol didn't realize that. 11:18 < rusty> #topic Remaining v1.0 Milestone PRs 11:18 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 11:19 < AmikoPay_CJP> kanzure: it's fortnightly. 11:19 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/500 11:20 < rusty> roasbeef: full quote helps here: "Note that the `htlc_maximum_msat` field is static in the current 11:20 < rusty> protocol over the life of the channel: it is *not* designed to be 11:20 < rusty> indicative of real-time channel capacity in each direction, which 11:20 < rusty> would be both a massive data leak and uselessly spam the network (it 11:20 < rusty> takes an average of 30 seconds for gossip to propagate each hop)." 11:21 <+roasbeef> it's static on the link level, but you can issue updates on the network level 11:21 < rusty> roasbeef: this advice is saying explicitly not to do that. 11:21 <+roasbeef> but the update can't be greate rhtan the link level value, or exceed the max capacity of the channel 11:21 <+roasbeef> well yeh don't spam it, but you can modify your routing policies in real time 11:21 < cdecker> So you are saying we can send updates that set this in the acceptable range? 11:22 < cdecker> Sounds a bit micro-managy, but interesting 11:22 <+roasbeef> i don't mean each time you forward, i mean lets say you want to carry even smaller htlcs that are routed across, you can modify this 11:22 -!- ott0disk [~ott0disk@5.170.48.40] has left #lightning-dev [] 11:22 <+roasbeef> yeh 11:22 -!- ott0disk [~ott0disk@5.170.48.40] has joined #lightning-dev 11:23 < cdecker> Are there good use-cases for this functionality? Or reasons to do so? If not I'm tempted to defer 11:23 < BlueMatt> current spec says you shouldnt do that, if you want to change it, thats a separate discussion from 500... 11:23 <+roasbeef> or lets say for w/e reason, someone is being a nuisance and just hodling onto larger htlcs thru your channel, you can clamp down a bit on that by lowering this value and notifying all others interested in routing across 11:23 < BlueMatt> 500 just notes that minmum is, too, which is definitely true 11:23 <+roasbeef> yeh the original wording itself was too restrictive, for example you _can't_ update the link level values, but you can update the network level value 11:23 <+roasbeef> or even in a world of multi path payments, you may want to modify based on how ppl are typically splitting 11:24 < rusty> roasbeef: explicitly no. That's basically reflecting dynamic capacity. 11:24 < cdecker> Ok, shall we accept #500 and defer the discussion about the ability to change this to another PR? 11:24 < BlueMatt> cdecker: ack, htlc_minimum_msat even says you MUST set it to the value your peer will accept 11:24 -!- ott0disk [~ott0disk@5.170.48.40] has quit [Quit: Leaving] 11:24 < BlueMatt> so thats an orthogonal change 11:24 < cdecker> roasbeef: would that work for you? 11:25 < rusty> roasbeef: Yeah, more useful (in an AMP world) would be giving *some* vague non-completely-leaky indication of how far out the capacity constraint is. 11:25 <+roasbeef> you can't enforce that it's static though 11:25 <+roasbeef> nodes would need to rememebr the "first" (w/e that is) value and reject the rest 11:25 -!- ott0disk [~smuxi@5.170.48.40] has joined #lightning-dev 11:25 < rusty> roasbeef: of course not, but this is advice to avoid people trying to use this to send dynamic information. 11:26 < BlueMatt> or just the most recent and always check its the same in each update, thats pretty trivial, but it doesnt really matter, the text says you MUST set it to the value your peer sets, which is constant 11:26 <+roasbeef> BlueMatt: how do you know what the first update looked like? 11:26 < cdecker> I think he means the first one you saw and then just check on each update that the value doesn't change 11:26 < BlueMatt> that 11:26 <+roasbeef> rusty: ok then in that case the language can be relaxed, rn it asserts it's static in the protocol which is false 11:27 <+roasbeef> so then nodes are to reject if it chaanges? 11:27 < BlueMatt> no, its not, look later down... "MUST set htlc_minimum_msat to the minimum HTLC value that the channel peer will accept" 11:27 < BlueMatt> it is absolutely required to be static right now, but I agree we can/should look into relaxing that 11:27 <+roasbeef> it isn't though :/ 11:27 < BlueMatt> the text change proposed in 500 is consistent, even if you'd prefer it not be 11:28 < rusty> roasbeef: sure, it's sloppily worded. It should say the total channel capacity is static in current protocol, and the intent of this is to reflect that, not dynamic capacity. Of course, this has to be rewritten for 1.1 anyway... 11:28 <+roasbeef> it doesn't reflect reality 11:28 < cdecker> Does it get worse if we apply #500 and make a new issue discussing whether we should relax it roasbeef? 11:28 < BlueMatt> roasbeef: how is it not reflective of the requirement later down in that section? what am I missing? 11:29 < rusty> So, I think 500 is OK, but there's a deeper issue in the text it hits. 11:30 < rusty> Since no agreement here, let's move on. 11:30 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/502 11:30 < cdecker> #agreed Defer discussion of #500 to the issue tracker 11:31 <+roasbeef> BlueMatt: then doesn't that contradict itself? top tries to say static, below indicates it's dynamic value (what i accept today, may not accept tomorrow), i get we want to discourage flappy updates but we can do that with more precise language 11:31 <+roasbeef> sgtm 11:31 < rusty> There's a style nit that cdecker commented on... I think our style guide says use explicit 0 for a zero. 11:32 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 11:32 < cdecker> Ok, didn't realize that, if the styleguide says that I retract my nit :-) 11:32 < rusty> But I think we should apply this, with a note to clean up the tabs v spaces whitespace post. This too has been sitting here 3 months. 11:33 < rusty> #action Rusty to clean up whitespace tabs vs space in BOLT11 11:33 < BlueMatt> concept ack the changes, though I havent looked through them 11:33 < BlueMatt> roasbeef: ohhhh, I see your reading of it, yea, i guess thats obviously not how anyone else read it, so the text would need "assuming the channel capacity is available" or so in the MUST set section later 11:33 < BlueMatt> to make it match how everyone else read it 11:34 < rusty> Any objections to 502? 11:34 < BlueMatt> sounds like no 11:34 < sstone> rusty: no 11:34 < niftynei> there's a few outstanding spelling issues in 502 11:34 < rusty> #action Apply 502. 11:34 -!- pipp8 [~pipp8@unaffiliated/pipp8] has quit [Quit: Leaving] 11:34 < niftynei> i'll go in and annotate them, other 11:34 < niftynei> *annotate them 11:34 < rusty> niftynei: thanks :) 11:35 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/514 11:35 -!- stick` [~stick@sway.gk2.sk] has joined #lightning-dev 11:35 < BlueMatt> huh? it got merged? 11:35 < BlueMatt> did you mean something else 11:35 <+roasbeef> looks liek it's aleady dunzo 11:35 < ott0disk> isn't 514 already discussed? 11:35 < BlueMatt> we already did 514 11:35 <+roasbeef> yeh it was batched 11:36 < AmikoPay_CJP> as typo pull 11:36 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/525 11:36 < cdecker> #514 was one of the spellings we agreed before :-) 11:36 * rusty furiously searches for one not closed already... 11:37 < AmikoPay_CJP> Wait, are we actually going to finish going through this list today? 11:37 < cdecker> Hehe, rusty maybe we can define a milestone for each meeting, that way the issues become easier to iterate through 11:37 < rusty> cdecker: good idea... 11:37 < BlueMatt> ack 525 11:37 < rusty> #action Apply 525 11:37 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/528 11:37 < BlueMatt> looks like lots o' acks 11:37 <+roasbeef> AmikoPay_CJP: most of them are already ticked, well a good bit, buncha small ones 11:38 < cdecker> lol, that one's a freudian switch if I ever saw one :-) 11:39 < rusty> #action Apply 528 11:39 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 11:39 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 11:39 < AmikoPay_CJP> ack 528 11:39 < BlueMatt> note: if possible please write up what was discussed in meeting on the pr as required, best to keep notes so its visible after the fact imo 11:40 < rusty> OK, 529 and 530 already double-acked, am simply applying. 11:40 < BlueMatt> even if its just a comment that says "looks good as per meeting discussion" or something (unless, obviously, it meets ack requirements on its own) 11:40 < cdecker> Agreed 11:40 < cdecker> We also probably shouldn't merge mid-meeting either :-) 11:41 < rusty> Yes, for non-typo things, sure. 11:42 < rusty> We shouldn't even need to discuss typos in meeting, but getting acks proved hard. 11:42 < rusty> #action Merge 523 11:42 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/527 11:42 < bitconner> ack 523 11:44 < rusty> I convinced myself this was correct when I acked it, but it's a bit non-trivial. 11:44 -!- rpickhardt [5f5bdc3d@gateway/web/freenode/ip.95.91.220.61] has quit [Ping timeout: 256 seconds] 11:44 < BlueMatt> this reads wrong to me? 11:45 < BlueMatt> MUST *resolve* the _remote node's offered HTLCs_.....with HTLC-Timeout? 11:45 < BlueMatt> remote's offered implies to-us implies *they* should time it out? 11:45 < BlueMatt> or am I misreading? 11:45 < rusty> BlueMatt: misreading... "* spend the *HTLC-timeout tx*, if the remote node has published it." 11:45 < BlueMatt> oh lol, yup, indeed 11:46 < BlueMatt> ack'd 11:46 < cdecker> #agreed Merge #527 11:46 < rusty> #action Merge #527 11:46 < BlueMatt> cdecker: plzackonzegithubz 11:47 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/532 11:47 < rusty> Can I have an ack please? 11:48 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 11:48 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 11:49 < rusty> I think it needs bitconner, roasbeef or cdecker ack really. 11:49 < cdecker> Not sure, roasbeef you're the resident Noise_XK expert, can you confirm this is correct? 11:49 < AmikoPay_CJP> It doesn't look like a typo. Isn't there actually a meaning difference? 11:49 <+roasbeef> slightly off-topic, but there's a Noise Protocol meetup this week in the bay area, collocated with RWC 11:49 < cdecker> Indeed there is, it now switches which key is used, and I failed to follow the rationale 11:49 <+roasbeef> the diagram above and the text are correct 11:49 <+roasbeef> this body was diff 11:50 < BlueMatt> if it were wrong, my code definitely wouldnt work, so this is clearly the ways its implemented, and the header matches the change 11:50 <+roasbeef> the prior text was wrong, the ephemeral keys are already exchanged earlier in the protocol 11:50 < rusty> Yeah, it was well-spotted. 11:50 < BlueMatt> also what roasbeef said 11:50 <+roasbeef> this is now the initiator telling the responder who they are 11:50 < rusty> #action Apply #532 11:50 < cdecker> Excellent, so that's an ACK from BlueMatt and roasbeef :-) 11:51 < rusty> #action https://github.com/lightningnetwork/lightning-rfc/pull/533 11:51 < BlueMatt> do we really want to gossip these instead of just returning them via update_fails 11:51 < BlueMatt> ? 11:51 < rusty> Now I read it again I'm not so sure. It's undefined what "completely unbalanced" means. 11:51 <+roasbeef> imo just return the fail 11:51 < cdecker> Shall we add that completely empty means below minimum_msat? 11:52 < BlueMatt> I mean better response is to rebalance the channel or so vs gossiping something 11:52 <+roasbeef> from my PoV, you don't even really need the gossip, you can just get all these updates back in error messages 11:52 < rusty> FWIW, we considered not sending out a channel_update until we had some outgoing capacity, but niftynei pointed out that's a terrible passive data leak. 11:52 <+roasbeef> as more users really only pay a select number of destinations at this stage, and impls can learn from their behavior to optimize which updates to fetch optimistically and which ones to just grab the fail 11:52 < ott0disk> note that a channel might be disabled due to other reason too 11:52 < cdecker> Right, this is a tradeoff between letting people try and fail, or telling them ahead of time 11:53 <+roasbeef> ott0disk: yeh that too, atm lnd only does offline/online thresholds 11:53 <+roasbeef> just raising fees on a channel to "too damn high" can also signal the same thign 11:53 <+roasbeef> cdecker: does CL disable a channel until it's above the reserve? 11:53 < cdecker> Same with c-lightning, but we wait for someone to actually attempt to use the channel before broadcasting 11:53 < rusty> roasbeef: no. 11:53 < cdecker> That'd leak the funder 11:53 <+roasbeef> gotcha, not sure why i thought y'all did 11:54 < cdecker> (I might have mentioned something like that in the past. mea culpa) 11:55 < rusty> cdecker: I think it was my clever idea, TBH. But yeah, not so clever. 11:55 < rusty> Don't know how to undo an ack on GH. 11:55 < rusty> So, we Nak this change with some explanation? 11:56 < BlueMatt> sounds good to me, yes 11:56 < BlueMatt> will write up 11:56 < BlueMatt> sec 11:56 < sstone> like what it actually means to be unbalanced ? 11:56 < cdecker> Yep, sounds good 11:56 <+roasbeef> sstone: /shrug 11:56 < rusty> #action Close #533 with explanation 11:57 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/533 11:57 < rusty> BlueMatt points out that it's technically backwards incompatible, but since nobody uses the error fields at the moment... 11:57 < BlueMatt> rusty: wrong link 11:57 < BlueMatt> 538 is what you meant 11:57 < rusty> #topic https://github.com/lightningnetwork/lightning-rfc/pull/538 11:58 < rusty> Thanks. 11:58 < BlueMatt> yea, I dont care, I'm happy to just see it merged as-is, just noting that it would break someone actually currently using that data 11:58 < BlueMatt> actually, I think we use them 11:58 < BlueMatt> wait 11:58 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 11:58 <+roasbeef> yeh at a glance woudl seem it isn't backwards compat? 11:59 <+roasbeef> why is it better to return the outogoing in these cases? the PR description doesn't have any sort of justification 11:59 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 11:59 < rusty> roasbeef: well, that's the one you're complaining about. And in fact, that's what c-lightning does, from a quick reading now. 12:00 < BlueMatt> oh, no, we dont use them 12:00 < rusty> Yes, confirmed; we generate those errors on the outgoing side, it has no concept of where it came from. 12:00 <+roasbeef> why's it better to return the amt in the onion instead of the amt extended if it's below min? 12:01 <+roasbeef> by outgoing htlc, it means the onion forwarding info right? 12:01 < cdecker> Yep, that'd be the value you'd apply when forwarding 12:01 -!- pav [~pavle_@185.59.221.158.adsl.inet-telecom.org] has joined #lightning-dev 12:01 < BlueMatt> for amount_below_minimum it makes sense, but, indeed, for cltv_expiry_delta, I dont think it does 12:02 < sstone> yes (it only applies when you're forwarding payments) 12:02 < BlueMatt> ie cause you know the value they're supposed to set on the remote cause they told you the onion passed mac check 12:02 < BlueMatt> but you cant be sure the previous hop forwarded it correctly 12:03 <+roasbeef> i'm confused...yeh you know the onion vlaue is correct if it checked, so then someone didn't give you the correct value, which means you should tell the incoming value? 12:03 <+roasbeef> same w/ the cltv expiry 12:03 < BlueMatt> well the htlc value change there only is the minimum, so really any data you might send is redundant 12:03 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 258 seconds] 12:03 < BlueMatt> but for cltv_expiry doesnt make sense 12:04 <+roasbeef> seems there's two cases: the sender messed up and didn't checkk your min value, and the node before you took too many fees or gave you an incorrect htlc 12:04 < BlueMatt> took too many fees should be covered by fee_Insufficient 12:04 < BlueMatt> not amount_below_minimum 12:04 < BlueMatt> incorrect htlc -> cltv_expiry, yea 12:06 <+roasbeef> i guess we're also over time now 12:07 < cdecker> Ok, so the correction seems correct to me, the value for amount_below_minimum seems redundant since the sender knows that value but ok 12:07 < rusty> And bad cltv should be caught by incorrect_cltv_expiry. So we assume it's not the fault of the prior node. 12:08 <+roasbeef> commented on the PR 12:08 < rusty> Yes, we're into overtime, and I need coffee to consider all the cases here. So let's defer this one onto the PR and close? 12:08 < rusty> roasbeef: thanks! 12:08 < BlueMatt> kool 12:08 < BlueMatt> next topic? 12:08 < cdecker> Yep, defer is good here 12:08 < rusty> #action Defer 538 to the PR itself. 12:09 < cdecker> I think we're through the issues/PRs 12:09 <+roasbeef> lingering stuff at the end: lnd has a fixed for an update_fee related bug, might explain some of the random force closes even between ourselves, should land in this week and we'll follow up with a minor release to get ppl on the network updated 12:09 < rusty> I'm going to close the formal meeting due to time constraints, but feel free to discuss wider issues. Sorry we didn't get to it. 12:10 < rusty> #endmeeting 12:10 < lightningbot> Meeting ended Mon Jan 7 20:10:03 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:10 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-07-19.00.html 12:10 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-07-19.00.txt 12:10 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-01-07-19.00.log.html 12:10 < cdecker> Excellent, that wasn't too bad for the first time I think ^^ 12:10 <+roasbeef> basically we didn't handle the case of a concurrent sig from both sides after we'd already sent an update_fee, so we'd try to enforce that new fee on the incoming sig 12:10 <+roasbeef> yeh not as bad as i thought it would be :p 12:10 < rusty> roasbeef: I have a report of a bad signature from yalls.org, running through it today; had two simultaneous things and an update fee. Is this likely the same thing? 12:11 < rusty> (as in, yalls.org gave c-lightning what it considered a bad commitment sig) 12:11 <+roasbeef> rusty: soudns like it 12:11 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 12:11 < BlueMatt> man, need dat option_simplified_commitment 12:12 < rusty> roasbeef: I want to hug you, because I was NOT looking fwd to debugging that one :) 12:12 <+roasbeef> in first stage of deploy (new commit) we'd still update_fee usage 12:12 <+roasbeef> :D 12:13 < rusty> brb... 12:14 < cdecker> Loving the meetbot output :-) 12:15 <+roasbeef> yeh output is pretty nitfy 12:15 < AmikoPay_CJP> Apparently, presence is an integer, not a boolean. 12:16 < sstone> BlueMatt: are you still interested in applying set reconciliation tools to sync routing data ? 12:16 < BlueMatt> rusty: dunno if you saw my email this morning re: option_simplified_commitment, sorry I've been really bad at my homework....if there's anything worth discussion higher bandwidth happy to 12:16 < BlueMatt> sstone: I am, though admittedly havent dug into it a ton 12:16 < BlueMatt> I tried to convince suhas to tackle it and got close to nerd-sniping him but failed in the end :/ 12:16 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 258 seconds] 12:16 < BlueMatt> sstone: I think the first step is to simulate with real data and minisketch and see where we get 12:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 12:17 < BlueMatt> sstone: I had some ideas and went back-and-forth with suhas and others a bit and think its quite practical 12:17 < BlueMatt> depending on how its structured 12:17 < sstone> I've had a took at how we can use minisketch for example but got stuck. I do think that there's a mismatch 12:18 < sstone> if you and I have 2 different updates with different timestamps for the same channel we'll end up syncing both 12:18 < BlueMatt> no? 12:18 < BlueMatt> you'll see there is a mismatch and download the higher-timestamp 12:18 < BlueMatt> assuming you're using the timestamp,id tuple in minisketch, which is slower, so may not be the ideal way 12:18 < BlueMatt> needs simulation 12:19 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 12:19 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 12:19 < sstone> ah ok yes something may be possible if we include the timestamp in what is actually being reconciled 12:19 < sstone> but 64 bits is not much 12:19 < BlueMatt> you'd have to? 12:20 < BlueMatt> it does make the field much slower 12:20 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Leaving] 12:21 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 12:21 -!- hiroki [7c9aaff8@gateway/web/freenode/ip.124.154.175.248] has quit [Quit: Page closed] 12:21 < sstone> also we've seen that there are a lot of "redundant" updates bc of "flapping" channels 12:22 < BlueMatt> indeed, though thats somewhat orthogonal, no? 12:22 < BlueMatt> like, not much we can do about that, any sync mechanism has to deal with that 12:22 <+roasbeef> sstone: imo y'all shouldn't worry about religiously syncing all channel updates, even once the inv stuff and stuff beyond that is in 12:23 < bitconner> sstone: spent a good bit of time over the holidays reworking lnd's enable/disable state machine 12:23 <+roasbeef> you have a good idea of which destinations are frequently sent to from the clients' PoV, and can prioritize those 12:23 < sstone> it's not syncing all updates, it's more not querying things you already have 12:23 <+roasbeef> which paths 12:23 < bitconner> sstone: should be a bit less chatty from our end after that's rolled out 12:23 <+roasbeef> sstone: yeh there's a tradeoff tho right? bandwidth vs latency of payments 12:24 <+roasbeef> you get the data on failure, so you don't need to optimistically fetch everything 12:24 <+roasbeef> on all my routing nodes, i even furth off chan updates all togther as passive forwarding nodes don' treally need em 12:24 <+roasbeef> my logs are readable now ;) 12:25 < sstone> yes, I guess, but I was just surprised how much traffic is redundant 12:26 < sstone> which is why I added a basic checksum over HTLC min/max and fees to my proposal for extended channel queries 12:26 < bitconner> sstone: how does the checksum account for new fields that get added? 12:27 < bitconner> in a tlv-world, for example 12:28 < sstone> then it would change. the idea is to cover fields that are needed for routing and not actually updated very often 12:28 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 12:28 < sstone> it could also be used in INV messages 12:28 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 12:29 < bitconner> would we not then need a way to signal which fields are covered? idt we can just change the covered fields as tha would break backcompat? 12:30 -!- ott0disk [~smuxi@5.170.48.40] has quit [Read error: Connection reset by peer] 12:30 < sstone> yes that's correct 12:32 <+roasbeef> sstone: yeh generally imo eating a bit extra latency on the first payment is a worthy tradeoff over the increased bandwidth 12:33 <+roasbeef> as even with the checksum or w/e, ppl can still be flappy for no reason 12:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:36 <+roasbeef> like with the mil channel thing, i sure how that by then the existing gossip stuff has been pretty much scrapped all together 12:36 <+roasbeef> hope* 12:36 < sstone> yes we're currently mostly looking at optimizing our current routing traffic. And I guess you're right about the million channels :) 12:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer] 12:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 12:37 < sstone> got to go now, thanks! 12:37 -!- sstone [~sstone_@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving] 12:39 -!- pav [~pavle_@185.59.221.158.adsl.inet-telecom.org] has quit [] 12:40 < BlueMatt> ;;later tell sstone interestingly, sadly, the flappyness of a channel is useful information...if you're a mobile client and want ot reduce bandwidth, a good optimization is to have five servers that tell you the list of channels that *arent* flappy and just combine the results of that 12:41 <+roasbeef> did we lose the github bot in here? 12:41 < BlueMatt> later tell is usually gribble, where's a nanotube when you need one 12:54 -!- deusexbeer [~deusexbee@080-250-076-070-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 12:56 -!- deusexbeer [~deusexbee@080-250-076-070-dynamic-pool-adsl.wbt.ru] has quit [Remote host closed the connection] 12:57 -!- deusexbeer [~deusexbee@080-250-076-070-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 13:09 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Quit: farmerwampum] 13:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:09 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 13:12 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 13:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 13:13 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Client Quit] 13:14 -!- farmerwampum [~farmerwam@184.75.210.234] has joined #lightning-dev 13:21 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 272 seconds] 13:42 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 13:42 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Read error: Connection reset by peer] 13:42 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 14:04 -!- kaybesee [48315c2a@gateway/web/freenode/ip.72.49.92.42] has joined #lightning-dev 14:09 -!- kaybesee [48315c2a@gateway/web/freenode/ip.72.49.92.42] has quit [Client Quit] 14:09 -!- Tralfaz [~none@104.248.145.220] has quit [Ping timeout: 258 seconds] 14:10 -!- Tralfaz [~none@104.248.145.220] has joined #lightning-dev 14:20 < niftynei> in case anyone else was wondering what an INV message is, it's a bitcoin message type https://en.bitcoin.it/wiki/Protocol_documentation#inv 14:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 14:21 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 14:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:45 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 14:46 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 14:49 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 14:49 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Read error: Connection reset by peer] 14:55 < rusty> niftynei: an INV message is how bitcoin's gossip works: it says eg. "I have block X" and the peer asks for it if it wants it. 15:11 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds] 15:13 -!- keymone [~keymone@31.16.193.167] has joined #lightning-dev 15:13 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev 15:22 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 15:39 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 15:55 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 15:59 < BlueMatt> ;;later tell sstone interestingly, sadly, the flappyness of a channel is useful information...if you're a mobile client and want ot reduce bandwidth, a good optimization is to have five servers that tell you the list of channels that *arent* flappy and just combine the results of that 15:59 < gribble> The operation succeeded. 15:59 < BlueMatt> gribble: wherefor art though gribble 15:59 < BlueMatt> heh, yay 16:00 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 240 seconds] 16:01 -!- diackca_ [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Remote host closed the connection] 16:02 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 16:02 < rusty> niftynei: here's my blushingly incomplete WIP on JSON test vectors https://github.com/rustyrussell/lightning-rfc/tree/guilt/tests 16:06 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 240 seconds] 16:14 < niftynei> thnx! 16:43 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 16:48 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 16:48 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Read error: Connection reset by peer] 16:49 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 16:49 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 16:49 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 16:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds] 16:59 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 17:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:06 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 17:10 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 17:11 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has joined #lightning-dev 17:19 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 17:47 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 246 seconds] 17:56 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 18:02 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 272 seconds] 18:16 -!- melvster [~melvin@ip-86-49-18-190.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 18:20 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 18:20 -!- keymone [~keymone@31.16.193.167] has quit [Ping timeout: 244 seconds] 18:21 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has joined #lightning-dev 18:21 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 18:41 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has quit [Ping timeout: 245 seconds] 18:43 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has joined #lightning-dev 18:55 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #lightning-dev 18:56 -!- unixb0y [~unixb0y@p5B029CFE.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 18:58 -!- unixb0y [~unixb0y@p5B02973D.dip0.t-ipconnect.de] has joined #lightning-dev 19:00 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 19:05 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 250 seconds] 19:08 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 19:19 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Remote host closed the connection] 19:40 -!- Tralfaz [~none@104.248.145.220] has quit [Quit: Leaving] 19:49 -!- farmerwampum [~farmerwam@184.75.210.234] has quit [Ping timeout: 250 seconds] 19:55 -!- thomasanderson [~thomasand@172.83.40.67] has joined #lightning-dev 20:00 -!- thomasanderson [~thomasand@172.83.40.67] has quit [Ping timeout: 250 seconds] 20:06 -!- zenogais [~eric@cpe-76-175-74-114.socal.res.rr.com] has joined #lightning-dev 20:35 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 20:54 -!- winircuser-714 [~winircuse@p1538213-ipngn200604fukuokachu.fukuoka.ocn.ne.jp] has joined #lightning-dev 20:56 -!- winircuser-714 [~winircuse@p1538213-ipngn200604fukuokachu.fukuoka.ocn.ne.jp] has quit [Read error: Connection reset by peer] 20:59 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has joined #lightning-dev 21:03 -!- diackca [~abdoulaye@41-184-172-161.rv.ipnxtelecoms.com] has quit [Ping timeout: 250 seconds] 21:03 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #lightning-dev 21:27 -!- zenogais [~eric@cpe-76-175-74-114.socal.res.rr.com] has quit [Ping timeout: 246 seconds] 21:53 -!- xchuck00 [~xchuck00@unaffiliated/xchuck00] has joined #lightning-dev 22:34 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 260 seconds] 22:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:38 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #lightning-dev 23:48 -!- xchuck00_ [~xchuck00@unaffiliated/xchuck00] has joined #lightning-dev 23:52 -!- xchuck00 [~xchuck00@unaffiliated/xchuck00] has quit [Ping timeout: 268 seconds] --- Log closed Tue Jan 08 00:00:14 2019