--- Log opened Tue Nov 02 00:00:21 2021
08:06 -!- meshcollider [meshcollid@user/meshcollider] has quit [Quit: :wave:]
08:27 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript
11:00 -!- gene [~gene@gateway/tor-sasl/gene] has joined ##miniscript
12:23 < jeremyrubin> _aj_ disxussed previously in https://github.com/bitcoin/bitcoin/pull/21365#issuecomment-793027851
20:23 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
20:31 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Changing host]
20:31 -!- meshcollider [meshcollid@user/meshcollider] has joined ##miniscript
20:44 < ademan[m]> is it possible to describe a pubkey hash in a policy? I've tried `ripemd160(pk(A))`, `pk_h(A)`, and `pkh(A)` I assume ripemd160 expects a literal, and I assume pk_h and pkh are miniscript, not policy... It seems like a size win to use pkh, an OP_HASH160 and some surrounding opcodes for a 12 byte saving per key, is there a reason why I shouldn't? (collision potential?)
20:46 <@sipa> no, you can't because in policy land there is no such thing
20:47 <@sipa> policies are "who has to sign"
20:47 <@sipa> whether that's done using a pubkey or a pubkeyhash is an implementation detail of how you map that policy to script
20:53 <@sipa> size isn't a concern in policies
20:53 <@sipa> the compiler is responsible for mapping it to something efficient
20:53 < ademan[m]> hrm 
20:55 <@sipa> and both implementations will in fact map pubkeys in policy to pubkeyhashes in circumstances where it on average saves space
20:57 <@sipa> don't forget that if you're trying to spend using a pkh, you still have to supply the full pubkey as witness, which also costs space
20:57 <@sipa> so the analysis is perhaps slightly less trivial than you imagine
21:09 < ademan[m]> does your miniscript compiler have a -OS? 😂 But in all seriousness, I guess I'm finding that policies are higher level than I thought they were, and I've already found miniscript to be lower level than I thought they were. I can write a miniscript that shoots me in the foot/behaves totally differently from what I'd expect: `or_b(pk(A),s:pk(B))` and `or_b(pk(A),pk(B))` both compile but the second one is nonsense. I'm not at all
21:09 < ademan[m]> confident I can hand-write miniscript tbh
21:09 <@sipa> the compiler always optimizes for size
21:10 <@sipa> the second isn't just nonsense; it's invalid
21:10 <@sipa> it doesn't typecheck
21:10 <@sipa> i'm pretty sure that given a _valid_ miniscript, you can fairly easily read what it does
21:11 <@sipa> writing it by hand is not something i expect many people to be able to do, except for very simple cases perhaps
21:25 < ademan[m]> hrm, well I guess for my use case `and(pk(A), or(after(42), pk(B)))` I want A to be a pkh to make it easy for the user to provide me a pubkey via a p2wpkh, rather than strictly about space. (Granted, I may find wallets have no idea how to sign this in the `and(pk(A), or(..., pk(B)))` case, but I'll address that when I get there, I guess)
21:32 <@sipa> i'd advise against that... you risk indeed getting keys from clients who have no way of signing for that
21:33 <@sipa> but if you must, and_v(v:pkh(A),or_d(pk(B),after(42))) will work
21:37 < ademan[m]> thanks! That looks nearly identical to the version the compiler gave me, was it really as simple as swapping v:pkh() for v:pk() ?
21:37 <@sipa> yes
21:37 < ademan[m]> er, I think what I'm asking is more "is that a generally safe substitution"
21:38 <@sipa> well i analysed it
21:38 <@sipa> and it typechecks
21:38 < ademan[m]> ah, thanks
21:42 < ademan[m]> I think I can retain a safe protocol by not broadcasting this tx using this script until after I get a correctly signed spend using A and B together, though the clients likely to be a problem might do something stupid like broadcast the tx automatically. But that's all OT, I'll take it elsewhere. Thanks for your attention and help sipa
--- Log closed Wed Nov 03 00:00:22 2021