--- Day changed Sat Aug 15 2015
01:48 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #lightning-dev
02:29 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds]
08:14 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:50 -!- mjerr [~mjerr@p578EA5C9.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
10:53 -!- jlrubin_ [~jlrubin@biohazard-cafe.mit.edu] has quit [Ping timeout: 244 seconds]
10:59 -!- jlrubin_ [~jlrubin@biohazard-cafe.mit.edu] has joined #lightning-dev
13:59 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
16:02 -!- ftlio [~ftlio@gateway/vpn/privateinternetaccess/ftlio] has quit [Remote host closed the connection]
17:17 < maaku> kanzure: in principle routing shouldn't require a central directory
17:17 < kanzure> is there a way of doing onion routing without a directory?
17:18 < kanzure> also: a blockchain counts as a directory in this context
17:18 < maaku> trustlessly? i don't know. but take this:
17:19 < maaku> you can do a search where you broadcast to your connections where you want to end up, and they forward to their connections, etc. each step onion encrypting
17:19 < maaku> when it reaches the goal state, it responds back
17:20 < maaku> if you encrypt to the destination key, i tmight even be the case that nodes along the way don't even know who you're looking for
17:20 < maaku> not very efficient though
17:20 < kanzure> each step onion encrypting defeats the purpose because each step will see your message before encrypting it for the next hop
17:21 < maaku> kanzure: your message is encrypted to the destination
17:21 < kanzure> how would you know the destination? hubs would just pick another key and do man-in-the-middle.
17:22 < kanzure> in -wizards i mused that perhaps there's a way for the network to know that it has to restructure, after a certain amount of querying has been done or something
17:22 < maaku> well presumably you know who you are sending money to. this doesn't solve the identity problem...
17:22 < kanzure> like, i norder to acquire some knowledge, you have to make it so that all nodes know that you know this knowledge, thus telling them it's time to restructure for safety
17:22 < maaku> this is not a problem i have spent adequate time on however
17:22 < kanzure> (unfortunately this restructuring canary may not be possible)
17:23 < kanzure> you might know who you are sending money to, but that doesn't solve routing i think
17:23 < kanzure> because routing is about finding a path from your payment channel to some other payment channel, and also selecting competing alternatives
17:23 < kanzure> ideally, without revealing your payment details- whether the whole transaction's details, or merely the amount, or merely the participants.
17:24 < kanzure> wait... what? okay so you encrypt for your destination (whoever you are paying), you flood the network with messages about routing that encrypted payload, everyone has to pass the message around because it's encrypted. already the scaling attributes of this design are not so great :-).
18:02 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has quit [Read error: Connection reset by peer]
18:02 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
19:09 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has joined #lightning-dev
20:15 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds]
20:27 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
20:38 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Remote host closed the connection]
20:39 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds]
20:42 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev