--- Day changed Mon Jan 04 2016
00:18 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 256 seconds]
00:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yijruespwcvvwsiq] has joined #lightning-dev
00:40 -!- matsjj [~matsjj@94.197.121.142.threembb.co.uk] has joined #lightning-dev
00:45 -!- matsjj [~matsjj@94.197.121.142.threembb.co.uk] has quit [Ping timeout: 264 seconds]
01:50 -!- matsjj [~matsjj@89.197.31.78] has joined #lightning-dev
03:08 -!- AaronvanW [~ewout@x4db44d5a.dyn.telefonica.de] has joined #lightning-dev
03:08 -!- AaronvanW [~ewout@x4db44d5a.dyn.telefonica.de] has quit [Changing host]
03:08 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
05:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
05:48 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
06:15 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
06:50 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has quit [Remote host closed the connection]
06:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
07:35 -!- AaronvanW [~ewout@x4db44d5a.dyn.telefonica.de] has joined #lightning-dev
07:35 -!- AaronvanW [~ewout@x4db44d5a.dyn.telefonica.de] has quit [Changing host]
07:35 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
08:06 -!- dcousens_ [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #lightning-dev
08:07 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 260 seconds]
08:18 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has joined #lightning-dev
08:21 -!- domwoe [~domwoe@84-75-162-45.dclient.hispeed.ch] has joined #lightning-dev
08:33 -!- matsjj_ [~matsjj@89.197.31.78] has joined #lightning-dev
08:35 -!- matsjj [~matsjj@89.197.31.78] has quit [Ping timeout: 276 seconds]
09:58 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 264 seconds]
09:58 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #lightning-dev
10:14 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
10:22 -!- domwoe [~domwoe@84-75-162-45.dclient.hispeed.ch] has quit [Remote host closed the connection]
11:04 -!- matsjj_ [~matsjj@89.197.31.78] has quit [Read error: Connection reset by peer]
11:05 -!- matsjj [~matsjj@89.197.31.78] has joined #lightning-dev
11:09 -!- matsjj [~matsjj@89.197.31.78] has quit [Ping timeout: 255 seconds]
11:28 -!- matsjj [~matsjj@31.74.163.66] has joined #lightning-dev
11:32 -!- matsjj [~matsjj@31.74.163.66] has quit [Client Quit]
11:45 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds]
11:46 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has joined #lightning-dev
11:47 -!- [1]AndyOfiesh [~aofiesh@pool-74-104-150-62.bstnma.fios.verizon.net] has joined #lightning-dev
11:48 -!- AndyOfiesh [~aofiesh@pool-74-104-150-62.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds]
11:48 -!- [1]AndyOfiesh is now known as AndyOfiesh
12:50 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #lightning-dev
12:56 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds]
13:07 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
13:08 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
13:14 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
13:17 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
14:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:00 -!- stevenroose_ [~steven@193.190.253.144] has joined #lightning-dev
14:00 < stevenroose_> hi
14:00 < stevenroose_> are the lightning developers currently already thinking about how nodes in the network would communicate?
14:01 < stevenroose_> because everything happens off-chain
14:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:21 < instagibbs> Yes! Might be best to skim the mailing list for archival reasons: https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
14:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds]
15:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:55 < rusty> stevenroose_: yes :)
16:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
16:41 < stevenroose_> rusty: what kind of protocols are being looked at?
16:42 < stevenroose_> is being thought about creating something entirely new? 
16:42 < stevenroose_> or reusing existing protocols?
16:42 < rusty> stevenroose_: that's a broad question, but I'll try to answer.  The inter-node comms is drafted currently by a protobuf file (eg. https://github.com/ElementsProject/lightning/blob/master/lightning.proto )
16:43 < rusty> stevenroose_: my crypto layer is currently just using the ECDH over the bitcoin curve, and AES + SHA-256-HMAC.
16:44 < dcousens_> rusty: is protobuf even worth it if you can know your datastructures up front?
16:44 < rusty> stevenroose_: (though Joseph, Tadge and roasbeef have a thing for using chacha20/poly1305, which is fine with me too, as long as we agree on one)
16:44 < rusty> dcousens_: Joseph said the same thing :)  It was good for prototyping the protocol, but we could open-code for 1.0
16:45 < dcousens_> rusty: nothing against protobuf, just, it adds a dependency to everyone who might want to interact with the network 
16:45 < rusty> Turns out (if we only allow compressed pubkeys) we only have one variable-size message, and that's the PKT_ERR string.
16:46 < dcousens_> rusty: i think that is a sane decision
16:46 < rusty> dcousens_: sure, but it also provides a simple extensibility mechanism.  Otherwise you need to come up with your own.
16:46 < dcousens_> rusty: true
16:46 < dcousens_> but that goes against the 'know everything up front' part :P
16:47 < dcousens_> a semver like versioning number could cover most cases
16:47 < rusty> dcousens_: I have a fair bit of experience with designing network protocols, and I'm happy to outsource to some random standard.  protobufs have support for every language, OTOH Google has moved to v3 already, and language decoders may have vulns too.
16:47 < dcousens_> rusty: cool, was just curious :)
16:48 < rusty> dcousens_: well, current protocol is that unknown odd fields are OK, unknown even fields are fatal.
16:49 < rusty> dcousens_: my preference for a flat system would be: at handshake, two bitstrings, one for optional and one for compulsory features.  In addition, for each packet, extra fields at the end are ignored, unknown packet types are fatal.
16:50 < rusty> Oh, but one other thing: dealing with fixed-size non-int fields in protobuf (v2 or v3) or even capn'proto is a real PITA.
16:50 < dcousens_> yeah noticed that in the file above
16:50 < dcousens_> 64bit fields 
16:51 < rusty> dcousens_: you can use variable-length fields, but part of the idea of outsourcing to prtoobufs is to have it do that validation.
16:53 < dcousens_> rusty: in my own experience in developing network protocols (though, never a p2p), I've always opted for super strict + simplest possible flat data structures,   basically anything that can be very simply have a parser written and understood without complication.   
16:53 < dcousens_> I guess the other side is, it'd be nice to be able to do all this via HTTP proxies too, so, JS friendly for browsers/mobile devices is always a plus
16:53 < dcousens_> Which basic `Buffer`s are
16:54 < rusty> dcousens_: indeed, me too.  I wasn't sure on starting whether or not we'd need something more sophisticated.  Turns out so far we don't.
16:56 < pigeons> and i was so looking forward to lightening-asn.1
16:56 < dcousens_> haha
16:57 < dcousens_> can a lightning participant send funds via lightning to a non-lightning participant?
16:57 < dcousens_> or would they have organize that through other means?
16:57 < dcousens_> (aka, just a traditional tx)
16:58 < dcousens_> I ask, simply because it'd be cool to have the ability to perform basic coinswaps using your pre-existing payment channel with someone
17:03 < dcousens_> rusty: I recently wrote up this, https://gist.github.com/dcousens/1287ead78b1104ba5c95,  its a 2tx amortized coinswap (start to finish), 3tx if you close everything after
17:04 < dcousens_> You could easily use this or something similar to send txs to people out of hte lightning network, but using your channel (means you can have more funds locked up without issue, + privacy for the coinswap)
17:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yijruespwcvvwsiq] has quit [Quit: Connection closed for inactivity]
17:04 < rusty> dcousens_: You can swap to any chain, in theory; we've been calling it "swap-to-X".  However, you can't just issue a payment to a random bitcoin address AFAICT without trust.
17:05 < rusty> (which is what is desired for the transition)
17:06 < rusty> Which makes wallet support tricky: how much do I keep in the channel vs how much for other payments?
17:06 < dcousens_> rusty: you mean,  in the case where Alice and Charlie have a lightning channel open,  Alice can't trustlessly send Bob (who is not in the LN) a payment via Charlie?
17:06 < dcousens_> Maybe I'm not aware of the intricacies around the LN channels, but, read the above, its quite possible to do so trustlessly
17:08 < rusty> dcousens_: no, you assume Bob is not using a standard wallet though, nor "random bitcoin address".
17:08 < rusty> s/nor/not/
17:08 < dcousens_> no I don't
17:08 < dcousens_> I assume Bob is a P2PKH
17:08 < dcousens_> QR code address, standard
17:09 < dcousens_> whatever bob wants, P2SH if he desires
17:10 < dcousens_> The point is the entire action should happen without Bob knowing a thing
17:10 < rusty> dcousens_: OK, I'm clearly missing something.
17:11 < dcousens_> dcousens_: happy to explain it if that gist isn't clear enough
17:12 < rusty> dcousens_: actually, maybe we could do this in the lightning scenario (without closing channel), by reanchoring.
17:13 < rusty> dcousens_: we don't currently support altering the anchor, but it's certainly possible (eg. to add new funds to channel, or remove some).  For the transition you need to maintain sets of commitment txs for both anchors, of course.
17:13 < dcousens_> rusty: not aware of the LN term anchor
17:13 < dcousens_> (what is the most up to paper btw? I've heard its changed a bit since I first read it)
17:13 < rusty> dcousens_: the funding transaction for the channel, which pays to 2x2 and sits in the blockchain.
17:14 < rusty> dcousens_: Suggest the deployable lightning paper: https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
17:15 < dcousens_> ta
17:15 < dcousens_> rusty: theres a flaw to the above gist, in that I have to have pre-opened channels of unspents
17:16 < dcousens_> though maybe not, still thinking about that
17:17 < dcousens_> in any case, its faster than the 4tx coinswap and requires less tx's
17:20 < dcousens_> anyway, food for thought :)
17:21 < rusty> dcousens_: sure; the consensus seems to be that the first v1.0 of the protocol wont' support swap-to-X scenarios, to avoid trying to boil the ocean, but I know people get excited about the possibilities :)
17:22 < dcousens_> rusty: smart move :)
17:23 < dcousens_> ooi, you mentioned your crypto layer above, is that juts for TLS or do you actually need auth. for other things?
17:30 < rusty> dcousens_: avoiding TLS, actually.  It's not a direct fit, since we know the node id of both ends.
17:30 < dcousens_> I didn't mean TLS as in SSL or whatever
17:30 < dcousens_> I mean't conceptually
17:30 < rusty> dcousens_: yeah, node-to-node crypto.
17:30 < dcousens_> your transport layer security
17:32 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 256 seconds]
18:10  * rusty fails networking 101.  My daemon successfully "connected" to a non-existent port, then I realized that my DNS lookup didn't specify SOCK_STREAM, so it was trying to use UDP...
18:12 < dcousens_> haha
18:12 < dcousens_> "connected" :)
18:12 < dcousens_> what are you using for sockets?
18:12 < dcousens_> just plain old sockets? ha
18:13 < rusty> dcousens_: yeah, this is getaddrinfo and connect: I initially suspected my ccan/io module until I looked closer http://ccodearchive.net/info/io.html
18:14 < dcousens_> have you used libuv?
18:15 < dcousens_> oh haha, this is by you
18:15 < dcousens_> hmmm, .au
18:15 < dcousens_> Where you based out of?
18:15 < dcousens_> Melbourne here
18:33 < rusty> Adelaide, actually.
18:50 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
19:23 -!- stevenroose_ [~steven@193.190.253.144] has quit [Ping timeout: 260 seconds]
21:21 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #lightning-dev
21:36 -!- dcousens_ is now known as dcousens
22:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jrpevwvieicboxpm] has joined #lightning-dev
23:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 276 seconds]