--- Log opened Tue Jan 07 00:01:02 2020 02:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 04:39 -!- jonatack [~jon@213.152.161.170] has joined ##ctv-bip-review 06:37 -!- jonatack [~jon@213.152.161.170] has quit [Read error: Connection reset by peer] 06:41 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##ctv-bip-review 07:17 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds] 10:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review 11:03 < bsm1175321> jeremyrubin: do you have a location? Need to plan hotels etc. 13:23 <@jeremyrubin> yes; I think I mentioned it's SF downtown. Will email you the specific location; not posting it publicly for security conciousness 14:12 < bsm1175321> Quick thought: using OP_CTV vs deleted keys for a vault presents an attack vector where the vault's extended public key is replaced with that of an attacker. 14:13 < bsm1175321> It's an attack we've considered, and our draft has some discussion of cross-device verification of this key. (e.g. in setting up a vault, all signing devices are initialized with the public keys of all other signing devices and the vault public keys -- needed to derive the OP_CTV scripts) 14:14 < bsm1175321> It makes setup more complex and signing devices more complex, but this really is independent of the vault mechanism and needs to be done regardless. 14:33 <@jeremyrubin> Hm yeah 14:34 <@jeremyrubin> I guess it's also problematic that the deleted keys could be generated from an HD seed 14:34 <@jeremyrubin> That *someone* might know --- Log closed Wed Jan 08 00:00:01 2020