--- Day changed Wed Nov 16 2016
00:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rujcfyldlkzjyqpx] has joined #lightning-dev     
00:26 < cdecker> roasbeef: (ZNC + VPS) + (IRSSI + TMUX) :-)
00:53 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 265 seconds]     
03:11 -lightningrfc:#lightning-dev- [lightning-rfc] pm47 closed pull request #4: minor: only 2 bytes for open_channel.max-num-htlcs (master...patch-1) https://git.io/vXM6E
03:53 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has joined #lightning-dev     
04:04 -githubby:#lightning-dev- [lightning] cdecker closed pull request #95: Fix #91 32 bit build (master...fix-91-32-bit) https://git.io/vXDxb
04:04 -githubby:#lightning-dev- [lightning] cdecker closed pull request #93: json_connect: don't try to double-fail if amount insufficient. (master...fix-87-open-too-small-for-fee) https://git.io/vXDAg
05:34 -githubby:#lightning-dev- [lightning] cdecker opened pull request #97: sphinx: Fixed a buffer overflow in hmac generation (master...patch-04) https://git.io/vXyQj
05:35 -githubby:#lightning-dev- [lightning] cdecker pushed 1 new commit to master: https://git.io/vXy7L
05:35 -githubby:#lightning-dev- lightning/master b2a3e80 Christian Decker: Merge pull request #96 from ElementsProject/minor-sphinx-cleanups...
07:00 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev     
07:38 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-wigihvkwbcatlrdi] has quit [Quit: Connection closed for inactivity]     
07:46 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #lightning-dev     
08:20 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:343f:32aa:26fa:66ed] has quit [Quit: .]     
08:26 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has joined #lightning-dev     
08:26 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-djndphyymhrasttf] has joined #lightning-dev     
09:07 -lightningrfc:#lightning-dev- [lightning-rfc] pm47 opened pull request #5: minor: updated open channel diagram (master...patch-1) https://git.io/vXS8C
09:28 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
10:48 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has quit [Ping timeout: 265 seconds]     
10:50 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev     
10:50 -lightningrfc:#lightning-dev- [lightning-rfc] pm47 opened pull request #7: minor: fixed hierarchy and added a table of content (master...patch-2) https://git.io/vXSiz
10:55 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:02 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #lightning-dev     
11:03 -!- pm [~pm@11.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving]     
11:50 -!- Guest84529 [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #lightning-dev     
11:52 -!- Guest84529 is now known as roidster     
12:05 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
12:10 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev     
12:23 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds]     
12:26 -!- arubi_ [~ese168@bzq-109-65-85-49.red.bezeqint.net] has joined #lightning-dev     
12:27 -!- arubi_ [~ese168@bzq-109-65-85-49.red.bezeqint.net] has left #lightning-dev []     
12:30 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds]     
12:55 -!- wraithm [~textual@205.197.160.100] has quit [Ping timeout: 260 seconds]     
13:03 < TD-Linux> cdecker, any reason IRC channel change PR hasn't been merged yet?
13:36 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 260 seconds]     
13:39 -!- arubi [~ese168@unaffiliated/arubi] has joined #lightning-dev     
13:46 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]     
13:47 -!- arubi [~ese168@unaffiliated/arubi] has joined #lightning-dev     
14:17 -!- mryandao [~mryandao@unaffiliated/mryandao] has joined #lightning-dev     
14:31 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has joined #lightning-dev     
14:50 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev     
15:13 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #lightning-dev     
15:20 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #lightning-dev     
15:26 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-kpibxvzbqfkgmrbo] has joined #lightning-dev     
15:26 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
15:58 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-djndphyymhrasttf] has quit [Quit: Connection closed for inactivity]     
16:25 -lightningrfc:#lightning-dev- [lightning-rfc] Roasbeef pushed 1 new commit to master: https://git.io/vX9gx
16:25 -lightningrfc:#lightning-dev- lightning-rfc/master fc9975f Pierre-Marie Padiou: minor: updated open channel diagram
16:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev     
16:37 -!- adiabat [~adiabat@67.205.158.84] has joined #lightning-dev     
16:38 < adiabat> hey there, this is Tadge
16:38 < adiabat> about the revocation keys/points... we should define what attacks we're trying to prevent
16:39 < adiabat> I have (had) in my code just sending over a point, which gets added, in order to make the composite revocable pubkey which ends up in the script
16:39 < adiabat> There are some attacks on this, but I figured they didn't really matter
16:40 < adiabat> the attack there is, create private key x, pubkey X, set B = X - A, where A is the counterparty's base point
16:41 < adiabat> now you can sign with this 'revocable' public key immediately, instead of waiting for the OP_CSV timeout
16:41 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:41 < adiabat> thats... bad?  I mean, yeah, it's bad.  But you also can never revoke that commitment.  You don't know the private key b for the B you sent over.
16:41 < rusty> adiabat: hi!
16:41 < adiabat> So the whole channel ends at that point.
16:42 < adiabat> hey     
16:42 < rusty> Yeah, I'm reading your "shit, we need to multiply" now.  yeah, I think I agree.
16:42 < adiabat> Still that's probably an attack we should try to prevent if it's not too hard
16:43 < adiabat> Hm laolu just mailed... yeah I mean, the question is how bad is this attack...
16:43 < rusty> It's bad.
16:43 < adiabat> heh OK then we should switch to the pubkey delinearizationt hat sipa talked about
16:44 < rusty> If I get hold of the revocation privkey for my own commit tx, it's game over.
16:44 < adiabat> but... it's not really that bad, right?  Why game over?
16:44 < adiabat> it'd be your money anyway, you'd just have to wait a few days
16:45 < rusty> Revocation key lets me steal everything, your money too.  I mean, you can try to race me for it.
16:45 < adiabat> I don't think there can be a race
16:46 < adiabat> in this attack, the attacker has control of the timeout pubkey (which they should), and also the revocation key (which they shouldn't)
16:46 < adiabat> the race would only occur if it was a old/revoked commit
16:46 < adiabat> but it can never be revoked
16:47 < adiabat> so it's still an attack, in that you basically trick the other party, and now you can close with no delay at any time later
16:47 < rusty> Oh, yeah, revocation key doesn't apply to direct-to-other payments, so that's fine.  But old expired HTLCs I can push to timeout then spend with  revocation key immediately, right?
16:48 < adiabat> Hmm... I'm not sure you can get that far though
16:48 < adiabat> The whole channel ends as soon as there's this stuck commit which can't be revoked
16:49 < adiabat> the HTLCs can transition over to the HTLC resolution transaction, where the attacker can grab it immediately
16:49 < rusty> Right, that a specific subset of the problem "oops, you got the revocation key for your own tx".
16:49 < adiabat> but that's only after the absolute timeout of the HTLCs expire
16:50 < adiabat> I mean, it's ugly... the more I think about it, I don't like it.  I thought about it a while ago and figured "eh, no real attack, no problem" but... if we can get rid of it, i think we should
16:51 < rusty> Hmm, yeah.  I assumed the same, that if we can't provide the preimage, no harm.  I think that's still valid.
16:52 < rusty> But the CSV delay does provide a lightweight incentive against unilateral close, which I like.
16:53 < adiabat> but a construction where it's provable, hey, here's this revocation pubkey, which I definitely don't have the private key for
16:53 < adiabat> ... that's nicer
16:54 < adiabat> oh yeah in the secp25k1 delinearization, you don't multiply everything by the same hash.  The hashes are different
16:54 < adiabat> so it'd be
16:54 < adiabat> Q' = Q*h(Q || K) + K*h(K || Q)
16:56 < adiabat> that part I think is for this Wagner's generalized birthday attack
16:56 < adiabat> which I don't think applies here but might as well just use the same construction which guards against everything
16:57 < rusty> I missed sipa talking about delinearization, so I'm lost.  But if K = the shachain node, I think I'm following...
16:57 < rusty> So, we'd send h(Q || K) and K*h(K || Q) over the wire?
16:57 < rusty> (Or, a multiplicitive and an additive factor, IOW)
16:57 < adiabat> k would be the node, K would be k*G
16:58 < adiabat> so send over K the point first, then k the hash later
16:58 < adiabat> everyone can compute Q' = Q*h(Q || K) + K*h(K || Q)
16:59 < adiabat> I don't think you actually need the hashes to cover both since there are only 2 things being added, that was to protect against attacks where you could add many points
16:59 < adiabat> but it doesn't hurt to do so here
17:02 < rusty> I'm not sure why we need the additive part at all, but as you say it doesn't hurt.
17:02 < adiabat> you need the addition because if it's *only* multiplication, then there's nothing to revoke
17:02 < rusty> Oops, yeah :)
17:02 < rusty> Why can't we all just trust each other?!
17:02 < adiabat> haha
17:02 < rusty> We just put: "A node MUST NOT steal money" in the spec...
17:02 < adiabat> yeah you should ask sipa though, you're both at the same company right?  he's a few cubicles over?
17:02 < adiabat> he's the expert on this stuff.  I'm mostly going off his talk, and discussions with him
17:02 < rusty> Halfway around the world, and closer to your TZ than mine, but yeah....
17:02 < adiabat> I think with the addition where each key is 'delinearized' by multiplying by a hash, you know the attacker can't know the full revocable key
17:02 < adiabat> there's no guarantee they actually know little k... but nothing you can do about that
17:02 < rusty> So, did you get my note about sharing basepoints and shachain with the watcher means we want another basepoint for the to-other keys?
17:03 < rusty> Yeah, there's no guarantee they'll tell you k either, so that's no new assuption AFAICT.
17:03 < adiabat> yeah, I have 3 basepoints in my code, defining the channel
17:04 < adiabat> not because I was sure it was needed, but just seemed easy to do that way and safer.  no extra data on chain, and only has to be shared during channel construction
17:05 < rusty> Great...  BTW, did you see my comment about not needing encryption for the watcher data any more?  That kinda blew my mind...
17:06 < adiabat> for HTLCs, yeah. not sure what you mean by dummy sigs?
17:07 < adiabat> for obscuring the # of HTLCs per com?
17:08 < adiabat> like, "here's 5 sigs for com #43" then #43 gets broacast, but there's no HTLCs, so you only need 1 sig
17:09 < rusty> yeah.
17:10 < adiabat> yeah, that's doable.  I've got in the watcher just storing 16 byte half-txid and 64 byte sig.
17:10 < adiabat> https://github.com/mit-dci/lit/blob/master/watchtower/watchtower.go#L38
17:11 < adiabat> trying to get it working with just 1 sig / no HTLCs first, then extend it, but many HTLCs should be easy enough, just signatures, no hashes/preimages
17:13 < rusty> Yep!  If you want to let them to supply less sigs than stealable outputs, it gets a bit trickier; because you don't know if it's a dummy sig or an output they don't have a sig for, but still only O(n^2) for small n.
17:14 < rusty> I think it's worth insisting they be in order, though.
17:14 -lightningrfc:#lightning-dev- [lightning-rfc] Roasbeef pushed 1 new commit to master: https://git.io/vX9rf
17:14 -lightningrfc:#lightning-dev- lightning-rfc/master 17060cb Olaoluwa Osuntokun: BOLT 3: use code block for multi-sig script...
17:14 < adiabat> sure, can order them, even with 10 or 20 it's real quick
17:14 < adiabat> and none of this should ever happen anyway :)
17:17 < roasbeef> was just gonna add state-hints to the spec, but realize it's already there in the lock-time
17:18 < rusty> adiabat: so, I think we have: three basepoints.  (directkey-base, delayedkey-base, revokekey-base).  I send you the next k*G, aka K.  You calc each key for this commitment tx as Q' = Q*sha256(Q || K) + K*sha256(K || Q).  I revoke by sending k.
17:18 < roasbeef> two questions: do we want to move to the sequence num so we get 30 bits? and do we still wanna do the whole obsfucation thing? 
17:18  * roasbeef reads scrollback
17:18 < rusty> roasbeef: We use locktime and seqnum both.
17:19 < adiabat> 48 bits right? so we need both
17:19 < rusty> roasbeef: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction
17:20 < roasbeef> ahh didn't see the sequence section :) 
17:21 < roasbeef> y'all think we should re-add the XOR bytes? or do we no longer care if the world knows how many updates we did on unilateral close?
17:21 < adiabat> oh not in this doc I think, but XOR those 48 bits
17:21 < adiabat> yeah need that to keep privacy from watchers / others
17:21 < rusty> adiabat: oh, I got confused with "timeoutkey" because HTLCs also timeout, but if the other party offered them that doesn't go via a delayed output.  So delayed or indirect seems anicer term for the spec.
17:21 < rusty> adiabat: cool, what did you xor with ?
17:22 < adiabat> sha256 of the DH of the funding txs two pubkeys
17:22 < roasbeef> atm they way I implement it is that the initiator sends the bytes to XOR, and that's actually the additional hash for their 0th leaf in the revocation tree
17:22 < adiabat> could have inititor pick, and if they pick 0x000 or 0xfff or something, the other guy just says "nope"
17:23 < adiabat> but doing the DH means they can both know what it is and they've both added entropy, and nothing other to send on the wire
17:23 < adiabat> initiator pick is slightly less CPU I guess
17:23 < rusty> adiabat: generated and implicit is always nicer, no corner cases.  Hell, xoring the first two k values is probably fine.
17:24 < adiabat> first two k's is known by watcher though
17:24 < adiabat> if the watchers is wathcing both
17:24 < roasbeef> hmm     
17:25 < adiabat> the watcher will be able to correlate channels fairly easily
17:25 < adiabat> since they'll tend to progress together
17:25 < rusty> Yeah, sha of both directkey-base?
17:25 < rusty> SHA256(open-channel-directkey-base || accept-channel-directkey-base) ?
17:25 < adiabat> hmm, could do that instead, sort the direct-key-base and hash it?
17:26 < adiabat> or initiator / acceptor... though I like sorted better :)
17:26 < rusty> Well, one side sends open_channel the otehr sends accept-channel, so we already have nice asymmetry.
17:26 < adiabat> we might want to use fund-tx pubkeys DH for something else...?
17:26 < adiabat> seems like it could be useful to have a channel-specific shared secret?
17:27 < rusty> Let's keep it in mind when we find a nail...
17:27 < roasbeef> what's directkey-base? the funding key? 
17:28 < rusty> roasbeef: no, funding key gets exposed.  We need a new one.
17:28 < rusty> roasbeef: I originally thought we could have a simple "to-me" key and a "to-you" key per commit tx (aka localkey and remotekey). Turns out we can't, since watcher will know those.
17:29 < rusty> roasbeef: so now we need a key-when-youre-paying me and key-when-i'm-paying me (the watcher only needs the latter)
17:30 < roasbeef> ok, so what about the initiator picks 6 bytes, which aren't all zeroes or all f, then sends that over with the funding_created message
17:30 < rusty> I'll start the PR now..
17:30 < rusty> roasbeef: Nicer to know both sides contributed.  Plus some implementation can't use '0xDEADBF'.
17:31 < roasbeef> yeh or within the open/accept messages if both sides contribute, then xor those?
17:31 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-kpibxvzbqfkgmrbo] has quit [Quit: Connection closed for inactivity]     
17:33 < rusty> roasbeef: sha() avoids any information leakage.  Not that it should matter...
17:33 < roasbeef> are you making a PR for the obsfucated state num stuff or to fix the revocation key derivation?
17:33 < rusty> roasbeef: well, the second relies on the new field from the first, so I'll do the key derivation one first, then fix the state num obfuscation.
17:34 < rusty> But first, lunch(and a tech talk about beekeeping... go figure!)
17:35 < roasbeef> I don't see any dependancy between the two
17:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rujcfyldlkzjyqpx] has quit [Quit: Connection closed for inactivity]     
17:44 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qricqiicuidykdau] has joined #lightning-dev     
17:46 -!- ybit [~ybit@unaffiliated/ybit] has joined #lightning-dev     
17:50 < adiabat> I think he means sha() of both pubkeys, not initiator-supplied 6 bytes
17:50 < adiabat> in that case, the two pubkeys are the 'direct' base points, that go into the PKH outputs
17:50 < roasbeef> ahh gotcha
17:51 < roasbeef> but doesn't the watcher get the direct base points? 
17:51 < adiabat> no     
17:51 < adiabat> never sees anything PKH related
17:52 < adiabat> not needed for the penalty tx
17:52 < adiabat> (I still call it "justice tx")
17:52 < roasbeef> ah yeh, just the revocation since that what matters to restore "justice" 
17:52 < roasbeef> hehe
17:52 < roasbeef> or "judgement tx" 
17:53 < roasbeef> the latter makes me think of "Judge Dredd" lol
17:53 < adiabat> I mean penalty is more corporate sounding I guess
18:07 < rusty> eat-flaming-death-tx
18:08 < gmaxwell> trashaction.
18:08 < aj> gmaxwell: abbreviated "thx"
18:09 < gmaxwell> haha
18:15 < rusty> adiabat, roasbeef:wait, do we need the indirect-payment-basepoint now at all?  What happens if we just use static keys there instead?
18:17 < adiabat> we still need it to anonimize
18:17 < adiabat> I think...
18:17 < adiabat> yeah because the watcher needs to be able to regenerate the script
18:18 < rusty> No, the scripts are different forms, so you can tell which way each payment was going.
18:18 < adiabat> and if that's static, it'll show up
18:18 < rusty> adiabat: sure, we tell the watcher.
18:19 < adiabat> wait what is indirect-payment?  both keys in the script?
18:20 < rusty> adiabat: the payment to the second-stage HTLC tx.
18:20 < rusty> adiabat: (ie. any "to-me" payment which needs that CSV delay).
18:20 < adiabat> oh     
18:20 < adiabat> yeah the watcher never needs to use those
18:21 < adiabat> right..?  because those are in the HTLC outputs, which the watcher doesn't care about
18:21 < adiabat> only cares when they've moved over into the HTLC resolution tx output, which is the exact same script as the non-HTLC commit output
18:22 < rusty> adiabat: ... well, I was going to also use it for the HTLC tx outputscript, so it needs it there.
18:23 < adiabat> the HTLC *tx* output script is the same as the non-HTLC output script, right
18:23 < rusty> adiabat: Yeah.
18:23 < adiabat> there's 2 keys in that script
18:24 < adiabat> the OP_CSV one and the revocable one
18:24 < rusty> adiabat: well, we need to use the direct-payment key in the non-HTLC output script; that ensures the txid is unguessable by the watcher,
18:25 < rusty> adiabat: Hmm, scratch that.
18:25 < adiabat> direct is for the PKH output right?
18:26 < rusty> adiabat: yes, and it's also used in the HTLC script itself; either way, it is unknown to the watcher so only the most trivial commitment tx (output-to-me-only) has a guessable txid.
18:27 < rusty> adiabat: HTLC output script in the commitment tx, I mean.
18:29 < adiabat> right, and the output-to-me-only can only possibly happen in the beginning
18:29 < adiabat> and you'd never broadcast it... so just give them a dummy sig
18:30 < adiabat> but for indirect-payment-basepoint, that's still something the watcher needs to be able to generate
18:31 < rusty> adiabat: well, there's a corner case; a lower-than-dust payment causes a still-only-output-to-me with a lower amount.  This is decodable.
18:31 < adiabat> the OP_CSV encumbered key is in the script they need to reconstruct
18:31 < adiabat> right but ... would you even tell a watcher about that channel?
18:32 < adiabat> there's no point in watching it
18:32 < rusty> adiabat: good point.
18:32 < rusty> adiabat: yes, OP_CSV encumbered key (indirect-payment) needs to be known.  But can it be static?
18:32 < adiabat> so that could be a rule, don't send info to a watcher until there's an actual script
18:33 < adiabat> indirect-payment can't be static though, because it will show up on-chain later
18:33 < adiabat> in a valid / non-cooperative close
18:33 < rusty> adiabat: ah, yeah.  Great, thanks!
18:36 < adiabat> ok so the main changes are -- the PKH key has the simpler incrementing nonce construction
18:37 < adiabat> base + h(base || n)
18:37 < adiabat> where n = 1, 2, 3...
18:37 < adiabat> err + h(base ||n)*G I guess
18:37 < adiabat> or base*h() ... either way works in this case since everything is totally known
18:38 < adiabat> the revocable and indirect keys are made with the delinearization construction
18:39 < rusty> ObNomenclature:   k = per-commitment-secret.  K = per-commitment-point.
18:39 < adiabat> so 3 base points, exchange 2 points over the wire each time (revocable, indirect)
18:39 < adiabat> ah     
18:39 < adiabat> just one K needs to be sent over
18:39 < rusty> Indeed!
18:39 < adiabat> I think...?
18:39 < adiabat> yeah
18:39 < rusty> That's what I just typed.
18:40 < adiabat> yeah OK, right
18:40 < rusty> (in the spec patch, not here)
18:40 < rusty> I am just using K for all three keys.  I mean, why not?
18:40 < adiabat> ok that's pretty efficient
18:40 < rusty> Same formula, doesn't hurt.
18:40 < adiabat> the key construction with delinearization is a bit CPU costly but I think worth it to avoid weird edge cases
18:41 < adiabat> 2 hashes, 2 mults and an add
18:41 < rusty> Here's what I have for open_channel pkt (and accept):
18:41 < rusty>    * [33:funding-pubkey]
18:41 < rusty>    * [33:revocation-basepoint]
18:41 < rusty>    * [33:direct-payment-basepoint]
18:41 < rusty>    * [33:delayed-payment-basepoint]
18:41 < adiabat> delayed = indirect?  actually I like the term delayed better
18:42 < rusty> yeah, I flipped a coin.
18:57 < rusty> Hmm, direct key can be used to pay to the 2of2 HTLC tx, which feels a bit neater.  But now the name "direct" is bad.  s/direct-/ maybe...
19:01 < adiabat> PKH / HTLC... yeah no good name to call it
19:01 < adiabat> PKHTLC
19:07 < roasbeef> why cant the direct and delayed points just be combined into one? theyd change induvidually with each state as is, wpuld reduce the number of keys to manage for a single channel
19:08 < roasbeef> also im not personally convinced as to whats gained with the additional hashes during derivation. if you give me a point you cant revoke, then well the channel is over, we dont transisition states
19:09 < rusty> different points: Because we want the watcher to be able to generate the delayed keys, but NOT figure out previous txids by guessing contents.
19:09 < adiabat> yeah, they will observe the PKH once it's spent, and grind through to figure it out
19:09 < rusty> Using unpredictable direct keys helps with this (every non-trivial commitment tx uses these somewhere)
19:10 < rusty> adiabat: hmm, can't they recognize the use of the timeout key anyway though in a unilateral close?
19:10 < adiabat> Acutally the trivial ones use it as well right?  trivial has no script hash output
19:11 < adiabat> timeout key (indirect) changes every time so they won't recognize it
19:11 < rusty> adiabat: err, yeah.
19:11 < rusty> adiabat: no, they can reproduce indirect key, right?  They have base point and k.
19:11 < rusty> adiabat: ah, but not for the latest one.  Of course.
19:12 < rusty> (ie. they obviously don't have K for a unilateral close, since it's not revoked yet)
19:12 < adiabat> I think having the direct key combined the right way makes it unguessable after they've seen it
19:12 < adiabat> that's where the real entropy comes from
19:13 < rusty> adiabat: direct key isn't in the HTLC-Success or HTLC-Timeout txs though,which you'd still use for normal unilateral.  In that case, unknown K saves you.
19:13 < adiabat> they know all the previous commit txids (or half, but that's enough) but they don't know the 20 byte PKH output
19:14 < adiabat> that 20 bytes change each time, and the pubkey itself changes each time, and without knowing the base (which you can't derive even from observing all of them) you can't link it to the known txids
19:14 < rusty> roasbeef: to answer your second question: adiabat pointed out that if you can provide a bogus revocation pubkey, I will sign the commit tx, you can use that key (presumablt you know the secret key) to avoid the normal CSV delay.  That reduces the incentive for a mutual close.
19:15 < adiabat> roasbeef: it's not really an "attack" I guess, but it's ugly enough that if we can avoid it at low cost, probably better to
19:15 < rusty> adiabat:  no, HTLC-Success tx has only revocation pubkey and delayed-key in it.  They *can* generate those.
19:15 < adiabat> though yeah, I've had that in my code for a while and figured "whatever"
19:16 < rusty> adiabat: yeah, incentive problems for mutual close vs unilateral got worse if one side is paying all the fees. 
19:16 < adiabat> wait, HTLC-success can be generated..?
19:16 < rusty> adiabat: no, but they can recognize it when I spend it.
19:16 < adiabat> the keys, yes, but the hash isn't known
19:16 < adiabat> ah right
19:17 < rusty> adiabat: ... yeah, as I said, in *that* case we're relying on unknown K.
19:17 < adiabat> right because even though they're the "same" htlcs
19:17 < adiabat> the keys change each time
19:18 < adiabat> actually once there are HTLCs you don't really need the entropy from the direct key changing each time...
19:18 < adiabat> but easier to leave in, because many commit numbers won't have any HTLCs
19:20 < rusty> Yes.
19:28 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xsecnlwrykzdqdwh] has joined #lightning-dev     
20:01 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qricqiicuidykdau] has quit [Quit: Connection closed for inactivity]     
20:01 < rusty> OK, I ended up back at "pubkey = basepoint + SHA256(per-commit-point || basepoint)*G" for key and delayedkey. For revocation key we have the more complex revocationkey = revocation-basepoint * SHA256(revocation-basepoint || per-commit-point) + per-commit-point*SHA256(per-commit-point || revocation-basepoint)
20:02 < rusty> We could have used commitnum for direct key, but that makes 3 variants which I disliked.
20:06 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell opened pull request #8: BOLT 2/3: watcher-compatible key derivation. (master...fix-derivation) https://git.io/vX9Hc
20:12 < adiabat> I think that works.  I'd suggest for key/delayedkey multiply by the hash instead of adding the hash*G
20:13 < adiabat> saves a tiny bit of time, and it feels more similar to the other construction
20:13 < adiabat> pubkey = basepoint * sha256(per-commit-point || basepoint)
20:14 < rusty> adiabat: that's slower, not faster.
20:14 < rusty> adiabat: my benchmarks were on that exact construction.
20:14 < rusty> (multiplying by G is faster than by random number)
20:15 < adiabat> ohhh
20:15 < rusty> gtg, bbl will read logs.
20:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []     
20:15 < adiabat> because G is all optimized?
20:15 < adiabat> ok     
20:15 < adiabat> either is fine then
20:15 < adiabat> see ya
20:25 < roasbeef> adiabat: yeah since for the fixed-base "G", most implementations have a pregenerated lookup table which of multiples of G, so you end up just adding together items from that table 
20:25 < roasbeef> which contains* 
20:26 < adiabat> ok yeah that's faster then even though it feels like "more work"
20:26 < adiabat> in practice I think all these point add/mults are going to be so fast nobody will ever notice
20:27 < roasbeef> yeah, disk and network latency will be where the beachball spins
20:28 < adiabat> hopefully less than 1 rotation
20:47 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has quit [Quit: .]     
20:48 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:5c15:40e6:5986:2db4] has joined #lightning-dev     
21:08 -!- aalex [~aalex@64.187.177.58] has joined #lightning-dev     
21:15 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
22:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-yqdqfcolkzapzhkm] has joined #lightning-dev     
23:12 -!- aalex [~aalex@64.187.177.58] has joined #lightning-dev     
23:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
23:26 -!- roidster [~chatzilla@71-84-219-33.dhcp.ccmn.ca.charter.com] has quit [Ping timeout: 268 seconds]