--- Day changed Tue Oct 06 2015
00:57 < btcdrak> !m
01:18 -!- AaronvanW [~ewout@x55b29070.dyn.telefonica.de] has joined #lightning-dev
01:18 -!- AaronvanW [~ewout@x55b29070.dyn.telefonica.de] has quit [Changing host]
01:18 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
01:27 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev
01:30 -!- pepesza [~pepesza@bjq4.neoplus.adsl.tpnet.pl] has joined #lightning-dev
01:30 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
01:30 -!- lightningbot` [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #lightning-dev
01:31 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-oyioezokfvhpxtpg] has quit [Ping timeout: 240 seconds]
01:33 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-lfrdpkhmrqhuygvk] has joined #lightning-dev
01:46 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 240 seconds]
02:03 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #lightning-dev
02:56 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #lightning-dev
04:36 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 246 seconds]
05:26 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 250 seconds]
06:02 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #lightning-dev
06:12 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev
06:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
06:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
07:43 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
07:49 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
08:22 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit []
08:22 -!- CodeShark_ is now known as CodeShark
08:34 -!- pepesza [~pepesza@bjq4.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 240 seconds]
08:46 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev
09:20 -!- esneider [~esneider@181.94.16.90] has quit [Remote host closed the connection]
09:29 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev
09:56 -!- esneider_ [~esneider@181.94.16.90] has joined #lightning-dev
09:59 -!- esneider [~esneider@181.94.16.90] has quit [Ping timeout: 240 seconds]
11:02 -!- esneider_ [~esneider@181.94.16.90] has quit [Read error: Connection reset by peer]
11:07 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev
11:33 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
11:44 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Quit: WeeChat 1.1.1]
11:57 -!- matsjj [~matsjj@p5B209E34.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
12:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xopfwkosonrxyhra] has quit [Quit: Connection closed for inactivity]
12:10 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mmzrbacroyyshfei] has joined #lightning-dev
12:16 -!- esneider [~esneider@181.94.16.90] has quit [Remote host closed the connection]
12:31 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
12:37 -!- mode/#lightning-dev [+o rusty] by ChanServ
12:37 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev
12:38 -!- rusty changed the topic of #lightning-dev to: Bitcoin Lightning Development: Be Excellent To Each Other!  Logging at  https://botbot.me/freenode/lightning-dev
12:38 -!- mode/#lightning-dev [+o rusty] by rusty
12:38 -!- mode/#lightning-dev [-o rusty] by rusty
12:44 < rusty> aj: re: flip_key... we want a key with correct sign.  If we get the wrong one we flip it.  We could just retry, but gmaxwell taught me math instead.
12:44 < rusty> aj: ah, unless you mean I didn't clean up test_onion.  Good point.
12:46 -!- esneider [~esneider@181.94.16.90] has quit [Remote host closed the connection]
12:52 -!- esneider [~esneider@181.94.16.90] has joined #lightning-dev
12:53 -!- esneider [~esneider@181.94.16.90] has quit [Remote host closed the connection]
12:58 -!- matsjj [~matsjj@p20030089EA5643A29D6C391E959668B8.dip0.t-ipconnect.de] has joined #lightning-dev
13:03 -!- matsjj [~matsjj@p20030089EA5643A29D6C391E959668B8.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
13:14 -!- maaku_ [~quassel@c-50-156-64-222.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
13:27 -!- maaku_ [~quassel@c-50-156-64-222.hsd1.ca.comcast.net] has joined #lightning-dev
13:44 -!- Netsplit *.net <-> *.split quits: Ylbam, jouke_, aj, AaronvanW
13:46 -!- Netsplit over, joins: aj, Ylbam, AaronvanW, jouke_
13:47 < rusty> aj: ah, let me correct my correction.  Yes, we can skip that code.  Will apply your patch then actually remove it.
14:00 -!- matsjj [~matsjj@p5B209E34.dip0.t-ipconnect.de] has joined #lightning-dev
14:04 -!- matsjj [~matsjj@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
14:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mmzrbacroyyshfei] has quit [Quit: Connection closed for inactivity]
15:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uvgtfzykjybpxjvn] has joined #lightning-dev
15:27 -!- mjerr [~mjerr@p5B209E34.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
15:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds]
16:33 -!- maaku__ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev
16:40 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
16:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-uvgtfzykjybpxjvn] has quit [Quit: Connection closed for inactivity]
18:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:07 < rusty> aj: Traceback (most recent call last):
18:07 < rusty>   File "test/test_onion.py", line 343, in <module>
18:07 < rusty>     main(sys.argv[1:])
18:07 < rusty>   File "test/test_onion.py", line 337, in main
18:07 < rusty>     return args.func(args)
18:07 < rusty>   File "test/test_onion.py", line 303, in generate
18:07 < rusty>     k = ec_decompress(k)
18:07 < rusty>   File "test/test_onion.py", line 147, in ec_decompress
18:07 < rusty>     pubkey = "\x04" + pubkey[1:] + get_pos_y_for_x(pubkey[1:], yneg=yneg)
18:07 < rusty>   File "test/test_onion.py", line 133, in get_pos_y_for_x
18:07 < rusty>     field_size = OpenSSL.EC_GROUP_get_degree(OpenSSL.EC_KEY_get0_group(key))
18:07 < rusty> AttributeError: _OpenSSL instance has no attribute 'EC_GROUP_get_degree'
18:07 < rusty> Makefile:107: recipe for target 'test-onion2' failed
18:08 < rusty> aj: latest ubuntu
18:10 -!- CodeShark is now known as CodeShark_
18:10 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
18:43 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Quit: No Ping reply in 180 seconds.]
18:46 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #lightning-dev
18:46 -!- maaku is now known as Guest309
18:47 -!- Guest309 is now known as maaku
18:48 < aj> rusty: what version of libssl do you have?
18:48 < aj> rusty: and python-pyellipse?
18:49 < aj> rusty: and python-pyelliptic even?
18:50 < rusty> aj: ssl-dev  1.0.1f-1ubuntu11.4 pyelleptic 1.5.5-2
18:50 < aj> rusty: i'm guessing it wants pyelliptic 1.5.7-1
18:50 < rusty> aj: Neatening the onion code now.  AFAICT there's no reason to generate a disposable keypair for each hop.
18:50 < rusty> aj: let me try that...
18:51 < aj> rusty: wha?
18:51 < aj> rusty: what else are you going to use?
18:52 < rusty> aj: I'm wondering if we can reuse the same disposable keypair, but maybe I need more coffee...
18:53 < aj> rusty: hum, seems risky, but maybe you're right
18:53 < aj> rusty: you'd get correlations, but those are obvious from R already
18:53 < rusty> aj: I mean, the shared secret will be different for each, assuming their keys are different.  Maybe it's safest to leave as is though, esp. since it's meremly an optimization.
18:54 < aj> rusty: oh, it might screw up re-routing, because the re-router wouldn't know the secret key
18:54 < rusty> aj: that's always true, right?  You can only ever re-route one hop, and only ever add hops.
18:55 < aj> rusty: if you're allowed to extend the message length you can add multiple hops
18:55 < aj> rusty: (afaics)
18:56 < rusty> aj: yep, but you still need the next hop to decode onwards.
18:56 < aj> rusty: yeah?
18:57 < rusty> aj: so you can add as many hops as you want, you can't skip anyone.  Which makes it a bit marginal.  Unless, of course, the next hop is really nice and bounces it back to you unwrapped saying "Naah, I don't want the fees".
18:57 < aj> rusty: (you're creating a new disposable key and encrypting to them which they'll decode; final hop in the rerouting has to reduce the size, but that's okay)
18:57 < rusty> aj: well, you can use a special reroute protocol which doesn't encrypt, of course.
18:57 < aj> rusty: no, all this is still encrypted
19:00 < rusty> aj: Not sure it's worth it, but OK.  I'm just not sure rerouting will ever make enough sense to implement, except perhaps in the dumbest case where two nodes trust each other anyway.
19:03 < rusty> aj: pip install pyelliptic did the job, so yes, seems to be a pyelliptic version issue.
19:04 < rusty> That gave me 1.5.7.
19:05 < aj> rusty: hmm, i don't remember the uses for rerouting / arguments against source routing...
19:06 < rusty> aj: there was originally some talk from Joseph about routing around busy channels.  But that was before onion routing.
19:07 < aj> rusty: hmm; and actually adding one hop repeatedly might be enough anyway? "D get this to E" "duhhh, i dunnno how to, but i bet X does. X get this to E" "Y get this to E" "Z get this to E" "ok!"
19:07 < aj> rusty: oh, but D would have to pass along enckey and pad_iv to Z so that Z could add the right padding
19:07 < rusty> aj: maybe, but the fees get screwed up, and it's not clear you have enough routing info to know.
19:08 < aj> rusty: D gets paid a fee to forward to E; if he can't do that directly, but is willing to share his fe with X Y and Z, that seems like no problem at all?
19:08 < rusty> aj: if X Y and Z are cheap enough, sure.
19:09 < aj> rusty: and if they're not, it fails like any other time you didn't pay enough fee
19:10 < rusty> aj: "WTF is Z sending me an error for?" and how does D know the alternate path to E?  I mean, it's a possible extension, but it's not immediately obvious anyone will actually use it.
19:11 < rusty> aj: onion merged and pushed
19:11 < aj> rusty: yeah, i don't see any compelling use from old emails either
19:12 < aj> rusty: so file in the interesting thought experiment but not needed atm afaics. might be interesting when/if there are multiple networks and you want to tunnel from one to the other (bitcoin v dogecoin? public v super-secret-criminals-only networks?)
19:14 < rusty> aj: hmm, should we tweak the IV calc to split into 2?  Or just use AES256 and be done...
19:14 < rusty> aj: that's what the extra space in the message is for.  A network identifier, for example.
19:15 < rusty> aj: I'd like to merge the onion branch into master, so this is a chance for final bikeshed before we turn it into a real proposal.
19:18 < aj> rusty: https://www.reddit.com/r/crypto/comments/39211m/is_really_aes256_less_secure_than_aes128/  and https://www.schneier.com/blog/archives/2009/07/another_new_aes.html claim aes128 is /better/ than aes256... :(
19:19 < rusty> aj: for related-key attack, yes, AES256 has weakness.
19:20 < rusty> aj: don't do that though, AFAICT.
19:20 < aj> rusty: sorry, re multi networks i was thinking if you route along dogecoin, but dogecoin-lightning nodes secretly tunnel that over bitcoin-lightning (including currency exchange)
19:20 < aj> rusty: ie, totally towers built on clouds and not remotely worth thinkng about now
19:21 < rusty> aj: Only doge users would do that crazy shit1
19:22 < aj> rusty: it's crazy sure, but is it crazy-like-a-fox? </betteridge's law>
19:22 < rusty> My bad, make that "...be that crazy!".
19:29 < aj> rusty: oh, i had a thought that it might make sense to add an extra key, and do real encryted-zero padding on the first hop; makes it slightly more deniable that maybe you forwarded a message rather than initiated it
19:31 < rusty> aj: I don't think you can tell?  Last hop may tell junk from valid (in tiny chance junk is not valid key), but they know they're last.
19:34 < aj> rusty: you can't tell easily, but you could put a gun to someone's head and say "you claim to have forwarded this? show me the original message you got and the keys you used to decrypt it"
19:35 < aj> rusty: if you always encrypt zeroes for a hop, then add junk you can answer that even for messages you initiate
19:37 < rusty> aj: OK, deniability is good.  They might ask for the pre-decrypted image, so we really do need to add a full pre-hop I think.
19:39 < rusty> aj: see latest tree, with IV split.
19:42 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Ping timeout: 265 seconds]
19:43 < aj> rusty: ack
19:44 < aj> rusty: (i made you code python! yes!!)
19:53 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
19:54 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #lightning-dev
19:54 -!- maaku is now known as Guest41021
20:13 -!- maaku_ [~quassel@c-50-156-64-222.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
20:13 < rusty> aj: Oh, I'm a python fan.  Just not very good at it...
20:16 -!- maaku_ [~quassel@2601:646:8080:59:d250:99ff:fe27:3cff] has joined #lightning-dev
20:17 < aj> rusty: oh, eww, how did i miss it was doing sha four times instead of three still
20:18 < rusty> aj: that's "python style".
20:20 < aj> rusty: you can't just use "python style" as a synonym for "inefficient" !
20:20 < rusty> aj: "lacking premature optimization"
20:23 < aj> rusty: btw, i thought of a BIP/RFC acronym -- "BOLT - brief on lightning technology"
20:23 < rusty> aj: oh, nice backronym!
20:24 < rusty> Though, RFC is way less pretentious :)
20:24 < aj> rusty: i dunno, RFCs can get pretty pretentious...
20:26 < rusty> aj: but at least there's humility built into the name, which I like.
20:29 < aj> rusty: yeah... you'll have me pining for the internet's glory days soon
20:30 < rusty> aj: so, I'm about to break ground on a simple point-to-point daemon to try to bring the next phase into focus.
20:30 < rusty> (and figure out what we're missing so far, eg. a welcome message)
20:31 < aj> rusty: so that's the first steps for the p2p layer?
20:34 < rusty> aj: yeah... this will have a lightning-cli and lightningd, and you'll be able to manually connect to another lightningd, set up HTLCs etc.
20:34 < aj> rusty: frightning!
20:35 < rusty> There's a fair bit of infrastructure just in doing that (eg. talking to bitcoind, talking to RPC, etc)
20:35 < aj> rusty: RPC?
20:35 < rusty> aj: for lightning-cli...
20:35 < aj> rusty: aha
20:35 < rusty> JSON seems to be the thing, for better or worse, in the bitcoin world.
20:35 < aj> json++
20:52 < CodeShark> I'd recommend separating the transport from the message structures :)
20:53 < CodeShark> you can always add support for other types of transport
20:53 < CodeShark> starting with JSON is a good way to get out the door quickly
20:53  * aj assumes that's what rusty is planning anyway!
20:54 < rusty> CodeShark: yeah, JSON is reasonably debuggable.  And it's just for controlling the daemon, a-la bitcoin-cli.
20:55 < CodeShark> oh, this is not for the p2p layer
20:56 < CodeShark> that's right, you're using protobuf for that, right?
20:57 < CodeShark> kk
21:04 < CodeShark> so perhaps a more fundamental issue is whether to use REST. I like to use websockets to control my daemons because they are widely supported, it's easy to build web front ends, and they can handle async event handling stuff far better than REST
21:04 < CodeShark> however, for a command line tool REST is fine
21:09 < rusty> CodeShark: yeah, a commandline tool doesn;t really work with state very well.
21:17 < aj> for this REST just smean "doing RPC via stateless JSON over HTTP" i think?
21:17 < CodeShark> yes
21:18 < CodeShark> the way bitcoin-cli currently works :p
21:21 < CodeShark> lightning is inherently more stateful, though
21:21 < aj> i'm not sure it is
21:22 < aj> if you want to referene an HTLC, you just use the R value; you don't need state per se
21:22 < CodeShark> I suppose you're right
21:22 < aj> ahhhh
21:22 < aj> gosh this is so exciting!
21:23 < CodeShark> ???
21:23 < aj> nothing in particular, just excited :)
21:23 < CodeShark> heh
21:24 < CodeShark> I'm doing what I can to expedite the BIPs to make this all possible ;)
21:27 < aj> CodeShark: yeah!
21:28 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 268 seconds]
21:37 -!- Madars [~null@unaffiliated/madars] has joined #lightning-dev
21:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
22:17 -!- matsjj [~matsjj@p5B209A5A.dip0.t-ipconnect.de] has joined #lightning-dev
22:28 -!- mjerr [~mjerr@p5B209A5A.dip0.t-ipconnect.de] has joined #lightning-dev
23:16 < mjerr> just read through the logs (I really live in the worst time zone for that) ... so we are not using a new keypair per hop, because...? But we need to send our public key used for the encryption in the free with the message, don't we? while the nodes can correlate two messages based on the R value, at least any outstanding observer can't
23:18 < aj> mjerr: still doing a keypair per hop so far; suggestion to do otherwise is a FIXME comment in test_onion.c though
23:19 < mjerr> just for understanding. We send the encrypted message together with the unencrypted public key, right?
23:21 < mjerr> if we can make sure the public key is somehow encrypted as well, I think one keypair per route is okay. But with it in the open, any listener can correlate messages across the network
23:23 < aj> mjerr: yeah, the onion format is "encrypted payload; unencrypted temporary pubkey; hmac"
23:24 < aj> mjerr: anyone listening can correlate on R value as well; unless the p2p connections are encrypted as well, in which case you can't even see the onion message
23:26 < mjerr> so anyone fetching the tcp packets can map these messages. but the R value only makes it to a listener if the channel makes it to the blockchain? 
23:27 < mjerr> because it is saved in the encrypted payload
23:28 < aj> the R value has to be passed along in TCP as well though, even if it doesn't make it to the blockchain
23:29 < aj> (ie, both sides need to know R when updating the commitment txns to establish the HTLC)
23:29 < mjerr> so which messages are encrypted using the onion routing if not the information necessary to make the payment(R/amount/...)
23:29 < aj> the onion routing just does the forwarding and fee information i think
23:30 < mjerr> hm. but 'forwarding' is just sending the payment to the next node?
23:32 < mjerr> or am I missing some difference between forwarding the payment over onion and sending an updated channel tx?
23:36 < aj> words are hard :(
23:37 < aj> yeah, forwarding gets the transaction to the next node
23:37 < aj> and the onion (after decryption) tells that node how to forward further
23:38 < aj> but you have to update the channel before forwarding, and i think you do that without the onion mostly
23:38 < aj> there's no point encoding the same R one for every hop in the onion eg; everyone's going to know what it is anyway
23:39 < mjerr>  okay so the process is 1. update channel including a new payment with a node 2. send forward information what to do with that payment ... and 1 is unencrypted while 2 is encrypted? 
23:41 < aj> mjerr: i think it's "send the update HTLC request with onioned forwarding info from node 1 (Alice) to node 2 (Bob). Bob acks/naks and HTLC is setup and forwarded correspondingly.
23:41 < aj> mjerr: "
23:42 < aj> mjerr: but all of that is probably done over an encrypted TCP/IP connection between Alice and Bob anyway
23:42 < mjerr> I see, I was missing that information ;)
23:42 < aj> mjerr: (ie, TLS)
23:42 < aj> mjerr: well, i just made that information up then :)
23:43 < aj> mjerr: but i think it makes sense
23:43 < mjerr> but it's right, these are long lasting connections, might as well create a shared secret and encrypt everything using it
23:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kxvliibgfxbzmmra] has joined #lightning-dev