--- Day changed Wed Oct 14 2015 00:04 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has joined #lightning-dev 00:11 -!- mjerr [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has joined #lightning-dev 00:23 -!- mjerr_ [~matsjj@104.238.169.8] has joined #lightning-dev 00:25 -!- mjerr [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has quit [Ping timeout: 255 seconds] 00:25 -!- mjerr [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has joined #lightning-dev 00:27 -!- cubicearth [~corey@c-67-168-82-178.hsd1.wa.comcast.net] has joined #lightning-dev 00:28 -!- mjerr_ [~matsjj@104.238.169.8] has quit [Ping timeout: 240 seconds] 01:01 -!- mjerr_ [~matsjj@179.43.156.130] has joined #lightning-dev 01:03 -!- mjerr [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has quit [Ping timeout: 252 seconds] 01:10 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev 01:28 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 01:56 -!- mjerr_ [~matsjj@179.43.156.130] has quit [Remote host closed the connection] 02:15 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 02:22 -!- mjerr [~matsjj@89.197.31.78] has joined #lightning-dev 02:24 -!- mjerr_ [~matsjj@179.43.177.2] has joined #lightning-dev 02:26 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 02:27 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit] 02:27 -!- mjerr [~matsjj@89.197.31.78] has quit [Ping timeout: 260 seconds] 02:27 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 02:35 -!- pepesza [~pepesza@cpa186.neoplus.adsl.tpnet.pl] has joined #lightning-dev 03:02 -!- jtimon [~quassel@18.31.134.37.dynamic.jazztel.es] has joined #lightning-dev 03:26 -!- ftlio [~ftlio@ftlio.com] has quit [Remote host closed the connection] 03:59 -!- cubicearth [~corey@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Quit: Leaving] 04:10 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 240 seconds] 04:12 -!- go1111111 [~go1111111@162.244.138.37] has joined #lightning-dev 05:33 -!- mjerr [~matsjj@79.173.166.74] has joined #lightning-dev 05:33 -!- mjerr_ [~matsjj@179.43.177.2] has quit [Ping timeout: 240 seconds] 05:53 -!- mjerr [~matsjj@79.173.166.74] has quit [Remote host closed the connection] 05:54 -!- mjerr [~matsjj@89.197.31.78] has joined #lightning-dev 06:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 06:49 -!- mjerr_ [~matsjj@179.43.156.2] has joined #lightning-dev 06:51 -!- mjerr [~matsjj@89.197.31.78] has quit [Ping timeout: 252 seconds] 06:57 < mjerr_> aj, do you know what rusty means with 64-bit LE and how does it supply sufficient protection against replay attacks? https://github.com/ElementsProject/lightning/commit/ae248f6dd572772c4be89287e2f33782fe0c5171 06:57 < mjerr_> just implementing it as well 06:57 < mjerr_> finally got past the ECDH part 06:59 < mjerr_> and is there anything we gain from using a separate key for encryption and HMAC? 06:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 07:21 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 08:02 -!- mjerr [~matsjj@79.173.166.74] has joined #lightning-dev 08:02 -!- mjerr [~matsjj@79.173.166.74] has quit [Remote host closed the connection] 08:03 -!- mjerr [~matsjj@79.173.166.74] has joined #lightning-dev 08:04 -!- mjerr_ [~matsjj@179.43.156.2] has quit [Ping timeout: 256 seconds] 08:30 -!- pepesza_ [~pepesza@abbc119.neoplus.adsl.tpnet.pl] has joined #lightning-dev 08:31 -!- pepesza [~pepesza@cpa186.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 240 seconds] 08:44 -!- pepesza_ [~pepesza@abbc119.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 240 seconds] 09:00 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds] 09:02 -!- mjerr [~matsjj@79.173.166.74] has quit [Remote host closed the connection] 09:02 -!- mjerr [~matsjj@89.197.31.78] has joined #lightning-dev 09:45 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev 09:50 -!- Netsplit *.net <-> *.split quits: Guest4879, akrmn, maaku, Taek, fkhan 09:59 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #lightning-dev 09:59 -!- fkhan [weechat@gateway/vpn/mullvad/x-axplirbccmseankd] has joined #lightning-dev 09:59 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #lightning-dev 09:59 -!- Guest4879 [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 10:05 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 10:07 -!- Netsplit *.net <-> *.split quits: fkhan, Guest4879, maaku, akrmn 10:08 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #lightning-dev 10:10 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #lightning-dev 10:10 -!- fkhan [weechat@gateway/vpn/mullvad/x-axplirbccmseankd] has joined #lightning-dev 10:10 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #lightning-dev 10:10 -!- Guest4879 [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 10:43 -!- richardkiss [~richardki@ip68-227-33-165.lv.lv.cox.net] has joined #lightning-dev 10:50 < waxwing> in ssl different keys in both directions is to protect against replay attacks afaik 10:50 < waxwing> i guess that's a stricter kind of protection than the 'total so far' thing described there 11:03 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 11:25 -!- mjerr [~matsjj@89.197.31.78] has quit [Ping timeout: 256 seconds] 11:27 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 11:28 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 11:31 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 11:33 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 11:34 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 11:35 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev 12:15 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 13:26 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev 13:49 -!- bedeho [~bedeho@64.236.138.4] has joined #lightning-dev 13:56 -!- ftlio [~ftlio@ftlio.com] has joined #lightning-dev 13:59 -!- bedeho [~bedeho@64.236.138.4] has quit [Ping timeout: 240 seconds] 14:33 -!- JackH [~Jack@host-80-43-142-1.as13285.net] has joined #lightning-dev 14:33 < JackH> on a low level, where does the hub/channel data (transactions) get processed? 14:34 < maaku> JackH: on the two endpoints 14:34 < maaku> also, define "processed" 14:35 < JackH> ok so you and I setup a hub between each other 14:35 < JackH> I get that the signatures are not verified in the case of lightning 14:35 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 14:35 < JackH> so no CPU is used - check 14:35 < JackH> what I dont get is where this data resides before it is settled 14:35 < maaku> CPU is used our our two systems 14:35 < maaku> and it resides with us 14:36 < JackH> well it wont verify the ECDSA signatures as far as I understand 14:36 < JackH> so from that point of view 14:36 < JackH> ok - resides with us where? in RAM? 14:36 < maaku> implementation choice. does it matter? 14:36 < maaku> a payment channel is just two people swapping bitcoin transactions 14:37 < maaku> they are validated by the two participants, it's just no one else knows about the intermediates because neither of us broadcast them 14:37 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev 14:37 < JackH> yep, I get that 14:37 < maaku> JackH: the ECDSA signatures will most definately be validated by the participants 14:37 < maaku> if you and I have a channel, I need to know you are sending me good signatures 14:38 < JackH> ok lets scale this up so my question makes more sense 14:38 < JackH> we have 100 participating nodes 14:38 < JackH> each sends transactions 14:38 < JackH> we reach a total of 1 petabyte every 2 hour 14:38 < JackH> for example 14:38 < JackH> where does the data reside in the meantime 14:38 -!- bedeho [~bedeho@38.104.140.6] has joined #lightning-dev 14:39 < JackH> say our timelock is 2h 14:39 < maaku> each node keeps track of data for its own channels 14:39 < JackH> but before we settle, what do we do with all that data 14:39 < maaku> although much of that data is prunable 14:40 < JackH> is the data ledger structured like in Bitcoin? 14:40 < JackH> if we dont prune it 14:41 < JackH> and secondly, if ECDSA signatures are verified this puts the same stress on our CPU 14:41 < maaku> JackH: I'm not sure how to respond because I'm not sure what view you have in your head of how lightning works. the questions you are asking frankly don't make sense 14:41 < maaku> these transactions being swapped don't constitute a ledger 14:42 < maaku> they are transaction _replacements_, where each payment replaces the last one 14:42 < maaku> and regarding CPU usage, a node only validates transactions on channels it is involved with 14:42 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 240 seconds] 14:42 < maaku> whereas in bitcoin every participant validates every transaction 14:43 < maaku> so in lightning you validate only your transactions, and with on-chain transaction you validate every transaction. your transactions < all total transactions, so that's the scaling benefit 14:44 < maaku> does that make sense? 14:44 < JackH> they are transaction _replacements_, where each payment replaces the last on <- does that mean that there is no historical transaction inside a payment hub, but only constant replacements of where values resides? 14:44 < JackH> ie. auto pruning? 14:47 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 14:48 < aj> JackH: you only keep the current balances, and the transactions that are currently in flight (ie, they haven't made it all the way to the recipient to get an ack) 14:48 < maaku> JackH: there could be 14:49 < JackH> what I am having a hard time figuring out is if the data in flight, that is shared between the payment hubs is thus stored in RAM on the local machine, while in-flight 14:49 < maaku> well some data has to stick around, such as the signatures 14:49 < maaku> but it's a minimal amount 14:50 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev 14:50 < maaku> and it can be dumped in an append log or something 14:51 < maaku> JackH: yes the local machine has state 14:52 < JackH> ok so we can imagine, a very very busy payment hub, could have scaling problems, and would need to cluster its data center in order to stay "big" 14:55 < JackH> its explained like this in the white paper: 14:55 < JackH> ventually, with optimizations, the network will look 14:55 < JackH> a lot like the correspondent banking network, or Tier-1 ISPs. 14:56 < JackH> which means, the Tier-1 will router most of the transactions 14:56 < JackH> which again means, they will hold most of the data in transit 14:57 < JackH> am I wrong? 14:57 < aj> JackH: the number of txs on a channel in flight is limited by bitcoin's transaction size 14:57 < aj> JackH: and you can run different channels on different servers if you really need to scale, afaics 14:59 < JackH> server in this case means the node/daemon? 15:00 < aj> JackH: a 1MB tx would allow about 25k in flight transactions in a channel max 15:00 < aj> JackH: i mean server hardware; ie running a "node" by having 10k channels per server, over a dozen servers for 100k+ channels all up 15:02 < JackH> why does the channel have limitations? 15:02 < JackH> where do the limitations derive from? 15:02 < Ylbam> 23:57:25 JackH: the number of txs on a channel in flight is limited by bitcoin's transaction size 15:02 < aj> JackH: a channel is made up of an anchor transaction, and a pair of commitment transactions that spend it (bitcoin transactions i mean) 15:03 < aj> JackH: the commitment transaction has to have a p2sh output for every in-flight (lightning) transaction currently on the channel 15:04 < aj> JackH: the commitment transaction can't be bigger than a bitcoin block (ie, 1MB atm) and probably can't realistically be bigger than the 100kB standard transaction limit 15:04 < JackH> ahh now I get you! the anchor transaction is the derived value you set 15:05 < JackH> you are basing the limits on how the settlement is eventually made 15:05 < JackH> in Bitcoin itself 15:08 < aj> JackH: yeah, the commitment transaction is there to be used for settlement immediately if either side wants to close the channel for whatever reason; that's why it has to include everything, and get updated every time something happens on the channel 15:10 < aj> JackH: i think a p2sh output uses up 32 bytes per output, so 100kB/32B ~= 3000 transactions on a channel at any one time 15:11 < JackH> ok makes perfect sense 15:11 < aj> JackH: (but a transaction should only be "live" for a few seconds until it gets accepted/rejected by whoever's being paid; so that could be 1000s of transactions per second per channel still) 15:12 -!- bedeho [~bedeho@38.104.140.6] has quit [Ping timeout: 260 seconds] 15:13 < JackH> this is a bit like an in-memory grid like hadoop 15:17 < aj> JackH: yeah, or all the other things like that. long way off from needing to scale that seriously yet 15:17 < JackH> well I can actually see this happening before you might think 15:17 < JackH> not in Bitcoin 15:17 < JackH> but in a sidechain 15:17 < JackH> where big data will most likely dominate 15:18 < JackH> the reason to why I asked about constrains in lightning and where the data resides before a channel is closed was to understand where the bottleneck in the case of a sidechain needing to handle petabytes of data per day would be 15:19 < JackH> but I am not sure lightning on top of a sidechain would be right answer, since it doesnt do something "magical", but rather solves Bitcoins problem specifically 15:19 < aj> JackH: not sure what lightning does for "data" versus "money" ? 15:20 < JackH> well all is data 15:20 < aj> JackH: i guess lightning works because "money" is deliberately fungible -- if i give you $1 then you give me $1, we can cancel it out and pretend it never happened. but if i give you 100 bytes, and you give me 100 bytes, we've both got 100 bytes more than we did originally... 15:21 < JackH> haha, yes I understand what you mean 15:24 < aj> JackH: IoT stuff is where I could see crazy volume happening; thousands of tiny microchips with wifi wanting to pay 0.001 of a cent every few seconds for power/bandwidth or misc resource management... 15:25 < JackH> yep, exactly 15:25 < JackH> would you use lightning for that, if this happened in a sidechain aj? 15:26 < JackH> or would you rather rely on different software to handle it? such as hadoop, assuming you are in full control of the sidechain implementation and consensus model 15:29 < aj> JackH: depends on the sidechain i guess? (i mean, lightning still doesn't exist either) but if it's like bitcoin, ie confirmations take minutes rather than seconds, and logging every IoT txn in the blockchain isn't needed, then lightning would be a win 15:31 < JackH> aj: wont the constrains at the end of the day be placed on bitcoind for writing the data to a blockchain if the blocktimes in a sidechain were set to seconds? 15:33 < aj> JackH: i suspect that Liquid thing can probably update in seconds, since no proof-of-work is required 15:34 < JackH> liquid? 15:34 < aj> JackH: the new blockstream sidechain that got announced yesterday 15:35 < JackH> ahh that 15:35 < aj> JackH: https://www.reddit.com/r/Bitcoin/comments/3ok8ga/blockstream_announces_liquid_bitcoins_first/cvydu7r 15:37 < aj> JackH: for IoT stuff, i think the main sidechainy thing you'd need is segregated-witness or similar, so that tiny IoT devices could outsource the "deal with monitoring the blockchain" business to someone else 15:38 < JackH> well PoW certainly wont work in the case of IoT's even if block times are small 15:38 < aj> JackH: atm, to run a lightning node i think you're going to need RPC access to a bitcoin node, which isn't very "embedded-friendly" 15:38 < JackH> yeah, trust me I know, we are a payment gateway 15:38 < aj> JackH: proof of work is fine, as long as you don't care if it takes a while, and someone else is doing it for you :) 15:38 < JackH> so we played around with embedding into the RPC 15:38 < JackH> lol 15:40 < aj> JackH: how'd that go? ("embedding into the RPC") 15:41 < JackH> it went quite well, we have a full set of API's that talks to the RPC's for issuing addresses etc 15:41 < JackH> took 4 months 15:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:42 * rusty reworks the crypto, after sleeping on it. 15:43 < JackH> ah the man in charge of making this happen 15:43 < JackH> soon done Rusty? 15:43 < JackH> we all want to give this a go 15:44 < rusty> JackH: Understood, I'm eager too! But the competition is not to be first, it's to be best. 15:44 < aj> rusty: if you're first, at least you'll be best briefly! 15:44 < JackH> no doubt, but we still want to play with the toys ;) 15:45 < aj> rusty: so, uh, why aren't you using TLS? 15:46 < rusty> aj: true, until someone finds a horrible exploit and everyone loses money and now instead of building on an accreted mound of careful development we have to build inside a giant crater of disappointment, distrust and despair... 15:47 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] 15:47 < aj> rusty: hmm, if something goes wrong with lightning, surely the metaphor is having to deal with the burnt, blackened husk of a tree 15:48 < rusty> aj: you're right, it just struck me that I was off-meme. 15:50 < JackH> rusty are you familiar with the Thunder network? 15:51 < rusty> JackH: indeed, they've been interacting on the list. They've got some pieces together, but I've not actually downloaded and tested their stuff. 15:51 < JackH> it looks like there are 3 teams working on similar stuff, lightning, thunder and duplex 15:51 < JackH> but you each have quite a different approach 15:52 < JackH> and yours is by far more heavy 15:55 < aj> duplex is more reliant on malleability fixes, i think (ie, segregated witness, so even re-signing is safe) 15:56 < JackH> from my understanding duplex doesnt even check the ECDSA signatures of the transactions 15:56 < JackH> I might be wrong 15:57 < rusty> JackH: hmm, not sure about that categorization. I'm doing two things: developing a reference implementation, and developing a standard. It keeps things challenging for me. 15:58 < JackH> rusty: thats by far the most interesting about lightning, you are building a standard! 15:58 < JackH> now - give it to us! we want to play with it 15:58 < JackH> hehe 15:59 < aj> i think thunder has a somewhat-truted third party to make things a bit simpler, and the idea is that'll go away once lightning actually works 16:00 < rusty> aj: amikopay has that, not sure about thunder. 16:00 < aj> rusty: but seriously, why aren't you just using TLS to secure the tcp/ip connection? roll-your-own crypto protocols make my skin crawl :-/ 16:01 < aj> rusty: oh, maybe i'm confusing them then 16:01 < aj> rusty: i keep confusing CJP and Joseph Poon because they've both got JP as initials... 16:01 < rusty> aj: attack surface. All this needs is hmac (trivial) and AES. 16:01 < rusty> aj: not all of openSSL. Plus you'll want DTLS, for hole punching UDP. 16:02 < rusty> aj: and if you've ever looked at the OpenSSL APIs, you'll realize that you *still* need to know all the crypto things to drive it properly. 16:05 < aj> rusty: (i was thinking SMTP-like STARTTLS after establishing the connection, so don't think DTLS would be needed) 16:06 < aj> rusty: i guess i wish i could say the openssl apis didn't make my skin crawl too :( 16:07 < rusty> aj: yeah, writing this has tempted me to write a ccan/simplecrypto module, which supports SHA256, AES128 and BADA55 *only*, and supplies all the logical combinations you could want. 16:08 < aj> rusty: oh god, the only thing worse than writing your own crypto is making it a library for other people to use -- then it's your fault when their programs break too 16:08 < aj> rusty: don't do it man! 16:09 < aj> hmm, http://thunder.network/ isn't working for me :( 16:09 < rusty> aj: they will be broken anyway. For example, openssl makes it easy to generate your own hmac. But then it's up to the caller AFAICT to remember to use CRYPTO_memcmp not memcmp to avoid timing attacks. 16:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 16:27 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 16:27 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 16:27 -!- bedeho_ [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev 17:16 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:17 < rusty> Updated crypto scheme pushed... 17:18 < rusty> The previous one had some weaknesses; I should have pondered more before pushing yesterday, sorry mjerr. But now it's simpler... 17:25 < rusty> aj: so, I'm thinking of prepending a signed "rate card" before anything else, where a node could have a canned (signed) copy of node information which it would push first thing in any connection. 17:25 < rusty> aj: that would allow eg. whether it will fund a channel, or potentially later, how much it would charge for that service, etc. 17:26 < rusty> Even a node not currently taking new connections could publish this, then close channel if you don't identify yourself as existing client. 17:27 < rusty> For the moment it would be empty, but I want it in the protocol... 17:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-klojokmubmtcrosw] has quit [Quit: Connection closed for inactivity] 17:35 < aj> rusty: had a look at gnutls while you weren't here... seems like it'd be fine, except that it doesn't support secp256k1 17:35 < rusty> aj: if I had to choose a second crypto it'd be the DJB curves... does GNUTLS support them? 17:36 < aj> rusty: no don't think so 17:37 < rusty> aj: yeah :( 17:38 < aj> rusty: a rate card sounds like a good idea to me. (open ended json data? or protobufs?) 17:39 < rusty> aj: . 17:39 < rusty> aj: then intro packet is just . 17:39 < aj> rusty: only thing i wonder is if "connect to 1.2.3.4:5678, and it tells me it's node X" might be a security hole if nodes want to be secretive about the relationship between their ip and pubkey (or have multiple node pubkeys on a single server) 17:40 < rusty> aj: we could have a field. HTTP made that mistake originally. 17:42 < rusty> aj: so now it's . Stealth server could wait to receive that. 17:42 < rusty> aj: Hmm, would require signature too, so it would only answer if is good. 17:43 < rusty> aj: I guess that can be canned too, so it's OK (trying to reduce amount of signing required) 17:43 < aj> rusty: what's ? 17:43 < rusty> aj: crypto sig over other fields. 17:44 < aj> rusty: isn't it a hmac keyed on an ecdh secret between and ? 17:44 < rusty> aj: sure, but this is before we've established shared secret. 17:44 < aj> rusty: (isn't an ecdh secret sufficient to prove you have the other secret key?) 17:45 < aj> rusty: btw, i made some diagrams of the onion routing protocol: http://azure.erisian.com.au/~aj/tmp/lightning/onion.pdf 17:46 < rusty> aj: sure, if you get that far. You want a canned rate card though, even if you drop conn before. 17:46 < aj> rusty: generated via groff with https://github.com/sathlan/dformat because it's 2015... 17:46 < rusty> aj: you are 'leet! 17:48 < rusty> 3. Routing Message Format. Truncated? 17:48 < aj> rusty: https://github.com/ajtowns/lightning/commit/29dbb6264edd4bf1053b4f1dfcf425c7c6b43396 17:49 < aj> rusty: truncated at the motivation to typing interface, sure 17:49 < rusty> aj: ah, OK! Diagrams are nice though; I will convert to ASCII art as Postel intended, of course... 17:51 < aj> rusty: i didn't spot any scripts to generate ascii diagrams 17:51 < rusty> aj: emacs, dude! 17:53 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 17:56 < rusty> aj: good question on signature on session key. I think it's redundant, but let me get another coffee first... 17:57 < rusty> Here's what I have in my editor now: 17:57 < rusty> struct intro { 17:57 < rusty> /* Signature of all the rest (FIXME: Serialize!) */ 17:57 < rusty> u8 signature[64]; 17:57 < rusty> /* My node's public key (ie. ID). */ 17:57 < rusty> u8 pubkey[33]; 17:57 < rusty> /* If I am trying to reach a specific node (or zero) */ 17:57 < rusty> u8 destkey[33]; 17:57 < rusty> /* Optional public rate card. */ 17:57 < rusty> le32 rate_card_length; 17:57 < rusty> u8 rate_card[]; 17:57 < rusty> }; 17:58 < rusty> So, you can wait for other side to send that, then if you're happy, send yours. Then send a session key. 17:59 < aj> rusty: hmm 18:00 < rusty> aj: It allows multiplexing many nodes on the same IP/port. And "rate card" is a bit understating it, as we can use that for version info. 18:01 < aj> rusty: so "do i want to send my public key in cleartext where anyone could see it" is the first thing that comes to mind :-/ 18:02 < rusty> aj: because it's your node ID, it's kind of important to send. 18:03 < aj> rusty: yeah, but it's also sensitive, if someone's trying to track me down and is sniffing gsm traffic 18:05 < rusty> aj: *someone* has to send their pubkey... hmm... 18:10 < aj> rusty: what if the client sent " " ; the server responds with the ratecard or a failure ; everything else is encrypted using ECDH with the session key and server's pubkey ; initiator reveals their pubkey over encrypted channel ? 18:11 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:15 < rusty> It breaks symmetry, of course. That's not fatal... 18:16 < rusty> why ? That's a PITA to demux. 18:17 < aj> rusty: well, whoever connects presumably knows who they're connecting to... 18:18 < aj> rusty: if you don't have some sort of nonce, then you just look for SHA256(pubkey) instead of pubkey when you're snooping wireless traffic 18:18 < rusty> aj: but receiver has to demux in the "shared server" case. And it's still trivial for anyone to figure out what server you're going to AFAICT. 18:18 < rusty> aj: for the normal non-MUX case, at least. 18:19 < aj> rusty: if you thought i was connecting to Bob, you could verify that; but you could equally connect yourself and say "hey, give me the ratecard for Bob" 18:19 < aj> rusty: if you didn't know if it was Bob, you'd have to go through the phonebook to see what the SHA256 unhashed to 18:20 < aj> rusty: demuxing is a pain, yeah 18:21 < aj> rusty: maybe for version 0.x it's better just to assume that everyone knows which IP matches which lightning pub key and leave obscuring that to v1 or v2 or whatever 18:22 < aj> rusty: that seems really revealing though :( 18:25 < aj> rusty: (hmm, gnutls uses nettle for its actual cryto ops; /nettle/ supports curve25519, but gnutls doesn't afaics, despite wikipedia claiming it does. how strange) 18:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 18:27 -!- trippysalmon [~Rob@ip4da81ded.direct-adsl.nl] has quit [Read error: Connection reset by peer] 18:30 -!- AaronvanW [~ewout@f053078078.adsl.alicedsl.de] has joined #lightning-dev 18:30 -!- AaronvanW [~ewout@f053078078.adsl.alicedsl.de] has quit [Changing host] 18:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 18:36 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 19:10 < rusty> aj: OK, I've changed "rate_card" to "optdata". We can later extend to use a disposable pubkey and put the encrypted stuff in optdata. 19:13 < aj> rusty: does that make it symmetric again? 19:13 < rusty> aj: yes... 19:13 < aj> rusty: pretty! 19:13 < rusty> Yeah, it's a useful thought experiment on how we'd extend it, but I think we have to paint the bikeshed at some point. 19:15 < aj> rusty: optdata is like selling tinted sunglasses at the city gateway; why choose a paint colour? 19:16 < rusty> aj: you need those shades because the futures so bright? What with everything being hit by lightning and all... 19:18 < aj> rusty: the future's so bright, we'll all end up vision-impaired 20:22 -!- richardkiss [~richardki@ip68-227-33-165.lv.lv.cox.net] has quit [Read error: Connection reset by peer] 20:23 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 244 seconds] 20:24 -!- gwillen [~gwillen@li450-236.members.linode.com] has joined #lightning-dev 20:25 -!- gwillen is now known as Guest48737 21:22 -!- lightningbot [lightningb@cerulean.erisian.com.au] has quit [Remote host closed the connection] 21:22 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #lightning-dev 22:01 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 265 seconds] 22:23 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev 22:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds] 22:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zzmchqgovcmoedgb] has joined #lightning-dev 23:58 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 240 seconds]