--- Log opened Tue Apr 26 00:00:07 2022
02:50 < salvatoshi> Hello! I'm thinking about the security of showing the user miniscript vs its policy when registering a "miniscript wallet" on the device. Showing the policy ("lifted" miniscript) seems a better UX as it's much easier to read - but since many semantically equivalent miniscripts can lift to the same policy, I'm worried this could lead to ransom attacks (malware sends the hardware wallet a different miniscript than the user's 
02:50 < salvatoshi> backup during wallet registration, and it looks indistiguishable to the user on the device screen). That would violate the security model of hardware wallets (that is: the user can't be tricked into loss of funds as long as they verify correctly what's on screen). Any ideas on this?
03:15 -!- afilini [~afilini@2001:bc8:1828:245::2] has joined ##miniscript
03:15 < afilini> I guess you could show the descriptor checksum to let the user double check it matches with descriptor they've backed up
03:16 < afilini> But I don't think the current checksum function is hardened against those attack scenarios..
03:26 < darosior> salvatoshi: i believe there is no way around checking the descriptor on the signing device screen with your backup. Lifting is interesting when the user needs to decide whether to sign a transaction, and the HW is presented the Miniscripts that corresponds to the outputs' witness programs. So it can say "you send X of your coins to this contract,
03:26 < darosior> and Y to yourself (change). Want to do that? Y/N".
03:27 < darosior> "no way around" => Of course apart from sending a small amount of coins to the descriptor and testing to recover from backup on a trusted device :p 
04:46 < salvatoshi> when signing a registered wallet, it would just show you the name of the registered wallet, so that's good enough (on miniscript-on-taproot, I suppose I will instead have to show the policy of the leaf being used)
04:47 < salvatoshi> I guess I'll stick to showing miniscript for now, then ­- which is anyway the easier solution to implement
04:47 < salvatoshi> (a hardened checksum would have to be quite long, so not sure I like it more!)
04:54 < darosior> Good luck with showing the internal pubkey + the Miniscript for all the leaves for a Taproot 🙈
04:55 < darosior> Actually i guess it would not be more intimidating than a segwit v0, just the additional internal key
05:00 < salvatoshi> yeah, I'm not too worried about that - the cool thing about the registration is that you do it only once
05:02 < salvatoshi> ultimately, I think a really good UX will require whitelisting certain commonly used script patterns so that you can skip showing the descriptor altogether (especially for more convoluted contructions on taproot)
08:35 < andytoshi> salvatoshi: i would imagine that the hww should be able to sign any miniscript that has the same lifted policy?
08:35 < andytoshi> so the ransom would'nt be effective
08:36 < andytoshi> but i agree with the intuition that we should show a checksum .......better, we should show the user the final address!
08:38 < salvatoshi> unfortunately you will register a "wallet policy" with miniscript, not with policy (maybe I need to figure out better namings :P); a different miniscript is a different wallet policy and the hww will not sign it
08:41 < salvatoshi> indeed, showing the first receive address at wallet policy registration time could great in terms of UX (but it does not fully solve the problem above, we still have to expect the user to check that the miniscript matches the backup). If you have malware and you don't control the address, you are still in trouble
08:46 < afilini> Same with the checksum actually, i could show the user a descriptor with a wrong checksum
08:47 < afilini> Unless the user tires to import that descriptor in another software like Bitcoin core, they may never realize that their paper backup is invalid
08:49 < salvatoshi> yup, not a trivial problem, and it depends how the "wallet backup" was produced. BSMS (BIP-0129, https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki) is a scenario where checking the first address should be enough.
08:50 < salvatoshi> in general, it might be out of scope for the HW, so checking the first address might be as good as it gets indeed
09:02 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 272 seconds]
09:11 < andytoshi> i suppose someone could release an airgapped "descriptor checker" which just parses descriptors/miniscript in QR codes or as text or whatever
09:11 < andytoshi> and shows data to the user
09:11 < andytoshi> ...i don't think there is a software solution to this, i think you need some sort of product like that
09:20 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
09:35 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 250 seconds]
10:03 -!- roconnor_ [~roconnor@coq/roconnor] has joined ##miniscript
10:03 -!- roconnor [~roconnor@coq/roconnor] has quit [Ping timeout: 250 seconds]
10:04 -!- roconnor_ is now known as roconnor
10:05 < darosior> sanket1729_, andytoshi: have you seen https://github.com/rust-bitcoin/rust-miniscript/issues/368?
10:10 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
10:35 < andytoshi> darosior: i saw it but i didn't understand what you meant by "break the type system"
10:36 < darosior> andytoshi: i meant that "d" means that you don't need a preimage to dissatisfy. pk_h(H) is therefore not "d", but we consider that it is.
10:36 < andytoshi> weird....we introduced "d" specifically because of pk_h
10:50 <@sipa> darosior: I don't think that's right. Just because you don't know the public key preimage doesn't mean the potential signers don't.
12:21 < sanket1729_> darosior: Why is this wrong with Pk = DescriptorPublicKey? Pk::Hash would be Key, and the potential signers would know the pre-image.
13:31 -!- proofofkeags_ [~proofofke@2607:fb90:6ed5:eef1:ff56:1f01:9fb0:2145] has joined ##miniscript
13:34 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds]
13:45 -!- proofofkeags__ [~proofofke@2607:fb90:6eca:95a4:f15b:c890:6d31:baa4] has joined ##miniscript
13:47 -!- proofofkeags_ [~proofofke@2607:fb90:6ed5:eef1:ff56:1f01:9fb0:2145] has quit [Ping timeout: 260 seconds]
13:53 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
13:53 -!- proofofkeags__ [~proofofke@2607:fb90:6eca:95a4:f15b:c890:6d31:baa4] has quit [Ping timeout: 250 seconds]
16:36 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
17:42 -!- paairs [~rabidus@user/paairs] has quit [Remote host closed the connection]
23:54 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
23:57 < darosior> andytoshi: yeah but it's a rust-bitcoin matter, not a Miniscript matter
23:59 < darosior> sipa: other participants are assuming they can always dissatisfy it (that's the purpose of 'd'?). For instance consider `or_d(pkh(Alice's key hash),pk(Bob's key))`. Here for Bob rust-bitcoin would tell him "all good, you can always spend with your keys and don't nee no other secret", and that is incorrect as it needs the keyhash preimage that is
23:59 < darosior> not part of the descriptor
--- Log closed Wed Apr 27 00:00:07 2022