--- Log opened Wed Apr 27 00:00:07 2022
00:00 < darosior> sanket1729_: i'm talking about the descriptor not the implementation. See above ^
02:13 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 260 seconds]
02:15 -!- midnight [~midnight@user/midnight] has joined ##miniscript
04:54 <@sipa> @darosior I don't think that's really all that different from a descriptor with public keys, to someone who doesn't have the private keys.
04:55 <@sipa> They also might not be able to spend it, but others who do have the private key may.
04:55 < darosior> sipa: Yes it is, since the dissatisfaction of pkh requires that you show the preimage of the key. So in my above example, Bob is effectively stuck but rust-miniscript tells him he's not
04:56 < darosior> s/preimage of the key/preimage of the keyhash/
04:56 <@sipa> Yes, and someone who does have the pubkey can dissatisfy it.
04:57 <@sipa> Partial information does not change the type of the descriptor, just what you can do with it.
04:58 <@sipa> This should probably be treated differently in some way from descriptors that do have the full public key. E.g. in Bitcoin Core it'd be an "unsolvable" one.
04:59 <@sipa> But I don't think this should have any impact on the type system.
04:59 < darosior> Ok, maybe my wording of "pkh(Key) is 'd' but pkh(H) is not 'd'" is clumsy or plain wrong. My point was rather that rust-miniscript would tell to the user it's fine while it's not, they are missing information to dissatisfy and spend using their own path
05:00 < darosior> "E.g. in Bitcoin Core it'd be an "unsolvable" one." -> I don't think Bitcoin Core accepts pkh() with a keyhash argument at all.
05:01 <@sipa> It doesn't
05:01 < darosior> Oh ok i understand your sentence
05:02 <@sipa> But if you'd instantiate a Miniscript object with a custom Key type that can be parsed from a pubkey hash, it'd behave the same way.
05:02 < darosior> Yes
05:02 <@sipa> Because that isn't Miniscript's business, but the user's providing the Key type.
05:03 <@sipa> Things will be simpler if we bring partial information explicitly into the language, instead of hiding it behind the Key types.
05:09 < darosior> Ok, yeah, my explanation of the issue using Miniscript's type system was definitely not right. Sorry for the confusion. So andytoshi/sanket1729_ what i'm saying in the issue is we should convey that a user may not be able to use a descriptor with a pk_h(H) at all, even if it's in another branch. We should not expect them to know that a pk_h(H)
05:09 < darosior> necessarily ends up with an `EQUALVERIFY` on the presentation of the keyhash preimage, information that is not part of the descriptor...
05:49 < andytoshi> i didn't realize we supported pk_h(H)
05:55 <@sipa> I assume it's only in certain instantiations?
05:57 < andytoshi> like, if you set the key type to something opaque?
05:58 < andytoshi> in that case i don't understand how the library could do anything about it
06:31 < andytoshi> ah i see, we always use the "hash" type and expect the user to use some hash==pk type for "normal descriptors"
06:32 < andytoshi> otoh, the only key type we provide, DescriptorPublicKey, does have this hash==pk property ... so bob would have to "analyze the descriptor" using some nonstandard key type
06:34 < andytoshi> and in fact if he did use DescriptorPublicKey, the descriptor wouldn't even parse..
06:35 < andytoshi> but yeah, ok, i see your point. we have designed the system so you can put hashes here, though you have to do a little bit of extra work ... but then once we do, the "d" type modifier no longer does what you expect
08:31 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
09:15 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 246 seconds]
11:13 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
11:29 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Remote host closed the connection]
11:29 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
11:57 < sanket1729_> The only key that the user should ever use if `DescriptorPublicKey`. If the user is using other key types, the guarantees of "d" property for pkh won't hold. 
11:58 <@sipa> I disagree with that. "d" is a property of the script, not of what the user knows about the script.
11:59 <@sipa> You may say that the guarantees of the signing algorithm won't hold in such a case, but that's independent from miniscript's type system.
12:00 < sanket1729_> When you parse a script as miniscript with pkh(<hash>), and you don't know the pre-image, you will fail right?
12:01 <@sipa> Yes, but pkh(<hash>) and pkh(<pubkey>) are the same script. Their type properties are identical. The only thing that differs between them is how much you know about the script.
12:02 <@sipa> That's no different from pkh(<pubkey>) and pkh(<privkey>) also being the same script. With one you can sign, with the other you can't. The type properties are still the same.
12:02 < sanket1729_> I see what you are trying to say. 
12:02 < sanket1729_> Should the description of "d" property need a modification then?
12:02 <@sipa> Why would it?
12:03 < sanket1729_> It basically says unconditional dissatisfaction, but now have a condition to dissatisfy it
12:03 <@sipa> Well, yes, you need to know the script.
12:04 <@sipa> I think my view is that (for now, until rawpkh or something similar), pkh(<hash>) simply isn't a descriptor.
12:04 < sanket1729_> Agreed, we are on the same page. 
12:04 <@sipa> It's some partial information about one, and with partial information you obviously can't garantee anything.
12:05 <@sipa> Once we introduce rawpkh()... maybe we indeed need to change the type property explanation, to add an explicit "to parties that know the equivalent non-partial miniscript" or so.
12:06 < sanket1729_> > In rust-miniscript land, this means "The only Pk: MiniscriptKey that the user should ever use is `DescriptorPublicKey`"
12:11 < jeremyrubin> im a bit confused as to what's going on with this
12:12 < jeremyrubin> how is this different from pk(<pubkey>) and it being a NUMS point?
12:13 <@sipa> It's no different from pk(<pubkey>) and nobody knowing the private key to that pubkey (whether that is provably the case or not).
12:13 <@sipa> The point of discussion is that the "d" property definition states "unconditionally dissatisfiable", but that's obviously not the case for a pkh script where you only know the pubkey hash - you need the full pubkey to dissatisfy it.
12:14 < andytoshi> jeremyrubin: the difference is that to dissatisfy a pk_h you have to provide the preimage
12:14 <@sipa> And my point is that all properties really implicitly have an "to a party with access to sufficient (non-secret) information"
12:14 < andytoshi> with a NUMS point you can still dissatisfy (You just need an empty sig)
12:14 < andytoshi> i tend to agree with sipa that pk(hash) is just "not a descriptor"
12:15 < andytoshi> but OTOH i want to support this use-case in rust-miniscript so i think we need to figure out some reasonable way to document/describe that
12:15 < andytoshi> and maybe "d refers to a party with sufficient non-secret information" is the way to go, with the explanation that normally it's everybody, but if you use weird keytypes it [becomes more nuanced
12:16 <@sipa> But even if we add a rawpkh(hash), which would make it a descriptor, i think it'd need to be "d". Otherwise you introduce a bizarre distinction between "a pkh script where *I* don't know the full pubkey" and "a pkh script where *nobody* knows the full pubkey". The latter is just uninteresting.
12:16 <@sipa> If you see a pkh script, you should assume that somebody has the public key - and the type properties let you reason about what that someone can do.
12:18 <@sipa> In Bitcoin Core's descriptor that notion is captured by the "solvable" property - in some cases a descriptor simply doesn't contain enough information for particular use cases (e.g. estimating spending cost).
12:18 <@sipa> But you still can assume that someone does have that information.
12:19 < sanket1729_> sipa: In or_d(pkh(A-hash),pk(B)), as party B you cannot assume pkh(A-hash) as d
12:20 < sanket1729_> rawpkh I mean
12:20 <@sipa> I disagree.
12:20 < sanket1729_> B analysis would tell that B alone can spend the script, but it needs something else
12:20 <@sipa> rawpkh() means "I don't have the full picture".
12:20 < jeremyrubin> ah weird
12:21 <@sipa> You can reason about the spendability conditions only for someone who does have the full picture.
12:21 < jeremyrubin> what is the compiled fragment of this thing?
12:21 < sanket1729_> If you see anything raw, don't reason about anything
12:21 < jeremyrubin> not clearly seeing about the undissatisfiable part
12:21 <@sipa> rawpkh is compiled exactly the same as pkh
12:21 <@sipa> it just means you only know the hash inside, rather than the full pubkey
12:21 <@sipa> (assuming we go through with it, to be clear)
12:48 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
12:48 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript
12:55 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 250 seconds]
13:30 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
14:57 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 272 seconds]
16:47 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 240 seconds]
16:50 -!- sipa [~sipa@user/sipa] has joined ##miniscript
16:50 -!- mode/##miniscript [+o sipa] by ChanServ
16:55 -!- proofofkeags_ [~proofofke@2607:fb90:6ece:3054:d869:aa05:a6b4:c986] has joined ##miniscript
16:56 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]
16:57 -!- proofofkeags__ [~proofofke@2607:fb90:6ed7:f90a:ec4a:60ac:838d:5ba1] has joined ##miniscript
17:00 -!- proofofkeags_ [~proofofke@2607:fb90:6ece:3054:d869:aa05:a6b4:c986] has quit [Ping timeout: 250 seconds]
17:02 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
17:04 -!- proofofkeags__ [~proofofke@2607:fb90:6ed7:f90a:ec4a:60ac:838d:5ba1] has quit [Ping timeout: 250 seconds]
17:39 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds]
23:55 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
--- Log closed Thu Apr 28 00:00:08 2022