--- Log opened Thu Jan 20 00:00:35 2022
03:32 -!- meshcollider [meshcollid@user/meshcollider] has quit [Ping timeout: 256 seconds]
08:31 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 250 seconds]
08:50 <@sipa> For discussion: https://github.com/bitcoin/bitcoin/issues/24114
08:52 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-248.w86-252.abo.wanadoo.fr] has joined ##miniscript
09:09 < darosior> sipa: do you think this should block the Miniscript PR? It's getting very close..
09:10 <@sipa> I don't think so, no. It just proposes adding more thins.
09:20 <@sipa> @andytoshi @sanket1729 l: I think this may imply a somewhat invasive change for rust-miniscript. If I understand/recollect it correctly, I think it would mean you'd have a pkh_h fragment with a key argument (rather than keyhash), but a separate rawpkh_h fragment with a keyhash argument.
09:24 <@sipa> There may be other ways of implementing e.g., just leaving a singular pkh_h fragment, but render/parse it as rawpkh_h if its argument is a hash, and as pk if not.
09:24 <@sipa> Happy to hear opinions.
09:39 <@sipa> I guess I could also be convinced to instead just permit both hex arguments and key arguments to pkh_h, which I suppose needs fewer changes... but I'm a bit concerned about how similar the 40 hex character or 66 hex character argument to pkh would look.
09:42 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-248.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 240 seconds]
09:43 < andytoshi> we could prefix hashes with # or something
09:44 < andytoshi> i'll chew on this. it might be invasive but i'm unsure.
09:45 <@sipa> `#` would be hard, as that's the checksum character, but another prefix symbol may be a possibility too.
09:45 < andytoshi> in rust-miniscript it's already a common mode of operation to have a keytype whose "hash" is the identity, which has the effect of never losing information (we require a method to map a generic hash to a literal hash160 for script encoding)
09:45 < andytoshi> so maybe we just need to change the argument to PkH from Key to Key::Hash
09:45 < andytoshi> and users for whom this would've otherwise caused problems, can just use a identity-hash keytype
09:45 < andytoshi> but again, i'm not sure
09:45 < andytoshi> there are a lot of interacting parts :)
09:45 <@sipa> Sure.
09:46 < andytoshi> I guess -- if we have a large script with a pk_h(key) somewhere, and a pk_h(hash) elsewhere...that will cause us problems
09:46 < andytoshi> and this is probably the common case
09:49 <@sipa> But you must have a way already to represent this, right? E.g. an or_i with two pkh branches. You can sign for that if you only have one of the privkeys, and not even have the pubkey for the other.
09:52 < andytoshi> ah, yeah, the type inside PkH is already a Pk::Hash..
09:53 < andytoshi> sipa: but we don't directly support mixed descriptors like this
09:53 < andytoshi> internally, such a scenario would be represented by a descriptor that had only hashes, and a separate hashmap of hash->pk used by the satisfier
09:53 < andytoshi> we could support de/serializing the pair of these, similar to how we handle descriptors with private keys in them
09:53 <@sipa> Sure, that'd be invalid right now. But I'm suggesting adding a way to descriptors to make that partial information explicit.
09:54 < andytoshi> hmm, i think this might simplify things for us
09:54 < andytoshi> it would be invasive, es
09:54 <@sipa> Because partial information is already a reality actually, and with tr it's going to only get worse (see the issue I linked).
09:54 < andytoshi> yes
09:54 < andytoshi> right
09:54 < andytoshi> yep, i read the list of examples
09:54 < andytoshi> i think you are right, conceptually
09:55 <@sipa> I also realize this may be invasive, and probably more so for you than for me.
09:55 < andytoshi> so suppose the type of PkH, internally, was a tuple (Pk::Hash, Option<Pk>) ... this would explicitly represent maybe-missing information
09:55 < andytoshi> and our satisfier could use that rather than needing a separate hashmap
09:56 < andytoshi> sipa: that's ok, i think it brings us to a cleaner design ... and also we have more developers than you :)
09:57 <@sipa> Of course, if you had a descriptor with a PkH-with-known-hash, and you happen to have the private key for that pubkey hash, you'd want a way to combine that information into a descriptor that had a pubkey instead there.
09:57 <@sipa> And can sign for it.
10:00 < andytoshi> for sure - but i think we can do that in our privkey desciptor parser without any invasive changes
10:11 <@sipa> But I think it indeed makes things cleaner. Before you had a rely on type parameter substitutions to construct a miniscript object that could represent such information (which already was needed in some cases, like signing, but forbidden in others, like the descriptor string representation).
10:12 <@sipa> By making it explicit in the language more things can use the same instantiation, I think.
10:18 <@sipa> Another possibility is something like `pk_h(hash(HEX))` or so. There is something to be said for not duplicating the fragment just to represent a difference in knowledge about its key.
11:47 < andytoshi> i wouldn't mind that. though tbh i am not super concerned about keys and hashes being distinct
11:49 <@sipa> So you mean you prefer having separate `pk_h()` and `rawpk_h()`, or something else?
11:49 < andytoshi> i prefer having a single pk_h where you can put a 40- or 66-byte hex string into
11:49 < andytoshi> but it's not a very strong preferenc
11:50 <@sipa> Ah, that's my least preferred option, because it looks very similar but has very different semantics.
11:50 <@sipa> But I could be convinced.
12:41 < andytoshi> i think the semantic change is just "how much data do you need at signing time"
12:42 <@sipa> Not even that. Just whether or not the data needed for signing can always be encoded as a descriptor or not.
13:08 < andytoshi> ah, yeah
17:48 < sanket1729> andytoshi: I believe, we should add a another variant RawPkH(Pk::Hash) and convert the existing PkH(Pk::Hash) to PkH(Pk). That aligns more with the proposal and is simpler to implement.
18:13 < andytoshi> sanket1729: kk, you're closer to this stuff than me
18:13 < sanket1729> andytoshi: any chance you can help with this https://github.com/rust-bitcoin/rust-secp256k1/issues/378? 
18:14 < andytoshi> sanket1729: yep, it's on my list
18:14 < andytoshi> i spent a bit of time on it ths morning
18:14 < andytoshi> our removing-malloc patches don't apply :/ i think it's something simple but it'll take some work to remember how to regenerate those patches
18:14 < andytoshi> will try to do it tomorrom morning
18:14 < sanket1729> Thanks a lot :) 
18:15 < sanket1729> to be clear, none of the API changes removing the secp context are required, only the update to latest libsecp would be sufficient(for now)
18:15 < andytoshi> great, thanks, i was gonna ask
18:16 < sanket1729> If I understood tim correctly, Secp256k1::new_verification() should only do a few memcpys and not creat new contexts
18:28 < andytoshi> yes, that's how i understood him
18:28 < andytoshi> and like, not even big memcpys
18:49 <@sipa> Context objects are tiny now.
23:00 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-248.w86-252.abo.wanadoo.fr] has joined ##miniscript
23:43 -!- salvatoshi [~salvatosh@lfbn-idf3-1-717-248.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 240 seconds]
--- Log closed Fri Jan 21 00:00:36 2022