--- Day changed Wed Oct 17 2018 00:01 < BlueMatt> just receive an extended private key from which we derive key material, but that isnt so interesting 00:02 < BlueMatt> then have an Event that we can generate that's like "you gotz moneyz" that just has a privatekey and a type enum (eg for htlc scripts they need to know extra things to be able to spend) 00:02 < BlueMatt> or if its a cooperative close its simpler, just generate that event with a privkey 00:02 < BlueMatt> that should cover it, no? 00:36 < ariard> I think for revocation case, obviously we need to give back the privkey, as giving only remote per-commitment secret will bind user wallet to be aware of LN key scheme 00:39 < ariard> then have an Event that we can generate that's like "you gotz moneyz" that just has a privatekey and a type enum (eg for htlc scripts they need to know extra things to be able to spend) // there we send back to user the private key + preimage/redeemScript if needed 00:42 < ariard> for the tree form, I think we can have multiple level of depth, /per-connection/per-chain/per-channel/per-commitment ? 00:43 < BlueMatt> yea, I dont care too much about the way we do the key derivation, just something deterministic based on some hd key the user gives us 00:44 < BlueMatt> though ideally not just incremental 00:45 < BlueMatt> hmmmm, so here's an issue: if we just do something deterministic like use N for the Nth channel we generate we have to make sure the user persists that info reliably too, which kinda sucks 00:45 < BlueMatt> ideally the user should only have to reliably persist ChannelMonitor and if ChannelManager data gets lost somehow we just go on chain and thats ok 00:45 < ariard> yeah there is also the max commitment of 2^31 00:45 < ariard> which is far under bolt 3 max secret storage 00:45 < BlueMatt> well I'm not /too/ worried about users creating more than 4 billion channels :p 00:46 < BlueMatt> so maybe its best to just have random keys per-channel? 00:46 < BlueMatt> and just have the event for "hey, here's a key"? 00:46 < BlueMatt> as long as ChannelMonitors can always claim the funds 00:46 < ariard> well what does others implementations are doing ? 00:47 < BlueMatt> (ie during normal operation a user will fsync() ChannelMonitor updates, but ChannelManager storage they can be a bit lazy about for performance, and things usually work, but when they dont the just force-close everything, if they want) 00:47 < BlueMatt> I presume they fsync() the everloving shit out of everything? 00:48 < ariard> so no HD derivation ? because if yes user has to persist derivation path ? 00:48 < BlueMatt> well the concern is just that you have to persist the total number of channels you've had 00:48 < BlueMatt> its not much, but its really annoying that you have to fsync() that all the time 00:48 < BlueMatt> as otherwise you could end up re-using keys after a crash 00:49 < BlueMatt> within a channel we can do HD 00:49 < BlueMatt> for the ChannelKeys creation 00:49 < BlueMatt> instead of the HMAC thing it does now 00:49 < ariard> yes and you just have to backup per-channel master key and min seen secret right ? 00:50 < BlueMatt> well you have to back up ChannelMonitors 00:50 < BlueMatt> same as any lightning impl, if you dont back up your ChannelMonitors you're screwed 00:52 < BlueMatt> eg I think lnd can figure out on-chain balances for non-lightning balances from its seed backup, but I presume that would be true of any wallet build on rust-lightning, and they'd just immediately spend any not-to-their-HD-keys outputs 00:52 < ariard> yeah that's sure, so with this and #55 user should be safe 00:52 < BlueMatt> so maybe *just* the event interface? 00:52 < BlueMatt> I /hope/ #55 doesn't change safety 00:52 < BlueMatt> eg even if you *never* write the ChannelManager to disk, ChannelMonitors can always get your money back on crash 00:53 < BlueMatt> there's probably a little bit of exposing stuff to be done there, but... 00:53 < BlueMatt> they have the data, at least 00:53 < ariard> no I mean to ease backup, that's isn't the on-disk thing 00:53 < BlueMatt> yea, I mean ChannelManager serialization would *also* include all the Channel-latest ChannelMonitors 00:54 < BlueMatt> I guess we should let the user specify an HD key that we use only for shutdown_scriptpubkey? 00:54 < BlueMatt> since there's no harm (except privacy) if that gets duplicated? 00:54 < ariard> and channel_monitor_claim_key 00:54 < BlueMatt> and the privacy there is already (probably) tied to node_id w/i lightning 00:54 < ariard> speaking of node_id, should we also derive it from HD key? 00:55 < BlueMatt> oh, right, yea, that's gotta be persisted 00:55 < BlueMatt> so I guess just two things we want the user to provide - node_id and shutdown_scriptpubkey (keys) 00:55 < BlueMatt> so like, I guess, a single hd key where /0 is node_id and /N is shutdown_scriptpubkey? 00:56 < BlueMatt> well /0' and /N' 00:56 < ariard> and the path for per-channel master key from then ? it leave entirely to us we agree on this? 00:57 < BlueMatt> hmm? no I think per-channel keys have to be random per-channel 00:57 < BlueMatt> to avoid making the user fsync() ChannelManager updates 01:00 < ariard> yes that's what I meant, just to be sure we don't go this way 01:02 < BlueMatt> anyway, I'm rather jetlagged...gonna probably rewrite the synchronization in ChannelManager tomorrow (cause its kinda broken wrt ChannelMonitors) then maybe #55 01:02 < BlueMatt> started working on #61 the other day and just keep running into walls finding existing bugs that need fixing first :( 01:03 < BlueMatt> speaking of...gonna go merge 210 01:03 < BlueMatt> #55 turned into a bigger project than I thought, and I thought it was gonna be big :( 01:04 < ariard> oh you want it to get done before LN hacking days, right ? 01:04 < BlueMatt> yea, well 55 doesn't actually matter much for ln hackday, I just started it and dont want to put it down to have my already-big patch bitrot :( 01:04 < BlueMatt> err, 61 01:04 < BlueMatt> but I may have to if I want to get 55 done in time :( 01:04 < ariard> I didn't dig into yet, will focus on key thing first and if you need help will review it or can help 01:05 < BlueMatt> I think 210 is simple enough, I'm not too worried about it, 61 is gonna be gnarly, though 01:05 < BlueMatt> anyway, night! 01:06 < ariard> and will review 208 to leave, see you later :) 01:06 < ariard> *before 11:26 < stevenroose> just noticed this in python-trezor: now you can *import* typing in Python!: `from typing import Dict, Any, Iterable, Type, Optional` 16:25 < stevenroose> andytoshi: regarding FromStr for OutPoint, can the error for 75+ and leading zeroes just be the same as the invalid Format one? Or you prefer specific `TooLarge` and `IndexLeadingZeroes` ones? 16:32 < andytoshi> yep, it can be the "invalid format" one 16:33 < andytoshi> i'm mostly indifferent to specific errors tbh 17:02 < stevenroose> yeah I created errors and pushed already sorry 17:02 < stevenroose> can change if it matters, it just seems silly to have 5 error cases for such a simple thing 17:47 < andytoshi> all good 17:47 < andytoshi> nah, error codes are cheap 17:47 < andytoshi> i guess when we hit 256 then we need an extra byte to store them ... but then we don't have any more bytes until we hit 64k ;)