--- Day changed Fri Nov 02 2018
01:49 < BlueMatt> ariard: sorry, I'll get to #230 tomorrow, at first glance it looked good so I want to be awake to pay close attention on that one :p
02:00 < ariard> BlueMatt: don't worry you can wait to review it, I'm still writing new cases/tests on it
02:40 < ariard> andytoshi: would love to review script_descriptor when it's cleaned, because right now in ln we have our own descriptors given back by the ChannelMonitor to the user wallet to notify that an onchain output is spendable
02:41 < ariard> and this outputs are now more part of a payment channel so not our task to manage them
02:42 < ariard> even if I think for now script_descriptor isn't enough expressive for some of them maybe at some point it could be cool to use them to ease wallet job
02:43 < ariard> I mean we have outputs encumbered by script with  OP_IF and OP_CSV
10:15 < stevenroose> andytoshi: why does secp256k1::key::SecretKey::from_slice(&secp, &vec![0; secp256k1::consants::SECRET_KEY_SIZE]) return an error?
14:44 < andytoshi> ariard: so, FYI our current script descriptor design cannot express HTLCs (though i'd be happy to special-case them since they're a pretty common thing and have a fixed format)
14:45 < andytoshi> descriptors are mainly for describing "cold coins", i.e. things that might plausibly be transferred between wallets .. not things that are used in the middle of interactive protocols
14:45 < andytoshi> stevenroose: because that's an invalid secret key and will cause upstream to abort in several places
14:45 < andytoshi> i believe it's forbidden by the ecdsa standard in fact
14:46 < andytoshi> stevenroose: if you need this for now you can use the `secp256k1::key::ZERO` constant ... i presume you need this to use with add_assign or mul_assign?
14:46 < stevenroose> Actually I might have read that before, yes. I made it 0x01......00 instead.  Just needed a nit value.
14:47 < andytoshi> the next breaking version of rust-secp will get rid of the ZERO constant because it violates our "impossible to trigger assertation failures without using the ffi module" guarantee, but we'll also change add_assign and mul_assign to take tweaks that aren't necessarily secret keys
14:47 < stevenroose> No, to use as a key in the PSBT thing. Trezor just wants the HD path, doesn't care about the pubkey (for non-multisig), but psbt is a HashMap<PublicKey, HDPath>
14:47 < andytoshi> ah, yeah, we should also add TEST_DUMMY constants
14:47 < stevenroose> Let me check key::ZERO
14:48 < andytoshi> i can't wait til we have constexprs in rust (though they won't support ffi for a long time, maybe never..) and i can define constant test vectors sanely..
14:48 < andytoshi> it might be key::ZERO_KEY .. one is deprecated because i forgot to use the `const` keyword so it doesn't actually work in most cases that you need it
14:49 < stevenroose> Ok key::ZERO_KEY is exactly the key I wanted to make :D Would that error when I try to call .public_key()? I guess so. I might use ONE_KEY though.
14:49 < andytoshi> ariard: was hoping to clean up script descriptors this weekend but i probably won't be able to .. have some unexpected blockstream work, plus i'm behind on libsecp stuff, plus i try not to work too much on weekends for sanity's sake :)
14:50 < andytoshi> stevenroose: yeah, if you can use ONE_KEY definitely use that instead
14:50 < andytoshi> i think if you give ZERO_KEY to .public_key() it'll trigger a libsecp assertation and abort your program. not even a rust panic, just abort.
14:50 < andytoshi> oh, i think i'm wrong, it is a rust panic
14:51 < andytoshi> upstream will simply return `0` but we have an invariant on the `SecretKey` type that you can't have an invalid secret key
14:52 < stevenroose> That's fair. Since it doesn't matter, I can just take ONE_KEY. Ideally I'd be able to fill in the actual pubkey. But that'd require reserves users to know the pubkey for all their HD paths, which requires them to have the xpub. Not sure if that's a good requirement.
14:56 < andytoshi> you should be able to ask the trezor for the pubkey, that's a quick roundtrip
14:57 < andytoshi> well, when they generate the address, i would expect the host side of the wallet to record the address, pubkey, path, etc.
14:57 < andytoshi> so i guess that is "requiring the user to have the xpub". i think that's reasonable.
15:02 < stevenroose> Yeah the point is that the process is in 2 steps: (1) provide all UTXO info and (2) sign.  And step (1) should be doable without touching any wallets/... But it already stores the data in a psbt::Input struct (makes the most sense).  So yes right before signing in (2) I could ask the Trezor for the key and then put it in place, but that would still require me to store the path in a more shady way during
15:02 < stevenroose> step (1).
15:02 < stevenroose> But yeah that's fair enough.  Only annoying thing is that it's not explicitly clear that that pubkey in the map is a nil pubkey, unless it's compared with the PublicKey::from_secret_key(ONE_KEY) which is not trivial.
15:03 < andytoshi> how do you know that the address is yours, but don't know anything about its provenance?
15:04 < andytoshi> PSBT assumes that all signers recognize their own outputs and know all the extra data about it, because if they've got some hot storage that knows which addresses are owned, presumably that hot storage can also store hd paths etc
15:04 < stevenroose> That all depends on what info your watcher wallets are keeping.  I guess most of those would have the xpub anyway, so I could have a --xpub or --pubkey to provide them.
15:04 < andytoshi> i would expect the wallet watcher to have the entire output descriptor (or equivalent)
15:04 < andytoshi> which includes all the data that psbt wants
15:04 < stevenroose> Hmm, yeah you make me think I shouldn't put the random key there.
15:05 < andytoshi> yeah, it sounds like you shouldn't use dummy data here :P
15:05 < stevenroose> For Trezor it doesn't matter, but it goes against the PSBT standard and can cause problems further down the road.
15:05 < andytoshi> yes, if i were writing a combiner and somebody provided inconsistent data like that i'd probably nak them and drop them from the signing process
15:06 < andytoshi> (though maybe the psbt spec says i'm not allowed to do that? i'd have to look it up again..)
15:37 < stevenroose> dongcarl, andytoshi: the "master key fingerprint" that PSBT needs, is that the "xpub..".parse().fingerprint() or the "xpub...".parse().parent_fingerprint?
15:37 < stevenroose> s/.parse()/.parse().unwrap()/g :)
15:38 < andytoshi> .fingerprint()
15:38 < andytoshi> idk why parent_fingerprint exists tbh
15:39 < andytoshi> oh it appears inthe base58 encoding
15:40 < andytoshi> heh, ok, that isn't really justified in the BIP either .. "is a fast way for software to recognize parent/child relationships" ... anyway you want .fingerprint()
16:10 < stevenroose> k, thanks
16:10 < stevenroose> andytoshi: what's the default way to have a global secp? It seems to be annoyingly hard to have a static variable like that :D
16:11 < andytoshi> you can use lazy_static
16:11 < andytoshi> but i usually just pass secp contexts into all of my functions
16:11 < stevenroose> Btw, sorry if I'm too spammy in this channel :/
16:11 < andytoshi> because that has the side-effect of documenting whether they do signing or verification
16:12 < andytoshi> heh, no, it's a high-volume channel (or will be at some point) ... we maintain like 10 different projects here
16:37 < stevenroose> Heh yeah ofc.. I can't get the pubkey from an xpub and a path m/0'/0'/0 with hardened children.. Now that's not nice :/
18:05 < andytoshi> yes, any hardened derivations should be invisible to this
18:05 < andytoshi> just use the xpub from the longest public path
20:11 < dongcarl> Seems like the Debian people are doing some bootstrap work: https://lists.debian.org/debian-devel-announce/2018/11/msg00000.html
20:12 < dongcarl> Not sure if they’re using mrustc or not... guess I’ll check on my build of mrustc