--- Day changed Mon Feb 13 2017 00:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 00:06 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has joined #lightning-dev 00:09 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #lightning-dev 00:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds] 01:00 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has joined #lightning-dev 01:06 -!- takayaimai [~takayaima@em1-115-199-235.pool.e-mobile.ne.jp] has joined #lightning-dev 01:20 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds] 02:13 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 02:16 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 02:40 -!- takayaimai [~takayaima@em1-115-199-235.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 03:27 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 245 seconds] 04:04 -!- HostFat [~HostFat@host248-244-dynamic.20-87-r.retail.telecomitalia.it] has joined #lightning-dev 04:07 -!- HostFat_ [~HostFat@host220-91-dynamic.245-95-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 04:10 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 04:29 -lightningrfc:#lightning-dev- [lightning-rfc] OttoAllmendinger opened pull request #108: Bolt 02: minor fixes (master...bolt-02-fixes) https://git.io/vDoCt 04:51 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #lightning-dev 04:57 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 04:57 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #lightning-dev 04:58 -!- BashCo__ [~BashCo@unaffiliated/bashco] has joined #lightning-dev 05:00 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has joined #lightning-dev 05:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds] 05:02 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 05:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 05:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:27 -!- molz_ [~molly@unaffiliated/molly] has joined #lightning-dev 05:30 -!- crescend1 [~mozart@173.203.100.20] has joined #lightning-dev 05:31 -!- roasbeef_ [~root@104.131.26.124] has joined #lightning-dev 05:32 -!- roasbeef [~root@104.131.26.124] has quit [Write error: Broken pipe] 05:32 -!- mol [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 05:32 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Remote host closed the connection] 06:14 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 06:33 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #lightning-dev 07:36 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 07:47 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:05 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 08:18 -!- Greybits [~Greybits@unaffiliated/greybits] has joined #lightning-dev 08:19 < Greybits> Hi! I'm kind of new and not very smart at segwit and bitcoin etc. But to me it looks like segwit is a man in the middle proxy for crypto controlled by the government so they can block transactions to people like wikileaks 08:20 < Greybits> is that what lightning network is for? 08:26 < Greybits> so luke-jr and coblee want to spy on people? 08:27 < Greybits> but wait do luke-jr still want 300k block size too? ye failed experiment 08:46 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds] 08:50 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #lightning-dev 08:59 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 09:00 < cdecker> What? Segwit is not any different than todays Bitcoin network from a decentralization standpoint, nor is Lightning, if anything it improves privacy... 09:01 < abpa> It changes the privacy characteristics 09:02 < Greybits> the people that make lightning network provide transaction risk scoring for btc, and also bitcoin mixer "detangling"....how does that improve privacy if you add it by default to btc (or ltc) ? 09:02 < abpa> The people who make LN don't do that 09:02 -!- BashCo__ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 264 seconds] 09:02 < Greybits> bitfury is pretty much the ones behind lightning network 09:03 < Greybits> and thats what they do 09:03 < abpa> LN doesn't add that by default and BitFury is not the ones behind LN 09:03 < Greybits> OK 09:03 < Greybits> why does bitfury have offices in DC? is that a hotbed of bitcoin or banking activity? 09:03 < Greybits> what does bitfury do in north carolina by the military base down there? 09:04 < Greybits> if you wanna take it all the way lets go 09:04 < abpa> BitFury are not the ones behind LN 09:05 < Greybits> "Bitfury Lightning Network Algorithm Successfully Tested" 09:05 < abpa> BitFury has written about LN, but then again so have you 09:05 < Greybits> "“This success exemplifies why The Bitfury Group is committed to research and to supporting the implementation of Lightning Network." 09:06 < Greybits> keep talking your trollish trash 09:06 < abpa> Many people support LN 09:07 < Greybits> great, a company that supports tracking bitcoin users and detangling bitcoin mixers is in favor of lightning network and segwit.....does that tell you anything???? 09:08 < abpa> No 09:08 < Greybits> ok its not my fault you are blind 09:08 < cdecker> Guys can you move this somewhere else? 09:10 < Greybits> thank you for letting me speak my mind. peace. 09:10 -!- Greybits [~Greybits@unaffiliated/greybits] has left #lightning-dev ["Leaving"] 09:11 < sstone> cdecker: hi Christian I have a quick question about reconnection 09:11 < cdecker> This is channel for technical discussion, not conspiracy theories 09:11 < cdecker> That being said, I won't kick anybody, so feel free to write whatever you want, but don't expect us to reply :-) 09:12 < cdecker> Sure sstone 09:12 < sstone> A has a channel with B. B loses its connection for some reason and is now offline. A tries to reconnect to B. How does B know which channel he's supposed to restore ? 09:13 < cdecker> Aren't we replaying the full channel setup stuff upon reconnection? 09:14 < sstone> mmm... I dont' think so (?). say they've both sent and received 'funding-locked', what would they have to re-send ? 09:16 < cdecker> Uhm, good question 09:17 < cdecker> Wait have both committed the `funding_locked` to disk before going offline? i.e., will they recover it? 09:18 < cdecker> In that case I'd assume all channels are brought back up without problem 09:21 < sstone> yes, but from a tcp server pov B will see a new tcp connection, handshake etc... but how does he know which channel to assign it to ? I ended up adding a 'channel-id' field to the 'init' message just for this 09:22 < sstone> to put it differently, is there a message that you must re-transmit when reopening a channel and that includes the channel id ? 09:23 < cdecker> Well the TCP connection is authenticated with the peer's ID isn't it? So the channel-id needs to be stored with the peer-id on persistent storage 09:24 < cdecker> Once the crypto setup and init handshake completes we recover the channel-ids for that peer and restore those 09:25 < cdecker> If needed `init` is probably not the place to pass this, since it is a connection-specific message, not a channel-specific 09:25 < cdecker> And a connection may have multiple channels over it 09:25 < sstone> ah ok you mean there is a single tcp connection for any given peer not matter how many channel we've opened , and we multiplex channel messages on that connection ? 09:26 < cdecker> Hm, good point, hadn't thought about having multiple connections between endpoints 09:27 < cdecker> But yes, that's the general idea, muxing channels on top of a single connection 09:28 < sstone> I think multiplexing was discussed but I don't remember I a definite choice being made (I have the memory of a goldfish though...) 09:29 < sstone> So it means multiplexing is not really optional 09:31 < cdecker> Well, our client currently simply fails opening a second channel :-p 09:31 < cdecker> So it is optional in that sense 09:35 -!- udiWertheimer [~udiWerthe@bzq-82-81-94-166.red.bezeqint.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:36 < sstone> Yes :) but from a specs p.o.v I think it should be mentioned that there should be a single connection between peers 09:37 < sstone> and I' wondering if that could create limitations later (load-balancing etc...) as opposed to one connection per-channel 09:39 < cdecker> I think multiplexing is lighter on resources if we have a single daemon, no need to store multiple connection states 09:40 < cdecker> I don't think we should cater too much to large hubs, running multiple daemons, after all we want to avoid huge hubs routing forming in the first place 09:41 < cdecker> They'll have to come up with their own load-balancing strategy 09:41 < cdecker> Should not be too hard for them to do so anyway: 09:41 < cdecker> - terminate encrypted connection at the load-balancer 09:41 < cdecker> - route to channel-specific backend 09:42 < sstone> yes but you have the same issue: you don't know which channel is being targeted until you've received the first message that includes a channel id 09:45 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:48 < cdecker> Yes, so the load-balancer handles `init` and `error`, while all other messages have a channel-id which allows them to be routed to the corresponding backend 09:49 < cdecker> For connection re-establishment you'd probably query all backends for any channel-id corresponding to the peer-id 09:53 < sstone> but both client and server (from a tcp pov) would be in a temporary state. From a client pov you've chosen to reopen an existing channel, and all you know it that you have a new connection to the same peer 09:53 < sstone> it could fail later when you send an update become the peer could not restore that specific channel for example 09:53 < sstone> s/become/because 10:03 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 10:07 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 10:14 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has joined #lightning-dev 10:17 < cdecker> Well for these cases we should always drop to the chain and close the channel, I don't think there is a good/safe way to recover if one side has only partial knowledge about the state 10:22 -!- FiveBroDeepBook [~gk.1vm.su@2001:590:1405:2e5:2e5:9592:2218:862d] has joined #lightning-dev 10:25 -!- FiveBroDeepBook [~gk.1vm.su@2001:590:1405:2e5:2e5:9592:2218:862d] has quit [K-Lined] 10:28 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 10:41 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 256 seconds] 10:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:56 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 11:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 11:09 -!- cjamthagen [~user@h-88-153.a230.priv.bahnhof.se] has quit [Ping timeout: 240 seconds] 11:14 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.] 11:15 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #lightning-dev 11:29 -!- maaku [~mark@173.234.25.100] has joined #lightning-dev 11:35 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 12:34 < mryandao> lol 04:11 < cdecker> This is channel for technical discussion, not conspiracy theories 12:38 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 13:10 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 245 seconds] 13:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 14:37 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell pushed 3 new commits to master: https://git.io/vD6e1 14:37 -lightningrfc:#lightning-dev- lightning-rfc/master c977e7e Otto Allmendinger: BOLT 02: Remove reference to nonexistent field... 14:37 -lightningrfc:#lightning-dev- lightning-rfc/master 560439d Otto Allmendinger: BOLT 02: change "responser" to "responder" 14:37 -lightningrfc:#lightning-dev- lightning-rfc/master 5114f58 Otto Allmendinger: BOLT 02: fix state listing in "Normal Operation"... 14:46 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:51 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 15:05 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:07 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 15:49 -!- koshii [~w@c-50-151-108-105.hsd1.in.comcast.net] has quit [Read error: Connection reset by peer] 15:51 -!- koshii [~w@c-50-151-108-105.hsd1.in.comcast.net] has joined #lightning-dev 15:51 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:55 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 16:14 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds] 16:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 16:37 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 17:00 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:35 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 17:36 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #lightning-dev 17:52 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has joined #lightning-dev 18:04 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.] 18:05 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 18:43 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 18:43 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ccsrwyotvqjjnqtj] has quit [Quit: Connection closed for inactivity] 18:52 -!- HostFat_ [~HostFat@host103-250-dynamic.59-82-r.retail.telecomitalia.it] has joined #lightning-dev 18:56 -!- HostFat [~HostFat@host248-244-dynamic.20-87-r.retail.telecomitalia.it] has quit [Ping timeout: 255 seconds] 19:01 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.cablep.bezeqint.net] has quit [Ping timeout: 240 seconds] 19:07 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has joined #lightning-dev 19:29 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 19:43 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 20:48 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has joined #lightning-dev 20:50 -!- takayaim_ [~takayaima@KD106186241030.ec-userreverse.dion.ne.jp] has joined #lightning-dev 20:53 -!- takayaimai [~takayaima@em1-115-195-222.pool.e-mobile.ne.jp] has quit [Ping timeout: 240 seconds] 22:01 -!- takayaim_ [~takayaima@KD106186241030.ec-userreverse.dion.ne.jp] has quit [Remote host closed the connection] 22:04 -!- takayaimai [~takayaima@KD106186241030.ec-userreverse.dion.ne.jp] has joined #lightning-dev 22:18 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 22:34 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 276 seconds] 22:38 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-udyakugufacqiesq] has joined #lightning-dev 23:32 -!- takayaimai [~takayaima@KD106186241030.ec-userreverse.dion.ne.jp] has quit [Remote host closed the connection] 23:33 -!- takayaimai [~takayaima@KD106186241030.ec-userreverse.dion.ne.jp] has joined #lightning-dev 23:41 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]