--- Day changed Mon Nov 13 2017 00:05 -!- JackH [~laptop@91.189.61.70] has joined #lightning-dev 00:10 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 250 seconds] 00:12 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has joined #lightning-dev 00:13 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has quit [Remote host closed the connection] 00:13 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has joined #lightning-dev 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 00:16 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 00:18 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has quit [Ping timeout: 268 seconds] 00:24 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds] 00:28 -!- alanc_ [~chatzilla@109.255.196.64] has joined #lightning-dev 00:29 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 00:41 -!- Cogito_Ergo_Sum [~Myself@athedsl-314838.home.otenet.gr] has joined #lightning-dev 00:41 -!- Cogito_Ergo_Sum [~Myself@athedsl-314838.home.otenet.gr] has quit [Changing host] 00:41 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev 00:48 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has joined #lightning-dev 00:53 -!- lndbot [~lndbot@138.197.213.35] has quit [Ping timeout: 248 seconds] 00:58 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [Ping timeout: 240 seconds] 01:06 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #lightning-dev 01:35 -!- laurentmt1 [~Thunderbi@92.154.68.134] has joined #lightning-dev 01:37 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Ping timeout: 268 seconds] 01:37 -!- laurentmt1 is now known as laurentmt 01:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rfxpalwyzkkbouqw] has quit [Quit: Connection closed for inactivity] 01:52 < stevenroose> cdecker: about the channel factories paper, is it final, found a nit 01:53 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev 01:59 -!- m8tion01 [~m8tion@81-65-53-254.rev.numericable.fr] has joined #lightning-dev 02:01 -!- m8tion [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Ping timeout: 250 seconds] 02:10 -!- nodweber [~nodweber@94.100.229.130] has joined #lightning-dev 02:23 -!- nodweber [~nodweber@94.100.229.130] has quit [Remote host closed the connection] 02:29 -!- nodweber [~nodweber@94.100.229.130] has joined #lightning-dev 02:37 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Ping timeout: 248 seconds] 03:23 -!- CubicEarth [~cubiceart@xdsl-31-164-62-119.adslplus.ch] has quit [] 03:30 -!- dakk [~dakk@62-11-224-211.dialup.tiscali.it] has quit [Ping timeout: 248 seconds] 03:42 < cdecker> stevenroose, Conrad is still amending some minor things for the camera ready version 03:42 < cdecker> I can forward feedback if you'd like 03:56 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds] 03:59 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #lightning-dev 04:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection] 04:22 -!- deusexbeer [~deusexbee@080-250-077-176-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 240 seconds] 04:23 -!- deusexbeer [~deusexbee@093-092-177-014-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev 04:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #lightning-dev 04:31 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 04:32 < pm> cdecker: hey christian you there? 04:36 < cdecker> Yup 04:36 < cdecker> Sorry have a terrible track record on IRC these days 04:36 < pm> what do you mean? 04:40 < cdecker> I keep missing fabrice when he contacts me on IRC seeing his messages way too late 04:40 < cdecker> Sorry about that :-) 04:41 < pm> I guess I'm lucky then ^^ 04:42 < pm> I'm debugging test eclair_eclair_lnd, it appears to be a race condition in the sending of announcement_signatures 04:42 < pm> in c-lightning do you happen to know when it is done? after having sent the funding_locked, or after having sent and received it? 04:43 < pm> specs says that it can be sent right after the funding_locked (and before having received the counterparty's funding_locked), but I wonder if it is a good idea 04:44 < pm> it creates a scenario that only happens during testing when blocks are generated all at once 04:45 -!- marcoagner [~user@gateway/tor-sasl/marcoagner] has joined #lightning-dev 04:45 < cdecker> We send it as soon as funding_locked 04:46 < pm> but after 6 blocks right ? 04:46 < cdecker> Then we defer the actual announcements until we have sent and received the announcement sigs AND announce_depth was reached 04:46 < cdecker> No, we send it after 2 if funding_depth is set to two 04:47 < pm> hmm that's not compliant with BOLT 7 I think? https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#requirements 04:47 < cdecker> announce_depth of 6 only applies to {channel,node}_announcement and channel_update messages 04:47 < pm> you sure? "If sent, announcement_signatures messages MUST NOT be sent until funding_locked has been sent and the funding transaction has at least 6 confirmations." 04:47 < cdecker> Ok, that sounds strange indeed 04:47 < cdecker> Lemme check 04:48 < cdecker> Oh you're right 04:48 < cdecker> if (!(peer->announce_depth_reached && peer->funding_locked[LOCAL])) return; 04:49 < cdecker> So we wait for local locked AND announce_depth to be reached 04:49 < cdecker> https://github.com/ElementsProject/lightning/blob/master/channeld/channel.c#L186 04:49 < cdecker> So you're right 04:49 < pm> that's what lnd does too, and that is what the spec says 04:50 < cdecker> BTW we have 3 failing integration tests all of them forwarded_payment and with the last two nodes eclair_lnd in this order 04:50 < cdecker> That may be it 04:50 < pm> yes probably 04:50 < pm> problem is that we wait for the remote funding_locked 04:51 < cdecker> Cool, I'll file an issue with logs and we can see what happens 04:51 < pm> so the problem is in eclair 04:52 < cdecker> We trigger on both depth and funding_locked received 04:52 < pm> oh! 04:52 < pm> ok 04:52 < cdecker> But it only appears in combination with lnd, so it's actually the combination 04:52 < pm> so I guess eclair and c-lightning are both non-compliant ;-) 04:53 < cdecker> Huh? As in trigger I mean we attempt to send, and only actually send when both funding_locked local AND anonounce_depth was reached 04:53 < cdecker> (which is exactly what the spec says imho) 04:53 < pm> what do you do when you receive an announcement_signatures before even having sent the funding_locked? 04:53 < pm> (because blocks are generated in bulk) 04:55 < cdecker> We stash it until we are ready to send 04:56 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 04:56 < pm> don't you think the spec should instead say "If sent, announcement_signatures messages MUST NOT be sent until funding_locked has been sent *and received*, and the funding transaction has at least 6 confirmations." 04:56 < pm> my concern is that it creates a scenario that only occurs in testing 04:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 04:57 < pm> oh no you are right, if remote has a min_depth greater that 6 it wouldn't work 04:57 < cdecker> Hm, nothing prevents us from receiving blocks in arbitrary bursts 04:58 < pm> than* 04:58 < cdecker> Yeah, that as well 04:58 < pm> ok cool 04:58 < cdecker> It's a bit annoying to have to temporarily stash the signature for later, but it's the best solution I could come up with 04:59 < pm> actually I'm taking my last comment back, it works even when min_depth>6 05:00 < pm> I think announcement_signatures after funding_locked sent+received would be simpler, no stash necessary 05:03 < cdecker> Could work as well 05:04 < cdecker> So you're suggesting making a barrier out of the locked state of both channels instead of locally deciding that we are ready for this to be announced? 05:05 < cdecker> Forget that, I also need to add announce_depth into the barrier 05:06 < cdecker> So basically adding a third condition (remote_locked) into the signature exchange 05:07 < pm> yes, in other words send announcement_signatures only when the channel is usable (same preconditions as for sending update_add_htlc) 05:07 < pm> I think it makes sense and it is simpler? 05:09 < cdecker> Hm, c-lightning probably ends up stashing at least one signature anyway, but strengthening the barrier is fine by me 05:12 < pm> let me file an issue, see what laolu and rusty think 05:13 < cdecker> Only downside is that we'd be breaking the freeze (again) 05:13 < cdecker> But it's trivial to implement and literally takes 2 lines in c-lightning to do 05:14 < pm> if they disagree we add the stash in eclair 05:15 < cdecker> Sounds good, they should be compatible anyway ^^ 05:18 < stevenroose> cdecker: Figure 8 is not mentioned in the document 05:19 < stevenroose> Also, the first reference (the one for flood routing) seems to point like a random email in the discussion instead of the first email about the announcement (might be intensional) 05:20 < stevenroose> For Figure 8, it should be mentioned in Section 3.2, but it's not 05:21 < cdecker> Great, thanks for double checking, will see if I'm still in time to alter the camera ready version 05:22 < stevenroose> They're nits, but since the figure is not rendered close to the relevant section, it can be confusing 05:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 258 seconds] 05:41 -!- dff [~dff@unaffiliated/dff] has joined #lightning-dev 05:44 < dff> what happens if bobs sends alice 1 BTC off chain, that transaction is kept offchain for a long period of time as described in the youtube video on lightning.network 05:44 < dff> meanwhile, bob sends his only 1 BTC to someone else on chain 05:46 < cdecker> He can't, the coin is in a shared account controlled by both Alice and Bob so that they have to agree on how the coins get assigned 05:46 < cdecker> For your scenario the same coin would have to be in two multisig addresses at once, which Bitcoin makes sure does not happen 05:47 < dff> how does the main chain know of the shared account? 05:48 < dff> wouldnt that mean that the address holding bobs 1 btc has to be transferred to an an address owned by both bob and alice? 05:49 < mryandao> dff: bob cant doublespend coins that are committed to lightning 05:50 < dff> mryandao: how is that enforced? 05:50 < mryandao> bitcoin consensus rules enforce it 05:50 < dff> i understand how that works on the bitcoin chain 05:51 < dff> but not for things off chain 05:51 < cdecker> The setup of the channel basically consists of moving the funds into the shared account on-chain 05:51 < cdecker> Once the on-chain setup transaction confirms, then we can start transferring off-chain 05:52 < dff> i see, that would result in a tx fee 05:52 < dff> right? 05:52 < dff> i'm trying to understand how this is helping micro transactions 05:56 < mryandao> just moving your coins to a shared account 05:57 < mryandao> after that, you're free to move funds between alice/bob as much as you like, no tx fees involved 05:58 < cdecker> Right, you have 2 on-chain txs (setup and settlement) but you can amortize those costs with an infinite number of transfers over that channel during its lifetime 06:00 < dff> Right, so it doesnt really solve the problem of a single micropayment between alice and bob. 06:01 < dff> it works well if alice and bob have a lot of micropayments and use Party-A to facilitate them? 06:01 < cdecker> By routing payments over an extended network you can do one-off payments to people that you don't have a direct channel with 06:02 < dff> right 06:02 < cdecker> As long as there is any path from A to B they can interact just fine 06:02 < dff> but if there is c and d 06:02 < dff> you need a thrid party 06:02 < dff> right? 06:02 < dff> otherise you are opening up 2tx on chain, 06:03 < dff> unless there is a path between a-b-c-d open 06:03 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 06:03 < cdecker> Uhm, yes, you don't need to open all these channels yourself, you can use other people's channels as well 06:05 < dff> so would it be fair to assume that if this is implemented there is likely to be a third party payment processor? 06:05 < dff> with a lot of open channels 06:05 < dff> like the mastercard/visa of bitcoin 06:06 < cdecker> No, because that third party would have to front a lot of coins 06:06 < cdecker> it'd become a single point of failure and a huge target for attacks 06:07 < cdecker> We hope to establish a mesh-like network made out of users 06:07 < cdecker> That'd also increase privacy and resilience against attacks 06:08 < mryandao> cdecker: isn't finding an optimal route in this mesh-network hard? 06:09 < cdecker> Nobody said it'd be simple 06:09 < cdecker> :-) 06:10 < cdecker> But we have a number of ideas on how to tackle it 06:10 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-emgpqgjuvncgwahu] has quit [Quit: Connection closed for inactivity] 06:10 < dff> cdecker: thanks for taking the time to explain 06:10 < mryandao> so there might be "peering arrangements" eventually between peers and pseudo-BGP like protocols? 06:10 < cdecker> After all the internet topology is hard to route through as well, but we do it every day 06:11 < mryandao> yeah, the internet relies on BGP for that and various peering agreements 06:11 < cdecker> BGP-style routing is not really possible with our direct onion routing implementation but we might want to use that eventually 06:11 < cdecker> And peering agreements are little more than "you route for me, and I route for you" agreements 06:11 < dff> what are the guesstimates on when this could be live? 06:12 < cdecker> They're basically the paper agreement equivalent of accepting a channel 06:12 < cdecker> dff, the cannonical answer is "two weeks (tm)" or "when we are reasonably sure it's safe" 06:13 < cdecker> We don't want to rush it and then discover we have a bug in it that cost user funds 06:13 < dff> understandable 06:15 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 06:17 -!- marcoagner [~user@gateway/tor-sasl/marcoagner] has quit [Quit: WeeChat 1.0.1] 06:53 -!- rusticbison [b32b9443@gateway/web/freenode/ip.179.43.148.67] has joined #lightning-dev 07:03 -!- nodweber [~nodweber@94.100.229.130] has quit [Remote host closed the connection] 07:06 -!- adiabat [~adiabat@45.63.20.152] has joined #lightning-dev 07:07 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [] 07:07 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 07:14 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 07:17 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev 07:48 -!- rusticbison [b32b9443@gateway/web/freenode/ip.179.43.148.67] has quit [Ping timeout: 260 seconds] 07:54 -!- JackH [~laptop@91.189.61.70] has quit [Ping timeout: 240 seconds] 07:55 -!- dakk [~dakk@62-11-224-211.dialup.tiscali.it] has joined #lightning-dev 07:57 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 07:59 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:00 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 08:01 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 240 seconds] 08:03 -!- jb55 [~jb55@70.36.49.138] has joined #lightning-dev 08:05 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds] 08:08 -!- jb55 [~jb55@70.36.49.138] has quit [Ping timeout: 268 seconds] 08:19 -!- JackH [~laptop@alvira.static.korbank.pl] has joined #lightning-dev 08:22 -!- dakk [~dakk@62-11-224-211.dialup.tiscali.it] has quit [Remote host closed the connection] 08:35 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 08:39 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 08:39 -!- nodweber [~nodweber@188.129.208.212] has joined #lightning-dev 08:55 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt] 08:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-oyaxlzisuwlaedia] has joined #lightning-dev 09:09 -!- dom_eclair [~dom_eclai@92.184.96.31] has quit [Read error: Connection reset by peer] 09:21 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds] 09:33 -!- nodweber [~nodweber@188.129.208.212] has quit [Remote host closed the connection] 09:34 -!- nodweber [~nodweber@188.129.208.212] has joined #lightning-dev 10:03 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection] 10:04 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 10:08 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 10:34 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 10:34 -!- akrmn [~akrmn@88.red-83-52-44.dynamicip.rima-tde.net] has joined #lightning-dev 10:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:10 -lightningrfc:#lightning-dev- [lightning-rfc] Roasbeef pushed 2 new commits to master: https://git.io/vFKeA 11:10 -lightningrfc:#lightning-dev- lightning-rfc/master a759dff Rusty Russell: BOLT 1, tools: add support for our first optional field.... 11:10 -lightningrfc:#lightning-dev- lightning-rfc/master 046f5ac Rusty Russell: BOLT 2: option-data-loss: limited data loss protection.... 11:20 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 11:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 11:35 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 12:07 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 12:09 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 12:10 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 12:14 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 12:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 12:15 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 12:17 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 12:18 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 12:19 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 12:21 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 12:21 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 12:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 12:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:28 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 12:31 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 12:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:57 -!- Cogito_Ergo_Sum [~Myself@athedsl-314734.home.otenet.gr] has joined #lightning-dev 12:57 -!- Cogito_Ergo_Sum [~Myself@athedsl-314734.home.otenet.gr] has quit [Changing host] 12:57 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev 13:05 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 13:09 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 13:16 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 13:16 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 13:19 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-xznhjyvkrcpngaii] has joined #lightning-dev 13:24 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 250 seconds] 13:25 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 13:26 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #lightning-dev 13:29 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 13:29 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 13:51 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-wsorugsiucntfmmj] has quit [Ping timeout: 255 seconds] 13:51 -!- cdecker [~cdecker@mail.snyke.net] has quit [Ping timeout: 255 seconds] 13:52 -!- cdecker [~cdecker@mail.snyke.net] has joined #lightning-dev 13:54 -!- jb55 [~jb55@24.87.206.252] has joined #lightning-dev 14:04 -!- jb55 [~jb55@24.87.206.252] has quit [Ping timeout: 240 seconds] 14:04 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 14:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 14:06 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-zozkkpvfqbyfscct] has joined #lightning-dev 14:09 -!- jb55 [~jb55@24.87.206.252] has joined #lightning-dev 14:11 -!- esotericnonsense [~esotericn@gateway/vpn/privateinternetaccess/esotericnonsense] has quit [Quit: esoteric nonsense] 14:18 -!- JackH [~laptop@alvira.static.korbank.pl] has quit [Read error: Connection reset by peer] 14:19 -!- JackH [~laptop@alvira.static.korbank.pl] has joined #lightning-dev 14:25 -!- nodweber [~nodweber@188.129.208.212] has quit [Remote host closed the connection] 14:42 -!- dom_eclair [~dom_eclai@92.184.96.31] has joined #lightning-dev 14:49 -!- jb55 [~jb55@24.87.206.252] has quit [Ping timeout: 248 seconds] 15:09 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 15:15 -!- riclas [riclas@72.210.189.46.rev.vodafone.pt] has joined #lightning-dev 15:18 -!- Cogito_Ergo_Sum2 [~Myself@80.107.150.74] has joined #lightning-dev 15:18 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [Ping timeout: 248 seconds] 15:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 15:22 -!- Cogito_Ergo_Sum2 [~Myself@80.107.150.74] has quit [Client Quit] 15:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:30 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 15:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 15:45 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell opened pull request #272: htlckey: new basepoint avoid holding the payment secret. (master...htlckey) https://git.io/vFKow 15:49 -!- Rozal is now known as EarIyGrey 15:50 -!- alanc__ [~chatzilla@109.255.196.64] has joined #lightning-dev 15:51 -!- EarIyGrey is now known as Rozal 15:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds] 15:53 -!- alanc_ [~chatzilla@109.255.196.64] has quit [Ping timeout: 240 seconds] 16:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:40 -!- juscamarena_ [~justin@47.148.173.164] has joined #lightning-dev 17:27 -!- akrmn [~akrmn@88.red-83-52-44.dynamicip.rima-tde.net] has quit [Ping timeout: 248 seconds] 17:31 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 17:33 -!- StopAndDecrypt [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #lightning-dev 17:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-oyaxlzisuwlaedia] has quit [Quit: Connection closed for inactivity] 17:38 -!- Elsewhere [2fbb31b8@gateway/web/freenode/ip.47.187.49.184] has joined #lightning-dev 17:39 -!- Elsewhere [2fbb31b8@gateway/web/freenode/ip.47.187.49.184] has quit [Client Quit] 18:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 18:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 18:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds] 18:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev 19:00 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Quit: WeeChat 1.9] 19:55 -!- riclas [riclas@72.210.189.46.rev.vodafone.pt] has quit [Ping timeout: 268 seconds] 20:21 <+roasbeef> rusty: I think i've found an inconsistency w/ the way the optionall data loss provision is currently defined 20:21 <+roasbeef> when you recv a chan sync message, you can conclude the either: you don't need to send any data, or you need to send some data (updates, sigs, revokes, etc) 20:21 < rusty> Yep. 20:22 <+roasbeef> however, you can't verify that they're sending the correct commit point (what should be their unrevoked) if they've sent a revocation, but you ever recevied it, so they _will_ send it (but only after you process) 20:22 <+roasbeef> so here's a case: we started a transition, before they sent their last revoke, connection dies. when we come back up we don't owe anything, but they commit point they sent will be of their new state, not of the state that we think is their current 20:23 <+roasbeef> you _can_ always verify the "this is your last secret you sent me part" tho 20:24 <+roasbeef> in the "we're both synced up" case, everything is fine, but if one party didn't get the other's revocation, then what the "current" commit point is unknown until both parties transmit w/e they need to 20:24 < rusty> I *think* that's OK. We basically can't validate per_commitment_point in the cases where it matters. 20:25 <+roasbeef> mhmm, I think it's fine as well, just the current wording (at least the way I was reading it) would make you fail the channel if you don't need to send anything, but they need to re-send a revocation 20:25 <+roasbeef> > Otherwise, if either the `your_last_per_commitment_secret` or `my_current_per_commitment_point` do not match the expected values, the receiving node SHOULD fail the channel. 20:26 <+roasbeef> first part is fine, it's the second portion 20:26 < rusty> So, yeah, "if either the `your_last_per_commitment_secret` or `my_current_per_commitment_point` do 20:26 < rusty> not match the expected values" ie. values for the given next_local_commitment_number`/next_remote_revocation_numberr 20:27 < rusty> Ah, I see. You don't know yet I guess. 20:27 < rusty> I think we have to drop the "or `my_current_per_commitment_point`" requirement? 20:27 <+roasbeef> yeh you don't know _yet_, but after the exchange (both sides send everything), you can go back and check that the point is proper 20:28 <+roasbeef> depends... 20:29 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 20:29 <+roasbeef> seems that we do tho, unless it's modified to defer verification of the point to after the exchange, though it's likely the case that if that's wrong, then you wouldn't be able to process the retransmitted messages 20:30 < rusty> Hmm. Yeah, if we skip the check altogether, it's encouraging them to send crap, which sucks since we know we can't verify when it actually matters. 20:30 <+roasbeef> yeh 20:30 <+roasbeef> it's really only verifiable in the case that you need to go to chain, either you'll be able to derive the witness script, or not 20:30 < rusty> So we *should* check it later, to keep them hoest. 20:31 <+roasbeef> well also in the "biz as usual" case it's verifiable 20:31 <+roasbeef> mhmm 20:31 <+roasbeef> depending on arch, may be kinda hard to slip in, as they can just continue to do updates after the retrans 20:31 < rusty> But if it's "wrong" we have to wait for retransmit, right? 20:31 <+roasbeef> wait for them to retransmit? you can't tell it's "wrong" until they do (I think?) 20:32 <+roasbeef> you can cache it somewhere though, and then check in their next revocation that it properly matches up 20:33 <+roasbeef> but even in the case they sent garbage, but then proceed to update the channel, do we really care? 20:33 <+roasbeef> (in the case they need to retransmit a revoke) 20:35 < rusty> Hmm, I'd need to walk through more carefully. Does next_remote_revocation_number tell us that they're one ahead on revocation? So if that's what we expect, then we can check my_current_per_commitment_point. It's only when next_remote_revocation_number is out-by-one that we need to defer check? 20:36 < rusty> Ah, no, that's the counter on the other side. Ignore me 20:38 < rusty> Hm.... damn, gtg. I think removing the check is minimal spec change, but we should add a "MAY check later"? 20:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:39 <+roasbeef> mhmm 20:53 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #lightning-dev 22:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 22:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 22:13 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev 22:25 -!- nodweber [~nodweber@188.129.208.212] has joined #lightning-dev 22:30 -!- nodweber [~nodweber@188.129.208.212] has quit [Ping timeout: 240 seconds] 23:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hzaictgpvrotdsow] has joined #lightning-dev 23:05 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:24 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds] 23:37 -!- Cogito_Ergo_Sum [~Myself@80.107.150.74] has joined #lightning-dev 23:37 -!- Cogito_Ergo_Sum [~Myself@80.107.150.74] has quit [Changing host] 23:37 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev 23:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev