--- Day changed Wed Nov 30 2016 00:44 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 00:44 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev 01:06 -!- laurentmt [~Thunderbi@80.215.138.206] has joined #lightning-dev --- Log closed Wed Nov 30 01:20:46 2016 --- Log opened Wed Nov 30 01:21:01 2016 01:21 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev 01:21 -!- Irssi: #lightning-dev: Total of 65 nicks [0 ops, 0 halfops, 0 voices, 65 normal] 01:32 -!- Irssi: Join to #lightning-dev was synced in 704 secs 01:32 -!- jannes [~jannes@178.132.211.90] has joined #lightning-dev 02:17 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 02:19 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Ping timeout: 258 seconds] 02:19 -!- HostFat_ [~HostFat@host98-208-dynamic.49-82-r.retail.telecomitalia.it] has joined #lightning-dev 02:19 -!- murchandamus [~murchghos@ghostdub.de] has quit [Ping timeout: 258 seconds] 02:19 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds] 02:19 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 258 seconds] 02:19 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 258 seconds] 02:19 -!- HostFat [~HostFat@host98-208-dynamic.49-82-r.retail.telecomitalia.it] has quit [Ping timeout: 258 seconds] 02:19 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 02:19 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-xnqfwqxbdcsbtjnn] has quit [Ping timeout: 258 seconds] 02:20 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #lightning-dev 02:22 -!- inara` [~inara@68.ip-149-56-14.net] has joined #lightning-dev 02:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 02:23 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #lightning-dev 02:23 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ejtytqdujyeigdej] has joined #lightning-dev 02:23 -!- emschwartz [sid151392@gateway/web/irccloud.com/x-rfqfzqwydwdaeeng] has quit [Ping timeout: 252 seconds] 02:24 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #lightning-dev 02:25 -!- stevenroose [~steven@vps.weuste.club] has quit [Ping timeout: 258 seconds] 02:25 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 258 seconds] 02:25 -!- inara [~inara@68.ip-149-56-14.net] has quit [Read error: Connection reset by peer] 02:25 -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 258 seconds] 02:25 -!- stevenroose_ [~steven@vps.weuste.club] has joined #lightning-dev 02:25 -!- cfields [~quassel@unaffiliated/cfields] has joined #lightning-dev 02:26 -!- emschwartz [sid151392@gateway/web/irccloud.com/x-ozgjgsgdcniuqvyk] has joined #lightning-dev 02:26 -!- stevenroose_ is now known as stevenroose 02:31 -!- murchandamus [~murchghos@ghostdub.de] has joined #lightning-dev 03:17 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 03:19 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Client Quit] 03:39 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds] 03:41 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #lightning-dev 03:45 -!- molz [~molly@unaffiliated/molly] has joined #lightning-dev 03:47 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 04:02 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 04:03 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 04:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xtoxfgjzzibqrhnm] has joined #lightning-dev 05:43 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has joined #lightning-dev 06:00 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 06:01 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Client Quit] 06:54 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 06:56 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Client Quit] 07:21 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev 07:41 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev 07:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 246 seconds] 07:57 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4dbd:d6b8:36ed:7512] has quit [Quit: .] 08:00 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4dbd:d6b8:36ed:7512] has joined #lightning-dev 08:12 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev 08:16 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 250 seconds] 08:22 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 08:22 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Client Quit] 08:39 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev 08:43 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 248 seconds] 08:48 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 08:54 -!- aalex__ [~aalex@64.187.177.58] has joined #lightning-dev 08:58 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 09:23 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Quit: laurentmt] 09:30 -githubby:#lightning-dev- [lightning] cdecker opened pull request #99: New wire serialization/deserializtion (master...wire) https://git.io/v1339 09:54 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 09:54 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Client Quit] 10:00 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 10:13 -!- sstone [~sstone@3.46-14-84.ripe.coltfrance.com] has quit [Quit: Leaving] 10:17 -!- laurentmt [~Thunderbi@80.215.138.96] has joined #lightning-dev 10:22 -!- laurentmt [~Thunderbi@80.215.138.96] has quit [Quit: laurentmt] 10:48 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 10:56 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #lightning-dev 11:00 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #lightning-dev 11:00 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 11:00 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 11:06 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev 11:10 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 11:11 -!- aalex [~aalex@64.187.177.58] has joined #lightning-dev 11:14 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 11:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 11:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:50 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev 11:51 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 12:01 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ejtytqdujyeigdej] has quit [] 12:04 -!- btcdrak_ [uid165369@gateway/web/irccloud.com/x-rsuodddoxxliivxv] has joined #lightning-dev 13:13 -!- moli [~molly@unaffiliated/molly] has joined #lightning-dev 13:15 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 13:35 -!- wraithm_ [~textual@205.197.160.100] has joined #lightning-dev 13:37 -!- wraithm [~textual@205.197.160.100] has quit [Ping timeout: 260 seconds] 13:39 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 13:41 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 14:06 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 14:07 -!- wraithm_ is now known as wraithm 14:14 -!- HostFat__ [~HostFat@host98-208-dynamic.49-82-r.retail.telecomitalia.it] has joined #lightning-dev 14:18 -!- HostFat_ [~HostFat@host98-208-dynamic.49-82-r.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds] 14:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:02 < rusty> cdecker: nice, please merge your PR. We can renumber later if required. 15:02 < rusty> (But I don't think we will, too much pain) 15:21 < rusty> adiabat: hmm I think we returned to only sending one value across the wire anyway, in the current spec, but that could be wrong (since it's unimplemented). Look forward to reading your changes... 15:24 < rusty> (Also, I have a pending blog post about this, but it's going to have to be delayed again until the details are finalized I think!) 15:40 -!- Piper-Off is now known as Monthrect 15:54 < rusty> adiabat: hmm, trying to figure out watcher and obscuring the HTLC-success and HTLC-timeout txs. The only thing it can't guess (and isn't given) about these txs is the txid of the commitment tx it's spending, right? So we *must* hand the watcher only a partial (eg. 96 bit) txid prefix? 16:04 < rusty> adiabat: hmm, can we use key recovery from the signatures to save some space somehow? ,... maybe not... 16:16 < adiabat> rusty: right, I think the 1 pubkey over the wire is the same. Not updating the direct key is nice. Also since it never changes, we don't even have to send the pubkey itself when starting the channel, could just send the 20-byte pubkey hash 16:18 < rusty> adiabat: if we don't change the direct key, then I think we have a problem with txid guessing. 16:18 < adiabat> I don't think we do, but definitely need to make sure 16:19 < adiabat> HTLC-resolve txs should be safe either way I think 16:19 < adiabat> they're only sent to the watcher once they're no longer valid 16:20 < rusty> adiabat: So, startup case where it's all to-self-with-delay. We agreed this is determinable by watcher, but doesn't really matter? 16:21 < adiabat> yeah startup case probably should just lie to the watcher and make up a signature 16:21 < rusty> adiabat: it can tell, I think. 16:21 < adiabat> since the watcher can't do anything anyway 16:21 < rusty> adiabat: well, if you're opening channel with me, I want watcher to catch it for real, right? 16:22 < adiabat> rusty: channel is open but only one side has any money? 16:22 < rusty> adiabat: Yeah. And since it knows the witness script, it can grind out the rest of the tx values pretty easily. 16:23 < rusty> adiabat: Now, if we use a static direct key, and it gets hold of this (because cheat attempt), it can similarly grind out all the other commitment txs with no HTLCs, right? 16:23 < adiabat> rusty: wait, watcher knows the witness script for what? 16:24 < adiabat> rusty: oh I've assumed cheat attempt means privacy is totally gone 16:24 < adiabat> rusty: you're trying to preserve some privacy even when the watcher actually *does* something? 16:24 < rusty> adiabat: the to-local output is P2WSH, with witness script "IF revocation key ELSE to-self-delay CSV DROP local-delayedkey ENDIF CHECKSIG". 16:25 < adiabat> rusty: haven't thought through that, seems like a super out there edge case... 16:25 < rusty> adiabat: yeah, agreed, but y'know... 16:25 < adiabat> rusty: ok hmmm will look at it in that context 16:25 < adiabat> rusty: so try to protect previous HTLC-resolves even once the channel outpoint is known... 16:27 < rusty> adiabat: yeah, maybe it breaks down at that point. 16:29 < rusty> Yes, I think it knows enough to brute force the history then. Unfortunate. 16:32 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 16:33 -!- moli [~molly@unaffiliated/molly] has joined #lightning-dev 16:34 < adiabat> only if it knows the set of possible HTLC hashes though, right? 16:34 < rusty> adiabat: or not... it doesn't know (or need to know) the localkey or remotekey bases, which are used in the HTLC output (witness) script. So it can't determine the txids. 16:35 < rusty> adiabat: Yes, I'm assuming that, and it can guess amounts. 16:35 < adiabat> rusty: ok I'm still a little unsure of terms, direct key is used for the p2wpkh output 16:36 < adiabat> indirect base is what both people modify and put in the non-htlc script 16:36 < adiabat> local and remote are used in htlc scripts only 16:36 < rusty> adiabat: I think we do want to frob the other side's p2pkh key, though, because it could at least figure out when we had no HTLCs otherwise. 16:37 < adiabat> right? so yeah in that case the local/remote helps... 16:38 < adiabat> rusty: how does it figure out when no HTLCs were in the commit, other than checking number of signatures given (which it knows anyway?( 16:39 < rusty> adiabat: in BOLT 3 as it stands, I have which is used in both HTLCs and direct outputs, which is used in the CSV-delayed to-me output, and the HTLC outputs, and which is used only for the HTLC-success and HTLC-timeout output (so that it can be told to the watcher) 16:39 < rusty> adiabat: We can add bogus sigs. 16:40 < rusty> adiabat: but watcher can try all the possible balances to see if this txid prefix matches, for example. 16:41 < rusty> adiabat: so, if a commit tx has no htlcs, if it knows what the to-remote output would look like (because static key), and it needs to know what the to-self output would look like (because it would need to create penalty tx), it's pretty easy. 16:43 < rusty> Once it's ground out the balances, it will be able to guess what HTLCs went through pretty well, I think. 16:44 < adiabat> does the watcher know both htlc hashes and amounts and tries to match those? 16:44 < rusty> adiabat: presumably, because NSA. 16:44 < adiabat> I can see how changing the pkh output could maybe help hide balances once the penalty-tx happens... 16:45 < rusty> adiabat: HTLCs are protected by that and which *do* change every time, and *are not* known by the watcher. 16:45 < adiabat> there might be other attacks though, I've always just thought if the penalty happens you lose ~all privacy, but there may be ways to salvage some 16:45 < rusty> adiabat: so even if you know which HTLC, you can't determine what the scriptPubKey of the commitment tx would be. 16:46 < adiabat> right... one other (small) help is that the watcher doesn't know the com number hint 16:46 < adiabat> that's only 6 bytes though 16:46 < rusty> adiabat: ... and it does once it sees a commitment tx, because xor. 16:47 < adiabat> ah once it does the penalty and links up the channel yeah 16:48 < rusty> Now, similarly, HTLC-Timeout and HTLC-Success signatures risk leaking something. 16:48 < adiabat> so ideally, even once the watcher generates and broadcasts the penalty-tx... they learn the final state and where the channel was, but hopefully don't learn all the previous balances 16:48 < rusty> Yep! 16:48 < adiabat> hmm. that's harder :) 16:48 < adiabat> but yeah, if we can improve that, it's worth it 16:50 < rusty> adiabat: Now, re signatures leaking. If watcher can grind out what the HTLC-timeout or HTLC-success might be, they can test signature and see if they're right. 16:50 < adiabat> will have to sketch it out, but changing the pkh address seems like it would help there. maybe change the htlc-output scripts as well somehow 16:51 < rusty> adiabat: there's not many variables here they can't grind; they know the witness program (needed to spend), so I think we need to rely on the txid of the commitment tx being unknown. 16:52 < adiabat> rusty: they have to have some of the txid 16:52 < adiabat> but they shouldn't be able to figure out the rest of it 16:52 < rusty> adiabat: yeah, but not too much! 16:53 < rusty> Bitcoin already likes 160 bit security, so I would say 96 bits of txid? 16:54 < adiabat> bitcoin has 128 bit security... 16:54 < rusty> Though I don't think you can attack multiple at once, so 128 is probably sufficient. 16:54 < adiabat> 80 bits in the current p2sh setup... 16:55 < adiabat> but yeah if we want to send 12 bytes of the txid instead of 16 that's OK 16:55 < adiabat> collisions are still pretty hard to make, but more importantly collisions don't really do anything 16:55 < rusty> adiabat: Yeah, I guess this was for my own education. When we dropped the 'encrypt with txid' idea, I thought the txid became non-sensitive info, but this shows I was wrong. 16:56 < rusty> adiabat: yeah, DoS only. 16:56 < rusty> adiabat: hey, are we having fun yet? 16:56 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #lightning-dev 16:56 < adiabat> yeah you still don't want to send the whole txid... though really... hmm I have to draw this out 16:57 < adiabat> rusty: heh, yeah, fun edge cases! I mean it doesn't really matter because this will, like, never happen, and if it does, oh well, they found out about your old payments... but they also found out about all your money etc anyway... 16:58 < adiabat> rusty: but to the extent we can maintain privacy of the history we should 16:58 < adiabat> rusty: htlc-resolve outputs all having the same address might be not so good in that case... 16:58 < rusty> adiabat: yeah, I think you infected me with your idea that the more private we can make it, the wider it can spread. 16:58 < rusty> adiabat: yeah, see the current BOLT #3, all addresses change. 16:59 < adiabat> but not within one commit 17:00 < rusty> adiabat: no, that would be overly paranoid AFAICT. Four keys should be enough for anyone (local, remote, delayed-local, recovery) 17:01 < adiabat> right, but the localkey and remotekey are re-used within the same 'height' 17:01 < adiabat> if you have multiple htlcs 17:02 < rusty> adiabat: yes. I think that's OK. 17:04 < adiabat> rusty: iin the bolt 3 doc, it says "local-delayedkey" just has an increment counter... but that key is in the script of the to-local output right? 17:05 < adiabat> rusty: I don't think local-delayedkey can be incrementing nonce based. In my code it uses the hash tree, and I think it needs to 17:05 < rusty> adiabat: it is. "per-commit-point" = k. 17:05 < rusty> Line 315 17:06 < rusty> These keys are simply generated by addition from their base points: 17:06 < rusty> pubkey = basepoint + SHA256(per-commit-point || basepoint)*G 17:08 < adiabat> yeah, can't have that... the watcher knows the local-delayedkey base 17:09 < rusty> Sure, and they need to. They need to penalty-psend the to-local output too! 17:09 < adiabat> so a non-fraudulent, non-cooperative close 17:09 < adiabat> reveals the current local-delayedkey 17:09 < rusty> They don't know the per-commit-point though 17:09 < adiabat> (well, doesn't reveal it directly, but once that script hash is spent) 17:09 < adiabat> but the per-commit-point is just a number, so they can grind through pretty quick 17:10 < adiabat> not only that, they'll know the number, or at least a pretty close lower bound; k must be higher than the number of states they're watching 17:11 < rusty> adiabat: no, line 229 17:11 < rusty> err... 337 17:11 < rusty> The `per-commit-point` is generated using EC multiplication: 17:11 < rusty> per-commit-point = per-commit-secret * G 17:11 < rusty> I really need to select between "commit" and "commitment", gah! 17:12 < adiabat> wait which is the nonce based derivation? 17:12 < adiabat> secretkey = basepoint-secret + SHA256(basepoint || commit-number) 17:12 < adiabat> that is for localkey and local-delayedkey 17:13 < rusty> adiabat: oops, that's very wrong. 17:14 < rusty> adiabat: let me push a fix right now... 17:14 < adiabat> ok. I need to go through this whole doc though... I think having the to-remote, pkh output being nonce based is OK 17:16 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:21 < adiabat> remotekey and localkey as well can have the nonce based derivation. But yeah I guess you can't have static remotekey for the to-remote output... 17:21 < adiabat> you could probably get away with like, a specific nonce for the to-remote output, but nah, just keep using the nonce-based since you need it anyway in other places 17:22 < rusty> I like the simplicity of having one derivation formula. (Well, two, as revocation key is more complex) 17:23 < adiabat> right, revocation and local-delayedkey both use delinearization scheme 17:23 < adiabat> the rest can all be nonce based 17:24 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell pushed 1 new commit to master: https://git.io/v1sga 17:24 -lightningrfc:#lightning-dev- lightning-rfc/master 10f49ec Rusty Russell: BOLT 3: Fix incorrect secret derivation.... 17:26 < rusty> adiabat: Well we don't need local-delayedkey derived like the revocation key (using both multiply and add). And using a counter instead of commit number saves us very little on the other key, hence this construction. 17:28 < adiabat> rusty: local-delayedkey can't be nonce based, it has to be hash-tree based 17:28 < rusty> adiabat: exactly. So, we *could* have three schemes. 17:28 < adiabat> doesn't *have* to be the delinearization construction I guess, but I'd rather have 2 than 3... 17:28 < rusty> adiabat: me too. So that's why all keys use the hash-tree and we don't use commit number. 17:30 < rusty> adiabat: (That line which I've now patched ^^ was a remnant from before we discussed delinearization constructs; BOLT 3 never used commit-number) 17:32 < adiabat> rusty: ok so the new version, there is no nonce-based derivation? it's all hash-tree? 17:33 < adiabat> in that case why not just use the same derivation for everything? 17:40 < rusty> adiabat: yes, all hash-tree. 17:41 < adiabat> rusty: I mean all delinearization as well 17:41 < rusty> adiabat: seemed overkill, really? We could. 17:41 < adiabat> is it slower? maybe a little 17:42 < rusty> adiabat: ah, no, it's different anyway. 17:42 < rusty> adiabat: revocationkey, unlike the others, relies on the fact that per-commitment-point is the per-commitment-secret * G. 17:42 < rusty> adiabat: so you can only derive the secret key later. For the others, you need the secret key now. 17:43 < adiabat> rusty: heh oh yeah... 17:43 < rusty> adiabat: so I think 2 is as few as we can have. 17:44 < adiabat> rusty: but I still think local-delayedkey can't be derived the same way; that key can be done with the delinearization method instead 17:45 < rusty> I think this method is sufficient to obscure it. The full delinearization is only required for the revocation key to ensure no side knows the secret key without the other. 17:45 < adiabat> rusty: maybe it doesn't matter... maybe there's still no way to get it. but the watcher has the base point for local-delayedkey 17:46 < adiabat> delinearization has another benefit 17:46 < rusty> adiabat: yep! Still doesn't help it get the final local-delayedkey, since it doesn't know the per-commitment-point. 17:46 < adiabat> it stops the watcher from using known base points to link the two keys 17:46 < adiabat> but yeah maybe only one of them is sufficient. 17:47 < rusty> adiabat: yes, it absolutely has to be. 17:51 < rusty> adiabat: even if they see two commit txs for which they know per-commitment-point, it's still intractible AFAICT. 17:52 < adiabat> rusty: what's the benefit of adding the sha(comPoint, basepoint)*G 17:52 < adiabat> instead of just adding the comPoint? 17:53 < adiabat> so watcher never learns basepoint I guess? 17:53 < rusty> adiabat: yeah. 17:53 < rusty> Even if they know comPoint, basepoint is still obscured. 17:54 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 17:54 < adiabat> makes sense. This probably is about as good as you can do it... 17:54 < adiabat> still should run it by sipa though :) 17:54 < rusty> It was sipa's original proposal, actually :) 17:55 < rusty> https://botbot.me/freenode/secp256k1/2016-11-14/?msg=76426917&page=1 17:56 < adiabat> heh, cool 17:56 < rusty> adiabat: my only talent is parroting other people :) 17:56 < adiabat> oh also the delinearization, I implemented the same as for the schnorr sigs even though it does some things that only are needed with >2 keys 17:57 < rusty> OK, what does that end up looking like? 17:57 < adiabat> like it sorts the pubkeys to get the "combination commitment" (sipa's term, not mine :) 17:57 < adiabat> https://github.com/mit-dci/lit/blob/master/lnutil/curvelib.go#L114 17:58 < adiabat> I figure, just make it the exact same code as will be used in bitcoind, then we won't have to worry about it once schnorr sigs get in and that function is part of the library 18:03 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 18:06 < rusty> adiabat: Except they may well change it between now and then. Hmm, this takes N pubkeys and derives 1. Where would we use this? 18:07 * rusty keeps reading the code... 18:08 < rusty> Ah, right, you map K to a key, then use this to combine with the basepoint. 18:09 < rusty> Ah, no, that's just the per-commitment-point. OK. 18:10 < adiabat> yeah it may change... hopefully the construction will be finalized for schnorr before we have to release anything for mainnet 18:12 < rusty> Hmm, that's basepoint * SHA(sorted(basepoint || per-commitment-point)) + per-commitment-point * SHA(sorted(basepoint || per-commitment-point)) If I decode correctly. 18:18 < adiabat> Not quite; written out completely it'd be: 18:18 < adiabat> [basepoint * sha(sha(sort(basepoint, compoint)), basepoint)] + [compoint * sha(sha(sort(basepoint, compoint)), compoint)] 18:18 < adiabat> sha(sorted(points)) is the "combination commitment", which I label "z" 18:19 < adiabat> so then its: 18:19 < adiabat> [basepoint * sha(z, basepoint)] + [compoint * sha(z, compoint)] 18:21 < rusty> adiabat: pretty trivial change, but I'd prefer to make it now rather than later. I'll ask sipa how set in stone this construction is. 18:22 < adiabat> oh yeah I asked if it was sha256 or sha256d, he said he hadn't decided yet. Doesn't really matter, but yeah, having it be the same would be very nice 18:24 -!- HostFat_ [~HostFat@host14-245-dynamic.49-79-r.retail.telecomitalia.it] has joined #lightning-dev 18:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 18:27 < adiabat> also I would go with sha256d, because that was Satoshi's Vision :) 18:28 -!- HostFat__ [~HostFat@host98-208-dynamic.49-82-r.retail.telecomitalia.it] has quit [Ping timeout: 250 seconds] 18:48 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 18:49 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 18:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xtoxfgjzzibqrhnm] has quit [Quit: Connection closed for inactivity] 18:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 18:57 * rusty reads logs, throws up a little at adiabat's "Satoshi's Vision" comment.... 19:10 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 260 seconds] 19:10 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 19:15 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 19:17 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 19:18 -githubby:#lightning-dev- [lightning] rustyrussell fast-forwarded master from 6905cf5 to f85f2c6: https://git.io/v1s6F 19:20 -githubby:#lightning-dev- [lightning] rustyrussell closed pull request #99: New wire serialization/deserializtion (master...wire) https://git.io/v1339 19:41 -lightningrfc:#lightning-dev- [lightning-rfc] Roasbeef closed pull request #28: Splitting BOLT01 into messaging and transport specs (master...reorg) https://git.io/v1LTy 19:49 < roasbeef> holy scrollback batman 19:49 * roasbeef reads the mountain of chat 20:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 21:31 -!- molz [~molly@unaffiliated/molly] has joined #lightning-dev 21:34 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 21:36 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 22:17 -!- btcdrak_ [uid165369@gateway/web/irccloud.com/x-rsuodddoxxliivxv] has quit [] 22:20 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uazuitehuivwpwko] has joined #lightning-dev 22:20 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 260 seconds] 22:21 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uazuitehuivwpwko] has quit [Client Quit] 22:21 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-dpoacivzzknmmqke] has joined #lightning-dev 22:22 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 22:29 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Ping timeout: 260 seconds] 22:29 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 22:34 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 22:35 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 22:48 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 22:49 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 22:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hfkljsoftdntytqx] has joined #lightning-dev 22:54 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 23:01 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 23:06 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 23:08 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 23:13 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 23:14 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #lightning-dev 23:18 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 23:19 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 23:25 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 23:25 -!- moli [~molly@unaffiliated/molly] has joined #lightning-dev 23:25 -!- aalex_ [~aalex@64.187.177.58] has joined #lightning-dev 23:26 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev 23:28 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 23:50 -!- maaku_ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 23:52 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #lightning-dev