--- Day changed Thu Oct 15 2015
00:32 -!- Guest48737 [~gwillen@li450-236.members.linode.com] has quit [Changing host]
00:32 -!- Guest48737 [~gwillen@unaffiliated/gwillen] has joined #lightning-dev
00:32 -!- Guest48737 is now known as gwillen
01:02 -!- pepesza [~pepesza@abbc119.neoplus.adsl.tpnet.pl] has joined #lightning-dev
01:29 -!- bedeho_ [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds]
01:30 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
01:52 -!- mjerr [~matsjj@89.197.31.78] has joined #lightning-dev
01:52 -!- mjerr [~matsjj@89.197.31.78] has quit [Remote host closed the connection]
01:53 -!- mjerr [~matsjj@89.197.31.78] has joined #lightning-dev
01:55 -!- mjerr [~matsjj@89.197.31.78] has quit [Client Quit]
01:55 -!- matsjj [~matsjj@89.197.31.78] has joined #lightning-dev
01:56 -!- matsjj_ [~matsjj@lw.serv130.quikefall.com] has joined #lightning-dev
01:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
02:00 -!- matsjj [~matsjj@89.197.31.78] has quit [Ping timeout: 272 seconds]
02:05 < matsjj_> rusty, you around?
02:05 < rusty> matsjj_: I am!
02:06 < matsjj_> Oh great stuff! I implemented encryption and authentication yesterday
02:06 < matsjj_> I was wondering
02:06 < matsjj_> what you meant with
02:06 < matsjj_> 2) 64-bit LE total data length so far including this data (replay protection). 
02:06 < rusty> matsjj_: Good question!  OK, so it only ever increments, thus avoiding replay.
02:07 < matsjj_> What does LE stand for?
02:07 < rusty> matsjj_: an attacker can re-send an old packet and confuse the protocol.
02:07 < rusty> matsjj_: Little Endian :)
02:08 < matsjj_> ah I see. But why does it increments when it's just a length descriptor?
02:08 < rusty> matsjj_: OK, so if we just used it as length, we'd also want a separate packet counter to avoid replay.
02:09 < rusty> matsjj_: by combining the two, we get both packet counter and length.
02:09 < matsjj_> So what you actually have is two 4 bytes, one for the data length and one counter?
02:10 < rusty> matsjj_: no, you subtract the previous counter from the current counter to get the length of current packet.
02:10 < rusty> matsjj_: so it's "total data bytes sent so far, including this packet"
02:11 < matsjj_> ahhhh
02:11 < matsjj_> I totally not read the SO FAR
02:11 < matsjj_> weird
02:11 < matsjj_> but don't we get this property from CTR already?
02:11 < matsjj_> brb
02:11 < rusty> matsjj_: yeah, it's probably a total premature optimization.
02:18 < rusty> matsjj_: So we have to handle re-transmissions, for when a node goes down.  So, we'll have to know where to re-set CTR mode to.
02:18 < rusty> matsjj_: Turns out that we can have up to 5 packets replayed (our response will be to simply resend what we sent before; the protocol was designed to be robust in that case).
02:19 < rusty> (This is not yet implemented, BTW)
02:23 < matsjj_> when a node goes down, don't we just do a fresh handshake? it's only 2-4 packets anyway and we have a fresh connection again
02:24 < matsjj_> so I changed it a little bit up and separated encryption and authentication. Authentication only happens after the Encryption handshake, so it's like 2 separate handshakes, but an eavesdroper can only listen to the first one
02:25 < matsjj_> I like to not give information for free
02:26 < matsjj_> I don't know exactly how you handle with individual packets in C, I totally fell in love with the netty library for java for that, as I only have to deal with this on the lower layers
02:30 < matsjj_> rusty, ping :P
02:30 < rusty> matsjj_: sorry... need to mention my nick so I get pinged :)
02:31 < matsjj_> Yea realized that
02:31 < rusty> matsjj_: aj noted the same issue.  But one side needs to say who they are.
02:31 < matsjj_> :)
02:31 < matsjj_> for ddos protection or for which reason?
02:31 < rusty> matsjj_: how else do you encrypt to someone if they don't give some identifier?
02:32 < rusty> matsjj_: so, I have an update sitting here which adds a packet before session handshake.  Not sure I like it, but the idea is that you can send some setup data (eg. what version of protocol you support, what services you offer) before anything else.
02:32 < matsjj_> you send a ephemeral key and then the other party sends an ephemeral key and then you have the encryption 
02:33 < matsjj_> hmm
02:33 < matsjj_> I would rather have that on top of the encryption layer
02:33 < matsjj_> I know it makes sense to support older systems later on to have it as low as possible, but I would not have anything below the encryption layer
02:34 < matsjj_> If the encryption ever needs changing, I rather have kind of a hard fork that is not compatible with old systems
02:34 < rusty> matsjj_: indeed, I'm sympathetic to that idea.  Though it means you have to do work for every connection, before you know whether it's an established client or someone new.
02:34 < rusty> matsjj_: yeah, we'll probably hardfork.  Though unless we've screwed up the protocol design, if bitcoin crypto is broken we've got other problems :)
02:35 < rusty>  matsjj_so you prefer a straight key exchange, then identity next?
02:35 < matsjj_> Exactly! It might be susceptible for ddos attacks, as you cannot verify the other node before doing that work
02:35 < matsjj_> right
02:35 < rusty> matsjj_: yeah, aj disliked that you can see who is talking to who else.  I think I'm convinced.
02:36 < matsjj_> https://github.com/matsjj/thundernetwork/blob/onion/thunder-core/src/main/java/network/thunder/core/communication/nio/P2PServer.java#L72
02:36 < matsjj_> netty allows for these sweet handlers
02:37 < matsjj_> that really separate the layers, possible to change the flow with just changing one line
02:38 < matsjj_> rusty, exactly! Most of the open channels will be public due to the routing system, but some maybe aren't. Good to allow for these
02:40 < rusty> OK, so it'd be a 33 byte session pubkey first for ECDH.   Then we sign (that?) with our actual key under crypto as next step.
02:41 < rusty> matsjj_: did you catch the core crypto changes BTW?  We now have completely separate AES key, IV and HMAC key for each dir.
02:42 < matsjj_> It is 33 bytes back and forth, and then a 20 byte 'secret' is sent, the other party does sign that with their actual key together with a timestamp and the pubkey of the other node
02:42 < matsjj_> so each node has to sign data supplied by the other party, to allow for perfect replay protection
02:43 < matsjj_> rusty, link? I think I didn't
02:43 < rusty> matsjj_: hmm, I did push --force... bad me...
02:44 < matsjj_> I mainly based off of https://github.com/ElementsProject/lightning/commit/2c3665ef7f829d65986fb3a4e02697ea9d35b37e
02:44 < rusty> matsjj_: phew, that was after my fix!
02:44 < matsjj_> what do you mean with 'completely separate AES key, IV and HMAC key for each dir' then? :)
02:45 < rusty> matsjj_: why send the 20 byte secret?
02:45 < rusty> matsjj_: well, originally I used the same AES key for both dirs, but different IV.  And same HMAC.  THen I slept on it and decided that was stupid :)
02:46 < rusty> matsjj_: And a timestamp seems weird...
02:46 < matsjj_> rusty, I googled that and found http://crypto.stackexchange.com/questions/8081/using-the-same-secret-key-for-encryption-and-authentication-in-a-encrypt-then-ma
02:47 < matsjj_> saying that it is fine to just reuse the key for everything, but you might as well just derive them somehow
02:47 < matsjj_> rusty, yea the timestamp might be over the top. The secret is to ensure the other party actually really does have the private key, and is not replaying data somehow
02:48 < rusty> matsjj_: yeah, I could probably use same key, but it's pretty cheap to generate so I'm being paranoid.
02:48 < matsjj_> exactly
02:48 < rusty> matsjj_: yeah, it feels wrong to reveal the secret though, even under encryption.  Just signing the tmpkey should be sufficient.
02:49 < rusty> ie. session key.  That proves it is us.
02:49 < matsjj_> hehe, it just feels wrong because I call it secret. It's rather some blob of data we want the other party to sign
02:49 < rusty> matsjj_: Oh!  Right, some random blob.  I thought you meant the ECDH-extracted secret!
02:49 < matsjj_> Ohhh no
02:50 < rusty> Hence my confusion :)
02:50 < matsjj_> Yea I should really rename that
02:51 < matsjj_> But you are right, it should be sufficient to just sign OUR temp key, since it's equally random
02:51 < matsjj_> and we chose it
02:55 < rusty> I think we could just do another round of ECDH using our master key, since being able to HMAC would imply we knew it.  But a signature is useful to prove stuff to other people, in particular there's the idea of a "rate card".
02:56 < rusty> ie. a node will say how much it would charge for various services.  If they sign "<your tmpkey> <optional-ratecard>" we can give that to anyone to prove they said it without revealing anything
02:56 < rusty> Cool, now I just have to code it :)
02:57 < matsjj_> Hehe, that's similar to the authentication system I had in mind
02:58 < matsjj_> Yea ECDH could work as well, but it's pretty much just more work without any bonus (as we don't use that key for anything then)
03:00 < matsjj_> so for the records, authentication handshake is sending across the signature for [pubkeyMe + tempkeyYou]
03:00 < matsjj_> together with pubkeyMe
03:00 < matsjj_> rusty, right?
03:00 < rusty> matsjj_: yep, good point!
03:01 < rusty> matsjj_: signature first or last?  Turns out first is slightly easier to implement...
03:01 < rusty> (but it's really marginal, so if that's a hassle for you we can flip a coin :)
03:01 < matsjj_> Hehe, I'm using string encoded json currently, since it's great for debugging. I don't mind
03:02 < rusty> OK, cool.
03:02 < matsjj_> I can always change that up completely by changing the ByteToMessageHandler
03:02 < rusty> BTW, thanks!  This is exactly the kind of feedback I was after!
03:02 < matsjj_> :)
03:03 < matsjj_> I actually stopped working on the simulation for now. seeing your progress I instantly working on implementing it as well
03:03 < matsjj_> *started
03:04 < rusty> I'm pretty happy how many people are implementing all the bits... also means I'm not the only one who finds this stuff fun :)
03:04 < matsjj_> How many are there? Isn't it just the three of us?
03:06 < matsjj_> For me it is crazy how much there is to learn implementing this. Two weeks ago I had no idea what a HMAC even is..
03:07 < rusty> matsjj_: You, me, CJP are working on complete systems.  aj did a python implementation of the onion test code, too.
03:07 < rusty> matsjj_: fun!
03:07 < waxwing> so you guys are doing authenticated encryption? any reason not to just use something 'off the shelf' like nacl?
03:07 < matsjj_> *google*
03:08 < rusty> waxwing: attack surface.  I love DJB's work,  but we're already bound to bitcoin's encryption.  
03:08 < waxwing> ok, so you have to use secp256k1?
03:08 < waxwing> it seems at first glance you wouldn't have to, but i have no idea :)
03:09 < matsjj_> I was actually wondering the same thing
03:09 < waxwing> rusty: if i said "bitcoin doesn't use encryption" i would be probably be annoying :)
03:09 < rusty> waxwing: yeah, thanks.
03:10 < matsjj_> waxwing, we don't need to, but it seems to work. I don't really see any advantage of not using it, so we might as well
03:10 < rusty> waxwing: we could pull in another crypto library, but seems like just trouble.  If secp256k1 is broken, we're pretty screwed.
03:11 < matsjj_> rusty, hehe was close to writing the same. Didn't felt like a great point though
03:11 < matsjj_> ^^
03:12 < matsjj_> As it's not gonna be broken instantly, but rather someone will find a hole and start using it. Having it across all systems will just increase the damage
03:13 < matsjj_> secp256r1 seems to be widely used, for me it is just changing one letter at some point in the code. I don't think though that one is superior for what we are doing
03:13 < waxwing> fwiw i'm just raising the point about designing your own authenticated encryption protocol, not so much about the curve.
03:13 < waxwing> although i guess they cannot be totally extricated
03:14 < waxwing> but that's all above my pay grade. just curious.
03:14 < matsjj_> don't worry, these are valid points
03:17 < matsjj_> I am positive we will get a lot of review from more experienced crypto guys though. Not a great fan of of-the-shelf solution 
03:18 < matsjj_> rusty, aj was the one behind amiko pay, right? what is CJP working on?
03:19 < rusty> matsjj_: naah, aj's a random :)  CJP == amiko pay.
03:19 < matsjj_> ah, me confused hehe
03:19 < rusty> matsjj_: Oh, and I expect Tadge Dryja and Joseph Poon to do something; they're doing a startup AFAIK.
03:20 < matsjj_> I was wondering where they ended up as well
03:20 < matsjj_> Why isn't mirror pushing it though
03:20 < matsjj_> with Dryja onboard already
03:21 < rusty> matsjj_: they left mirror, apparently they're pivoting, but don't know details...
03:21 < matsjj_> Oh I see, didn't knew dryja left mirror as well
04:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
04:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
05:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
07:20 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zzmchqgovcmoedgb] has quit [Ping timeout: 256 seconds]
07:20 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-lpqfqatbumrrwgho] has quit [Ping timeout: 268 seconds]
07:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qhfwnbupyeszasbc] has joined #lightning-dev
07:30 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-ibqkichxkqshpqdc] has joined #lightning-dev
07:47 -!- pepesza [~pepesza@abbc119.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 240 seconds]
09:01 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
09:04 -!- matsjj_ [~matsjj@lw.serv130.quikefall.com] has quit [Remote host closed the connection]
09:04 -!- matsjj [~matsjj@lw.serv130.quikefall.com] has joined #lightning-dev
09:22 -!- matsjj [~matsjj@lw.serv130.quikefall.com] has quit [Ping timeout: 255 seconds]
09:51 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has joined #lightning-dev
09:52 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has quit [Remote host closed the connection]
10:33 -!- bedeho_ [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:38 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has joined #lightning-dev
11:02 < maaku> is lightning more likely to use height-based or time-based lock time?
11:25 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
12:02 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
12:02 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Remote host closed the connection]
12:02 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Client Quit]
12:02 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
12:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
12:57 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
13:07 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
13:39 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has joined #lightning-dev
13:53 < rusty> matsjj: good timing!  Just posted the change, and the optdata tests.
13:54 < matsjj> haha, hey there
13:54 < matsjj> rusty, link? :)
13:55 < rusty> matsjj: daemon branch: https://github.com/ElementsProject/lightning/tree/daemon
13:59 < rusty> matsjj: pretty simple: u8 signature[64]; u8 pubkey[33]; u8 sessionkey[33]; u8 optdata[];
13:59 < matsjj> sessionkey?
14:00 < matsjj> optdata is for forward compability?#
14:00 < rusty> matsjj: their session key, as a random nonce, as we discussed.
14:00 < rusty> Yep!
14:00 < rusty> matsjj: optdata has to be valid protobuf if not zero-length, and must not have any even fields.
14:00 < matsjj> oh, why are we sending it though?
14:00 < rusty> ("odd is OK")
14:00 < rusty> matsjj: err..... good point :)
14:00 < matsjj> ;)
14:01 < rusty> Makes code a bit simpler, but that's hardly a convincing argument.  Let me fix that :)
14:01 < rusty> (I will add it to signature at the end though, which allows a microefficiency in future since all the rest is known ahead of time).
14:01 < matsjj> I was thinking about MITM attacks against this btw. As we don't use authentication in the first handshake, it is possible to MITM that, but it would not be possible to MITM the authentication then
14:02 < matsjj> hm? so it is 
14:02 < matsjj> signature||pubkey
14:02 < matsjj> signature||pubkey||sessionkey
14:03 < matsjj> but this only holds true if we have know the pubkey of the node we want to connect to in advance
14:04 < rusty> signature covers pubkey||optdata||sessionkey
14:04 < matsjj> ah thats what you mean with adding it to the signature
14:04 < matsjj> yea sure
14:05 < matsjj> wouldnt allow for replay security otherwise ;)
14:05 < matsjj> but I would add a protocol-version-handshake after the authentication layer
14:05 < matsjj> I would not include that in the optdata
14:05 < matsjj> just saying it now ;)
14:08 < rusty> matsjj: I'm from Australia, so I fear adding round trips :)
14:08 < matsjj> oh you are, I always thought you were US :P
14:08 < matsjj> you don't like aquavit then either? :P
14:09 < matsjj> but some nodes might not like to expose data about their setup to nodes they don't know, so it really makes sense to add this layer after the authentication one
14:09  * rusty googles aquavit... looks dangerous!
14:10 < matsjj> and authentication is already linked up with the encryption (I realized that today, that these two layers are no longer seperate with this change today)
14:10 < matsjj> hehe - it tastes horrible. But it is called this way because they load it up a ship and ship it across the equator twice :P
14:11 < rusty> Sure, but you can indicate that you support such a think in optdata :)
14:12 < matsjj> but even that is information you might not want to share :P
14:12 < matsjj> whatever we add in optdata is basically free for anyone to read
14:13 < matsjj> are you working from australia currently as well?
14:15 < rusty> matsjj: sure, but a public node will want to do exactly that.
14:15 < rusty> Yep!  BTW, what's your preferred moniker for attribution?  I just put matsjj in the commit msg...
14:16 < matsjj> but shouldn't a non-public node look exactly like a public node from an outside perspective?
14:16 < rusty> (Oh, and thunder.network was down)
14:16 < matsjj> matsjj is great, thanks for the credit! Yea, I should restart that server
14:16 < rusty> You try to connect to a random node, and if it lets you it's a public node?
14:17 < matsjj> most of the data there is already outdated, it's crazy :o
14:18 < matsjj> hehe, probably not worth that much discussion. I don't like the idea of leaking any information to not-authenticated people, but I can understand that it is additional effort
14:19 < rusty> matsjj: crap, I put two T's in matsjj... let me quickly rebase and force push (nobody will know!)
14:19 < matsjj> oh true, not even I realized that haha
14:21 < matsjj> so the thing with MITM is that we need some really reliable way of getting new nodes known to the p2p network
14:22 < matsjj> I even got back to the idea of pushing some information to the blockchain one can relate to
14:22  * rusty is tempted to use "Suggested-by: Mats J. J. Thunder <matsjj@thunder.network>"
14:22 < matsjj> oh, do Mats Jerratsch <matsjj@gmail.com> then - that email is not in use
14:23 < matsjj> although I like it. I should probably set it up
14:30 < matsjj> rusty, what do you think about MITM and tricking users into a completely made up network? It's rather vandalism, since one can't steal any money, but look what some guys did with a hole as the highS/lowS....
14:32 < rusty> matsjj: yeah, or if someone is starting out they connect to some "random" nodes who are all colluding.  Hard to detect.
14:33 < matsjj> Exactly. I thought about it, and having trust in a couple of nodes really can avalanche into building up trust into the network by connecting to random nodes for obtaining the whole picture. An attack would be kinda expensive, as you would need lots of IP addresses
14:34 < rusty> matsjj: we're still debating whether the anchor transactions should be exposed on the blockchain, creating a lightning network map.  Once you have the node ids, the IP address (or tor, or whatever) can be stored in bit torrent's DHT.
14:35 < matsjj> yea, IP is not a deal, it's just about having pubkeys of nodes that we can trust in ... how would you 'expose' them? OP_RETURN?
14:37 < matsjj> it would at least make an attack crazy expensive
14:37 -!- pepesza [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 240 seconds]
14:39 < rusty> matsjj: https://github.com/ElementsProject/lightning/commit/c7eaa4fda5e067093d39755f144d6a96d8151930
14:39 < matsjj> :)
14:39 < matsjj> thats why you are so quiet ;)
14:42 < rusty> matsjj: well, if the anchor is a 2of2 and not P2SH, and we actually use the node pubkey/id as the payment address, then you can detect those and build a channel map.  But I think that might be a poor choice for other reasons.
14:42 < matsjj> 2of2? But how do we use these as anchors?
14:42 < rusty> Address reuse is generally bad, and using the same pubkey for all your channels somewhat increases exposure
14:43 < rusty> matsjj: the anchor tx is a payment to a 2of2, basically.
14:44 < matsjj> basically? if it were a 2of2, we could not do proper refunds without malleability
14:44 < matsjj> thats true, you should only use the 'node pubkey' for authentication
14:44 < matsjj> and not for actual channels
14:45 < rusty> matsjj: I'm assuming we fix malleability, yes
14:45 < matsjj> oh, I guess we can actually have 2of2 then
14:45 < rusty> matsjj: but we'd kind of get a "net map" for free.
14:45 < matsjj> yes, that would actually be really great
14:46 < matsjj> thinking about it
14:46 < rusty> matsjj: (not my idea, it was JP).
14:46 < rusty> It doesn't actually save us much, since we need dynamic information about fees.  But it makes the network more transparent (which is good and bad)
14:47 < matsjj> but we could add OP_RETURN [pubkey_me || pubkey_you || signature
14:47 < matsjj> as another output
14:47 < rusty> matsjj: Yep!  Slightly less "free" but still good....
14:47 < rusty> Damn, my son waking, gtg.  At least he slept in a bit and let me code :)
14:47 < matsjj> well, I am mainly concerned about security right now, and MITM can be an issue without
14:48 < matsjj> hehe, enjoy your time with him :)
14:59 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has quit [Ping timeout: 255 seconds]
15:04 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has quit [Ping timeout: 240 seconds]
15:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds]
15:07 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has joined #lightning-dev
15:07 < matsjj> rusty, just thought about it. While we cannot have a public map of everyone, because we cannot 'translate' the P2SH, it is possible to broadcast the script over our p2p network. Someone trying to MITM with a big made-up network then can't show these transactions.. It's like OP_RETURN, but for free
15:08 < matsjj> not technically for free, as it's some added bytes for the script
15:08 < matsjj> but still cheap considered to OP_RETURN
15:26 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
15:32 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
15:43 -!- mustyoshi [~mustyoshi@c-68-37-216-210.hsd1.mi.comcast.net] has joined #lightning-dev
15:53 -!- matsjj [~matsjj@host217-42-220-60.range217-42.btcentralplus.com] has quit [Remote host closed the connection]
16:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
16:10 < rusty> matsjj: 2of2 is standard without P2SH.  But yes, we can always send around our own proofs of tx ownership, and skip OP_RETURN altogether.
16:27 -!- btcdrak_ [uid115429@gateway/web/irccloud.com/x-avugwtnzabxkdvts] has joined #lightning-dev
16:30 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Write error: Broken pipe]
16:31 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #lightning-dev
16:32 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-dzjjmpwesctorqfv] has quit [Ping timeout: 253 seconds]
16:32 -!- btcdrak_ is now known as btcdrak
16:32 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 265 seconds]
16:33 -!- jorn [~jorn@g227014.upc-g.chello.nl] has joined #lightning-dev
16:34 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Ping timeout: 265 seconds]
16:34 -!- fkhan [weechat@gateway/vpn/mullvad/x-axplirbccmseankd] has quit [Ping timeout: 265 seconds]
16:34 -!- jorn is now known as Guest58705
16:34 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Ping timeout: 265 seconds]
16:34 -!- Guest4879 [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 265 seconds]
16:42 -!- Guest58705 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
16:55 -!- Netsplit *.net <-> *.split quits: rusty
16:55 -!- Netsplit *.net <-> *.split quits: mustyoshi
--- Log closed Thu Oct 15 16:55:53 2015
--- Log opened Mon Oct 26 10:48:46 2015
10:48 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev
10:48 -!- Irssi: #lightning-dev: Total of 38 nicks [0 ops, 0 halfops, 0 voices, 38 normal]
10:48 -!- Irssi: Join to #lightning-dev was synced in 1 secs
10:57 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
10:57 -!- mode/#lightning-dev [+o rusty2] by ChanServ
11:12 -!- matsjj [~matsjj@79.173.166.74] has quit [Remote host closed the connection]
11:43 -!- matsjj [~matsjj@81.17.19.34] has joined #lightning-dev
11:57 -!- matsjj [~matsjj@81.17.19.34] has quit [Remote host closed the connection]
13:05 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
13:09 -!- matsjj [~matsjj@213.205.251.87] has joined #lightning-dev
13:30 -!- matsjj_ [~matsjj@179.43.160.226] has joined #lightning-dev
13:31 -!- matsjj [~matsjj@213.205.251.87] has quit [Ping timeout: 260 seconds]
14:10 < amiller> do the current lightning network proposals let me use the same collateral to make multiple concurrent payments
14:10 < amiller> like, A has $100 of collateral with a hub B, and B has an arbitrary size channel to C and D
14:11 < amiller> and now A wants to concurrently/independently pay both C and D
14:28 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
14:49 -!- matsjj_ [~matsjj@179.43.160.226] has quit [Remote host closed the connection]
14:57 < instagibbs> Yes, up to that $100 limit.
15:01 < instagibbs> "concurrently" may be a bit of a misnomer, but you can indeed send $50 to C, and $50 to D, or any other combination.
15:03 < instagibbs> without anyone sending through you the other direction
15:26 < maaku> instagibbs: I think the question about concurrency is appropriate -- the point is there may be multiple HTLCs in place
15:29 < aj> you're can pay up to $100 concurrently, but you can also only pay up to $100 sequentially ($50 to C, then an hour later $50 to D), since all the funds will be on the wrong side of the channel afterwards
15:31 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
15:32 < instagibbs> maaku, so some shared secret that once revealed pays all?
15:33 < maaku> instagibbs: I'm not actually sure how lightning handles this
15:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:39 -!- mode/#lightning-dev [+o rusty] by ChanServ
16:08 < aj> instagibbs: you pay $50 to #R=d3b07384d113edec49eaa6238ad5ff00 and $50 to #R=c157a79031e1c40f85931829bc5fc552; C reveals a preimage of "foo" and collects the first $50, and D reveals a preimage of "bar" and collects the second $50
16:09 < aj> instagibbs: (#=md5 for brevity)
16:22 -!- mode/#lightning-dev [-o rusty] by ChanServ
16:50 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
17:03 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
17:25 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
17:28 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
17:59 -!- jnewbery [~jnewbery@203.58.22.226] has quit []
18:01 -!- fkhan [weechat@gateway/vpn/mullvad/x-yjxxwavjvubkbjnz] has quit [Ping timeout: 250 seconds]
18:13 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
18:15 -!- fkhan [weechat@gateway/vpn/mullvad/x-fpuzdzgceqhznkgv] has joined #lightning-dev
18:26 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
18:26 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
18:31 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Ping timeout: 264 seconds]
18:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hvdxzhpjpaqlezfa] has quit [Quit: Connection closed for inactivity]
18:59 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
19:43 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:51 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
21:22 < jnewbery> Hey folks, not sure if this will be of any use at all to anyone, but I've checked in my lightning dev vm config here: https://github.com/jonnynewbs/rods . It's all very basic stuff, but if you haven't got an environment for writing lightning code yet, it might be helpful.
21:22 < jnewbery> All it's doing is pulling in the dependencies, then building alpha, protobuf, protobuf-c and lightning from source. Any comments or suggestions gladly accepted!
21:28 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 246 seconds]
21:30 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
21:32 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
21:42 -!- fkhan [weechat@gateway/vpn/mullvad/x-fpuzdzgceqhznkgv] has quit [Ping timeout: 250 seconds]
21:56 -!- fkhan [weechat@gateway/vpn/mullvad/x-slnmaxmiuwdufown] has joined #lightning-dev
22:03 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
22:17 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
22:25 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Remote host closed the connection]
22:26 -!- jnewbery [~jnewbery@203.58.22.226] has joined #lightning-dev
22:30 -!- jnewbery [~jnewbery@203.58.22.226] has quit [Ping timeout: 264 seconds]
23:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
23:47 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has joined #lightning-dev
23:52 -!- pepesza_ [~pepesza@ip-193-239-80-155.merinet.pl] has quit [Ping timeout: 250 seconds]