--- Log opened Fri Jan 08 00:00:09 2021
00:17 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 246 seconds]
00:18 -!- jonatack [~jon@104.254.90.195] has joined ##miniscript
03:48 -!- jonatack [~jon@104.254.90.195] has quit [Quit: jonatack]
03:52 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript
03:56 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds]
03:57 -!- jonatack [~jon@184.75.221.43] has joined ##miniscript
09:05 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined ##miniscript
11:11 < andytoshi> sanket1729: can i make the internal key for Pkh and Wpkh public?
11:11 < andytoshi> oh i see, you have a method .as_inner for it
11:11 < andytoshi> mmmm ok i'll just use that
11:57 -!- jonatack [~jon@184.75.221.43] has quit [Quit: jonatack]
12:09 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript
12:14 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds]
12:16 -!- jonatack [~jon@213.152.162.89] has joined ##miniscript
12:32 < sanket1729> We can also add into_inner if you need that
12:32 < andytoshi> nah, i don't
12:33 < andytoshi> sanket1729:  why does Satisfier require ToPublicKey on its Pk?
12:33 < andytoshi> lemme fix this
12:33 < andytoshi> there is no reason that it should
12:33 < sanket1729> I think it needed that, don't remember why
12:33 < andytoshi> yeah, i think a long time ago the methods returned abstract public keys
12:33 < andytoshi> but now they always return bitcoin::PublicKey
12:34 < andytoshi> and an implementor can do whatever they want to obtain those keys..
12:35 < sanket1729> I think the Satisfier does need ToPublicKey. How else can you create a witness? 
12:36 < sanket1729> say for pkh
12:36 < andytoshi> call lookup_pkh_sig
12:37 < sanket1729> Yeah, right. How can we get witness_script for wsh?
12:37 < andytoshi> ahh that may be a problem
12:40 < andytoshi> oh, lol, i see what's going on ... in the latest release we take an abstract Pk but return bitcoin::PublicKey from a bunch of methods
12:40 < andytoshi> in the unreleased version we're smarter, we return abstract Pk
12:41 < andytoshi> so then the satisfier does need ToPublicKey to get pubkeys
12:41 < andytoshi> and, as you say, it also needs it to compute witness/redeem scripts
12:44 < andytoshi> oh, i'm still wrong, nothing changed, it's just that lookup_pkh_sig returns a bitcoin::PublicKey for some reason
12:44 < andytoshi> which led me on a wild goose chase of "maybe the Satisfier trait has enough info that I don't actually need ToPublicKey"
12:45 < sanket1729> It returns that in order to dissatisfy it
12:45 < andytoshi> right, i remember now
12:45 < sanket1729> There is comment above it :P
12:46 < andytoshi> there isn't one on docs.rs
12:47 < andytoshi> in any case ... it is frustrating that i can't impl Satisfier on some object which has enough context to convert abstract Pks to bitcoin::PublicKeys
12:47 < andytoshi> without making another key type which can do the conversion itself
12:53 < sanket1729> So, this was introduced in sortedmulti
12:53 < sanket1729> because satisfying that actually requires conversion to Publickey
12:54 < sanket1729> We can't satisfy that on abstract keys unless we actually convert to bitcoin::Publickey
12:55 < andytoshi> innteresting
12:55 < andytoshi> so, we can work around this by adding a method to Satisfier that does the conversion
12:57 < sanket1729> Yeah, I think that works. I can make a PR for it. 
12:58 < andytoshi> i'm unsure yet
13:00 < andytoshi> so, on the one hand i'd really like this, it would solve a problem i'm having
13:00 < andytoshi> but on the other hand it forces every general implementation of Satisfier to have a ToPublicKey bound and to add `fn bitcoin_pk(pk) -> bitcoin::PublicKey { pk.to_public_key() )` method
13:01 < andytoshi> and like, it only partially solves the problem anyway, for people who are missing context in their keys. they still need awkward tricks to compute addresses etc
13:09 < sanket1729> How is address creation related to satisfaction?
13:10 < sanket1729> andytoshi: I removed ToPublicKey on satisfier and things are working just fine :O
13:10 < andytoshi> sanket1729: yes, but you can't call .satisfy on descriptor 
13:10 < andytoshi> because that still has a ToPublicKey bound :)
13:11 < sanket1729> We can maybe remove it from the get_satisfaction API. 
13:11 < sanket1729> maybe not. 
13:11 < sanket1729> It still needs the witness_script
13:11 < andytoshi> yeah
13:13 < andytoshi> ok, can we remove FromStr and Display from MiniscriptKey?
13:14 < andytoshi> these are very annoying to implement if you have a keytype that has some extra aux context in it, that never needs to be serialized out
13:14 < sanket1729> +1
13:14 < sanket1729> yes, please
13:14 < andytoshi> hehe, ok, lemme give that a shot
13:14 < andytoshi> i think we might as well keep all the rest, Eq, Debug, Hash, etc
13:14 < andytoshi> well actually std::Hash we might as well drop
13:33 < andytoshi> ah, no, std::Hash we want i think, we need it to check for duplicate keys which is pretty fundamental
13:36 < andytoshi> hmm, gross, fmt::Display is needed for miniscript::types::Error to impl std::Error
13:36 < andytoshi> so maybe i'll keep Display as well. But FromStr i really wanna drop
13:47 < andytoshi> ok, just running tests and then i'll PR
13:54 < andytoshi> sanket1729: https://github.com/rust-bitcoin/rust-miniscript/pull/220
13:58 < afilini> I've just noticed that `MiniscriptKey::is_uncompressed()` was not implemented on `DescriptorPublicKey`, so it was always returning false
13:58 < afilini> here's the pr: https://github.com/rust-bitcoin/rust-miniscript/pull/221
14:02 < andytoshi> lol. lgtm
14:02 < andytoshi> does bip32 ever allow uncompressed keys?
14:02 < sipa> yes
14:02 < sipa> ah
14:02 < sipa> no
14:03 < sipa> i guess it's up for interpretation; it uses compressed keys internally everywhere, but you could read it as just specifying EC points, not a specific encoding
14:03 < sipa> i think in most places it's interpreted as being always compressed
14:04 < andytoshi> the Ledger Nano S, bizarrely, will send keys in uncompressed encoding over the wire
14:04 < afilini> in rust-bitcoin I don't think there's a way to make it generate uncompressed keys, so I don't think we can check for it in any way
14:04 < andytoshi> but always derives addresses (e.g. for user dispaly ) with compressed ones
14:04 < andytoshi> ok, i think it's fine to say "in rust-bitcoin-land, bip32 means compressed keys". nobody has complained so far..
14:05 < sipa> may make sense to include this explicitly in the output descriptor spec
14:05 -!- notmandatory [~notmandat@shindig.notmandatory.org] has joined ##miniscript
14:05 < sipa> i don't think anyone can interpret it differently because expansion has to be unambiguous, and there is no way to specify compressed or uncompressed format
14:06 < afilini> yeah i guess it could be added to `ExtendedPubKey` and `ExtendedPrivKey`, but if nobody uses them it doesn't really matter 
14:06 < andytoshi> afilini: it can't, i'm pretty sure, because those types need to de/serialize according to bip32
14:06 < andytoshi> which doesn't have any space to fit an extra bit
14:07 < andytoshi> in the base58ck encoding
14:07 < sipa> xpubs always use compressed encoding
14:07 < sipa> serP(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser256(x), where the header byte depends on the parity of the omitted y coordinate.
14:07 < sipa> (from BIP32)
14:10 < sanket1729> andytoshi: merged. 
14:12 < andytoshi> thanks!
14:12 < andytoshi> afilini: just running tests on the rebased version of 221 then i'll merge that
14:12 < andytoshi> not that i really need to rebase and fuzz something this small :P but it's nice to have a process
14:16 < andytoshi> afilini: merged
14:41 < afilini> nice, thanks!
15:12 < andytoshi> lol, wtf, bitcoin will consensus-serialize tuples with 2 or 4 or 6 or 8 elements
15:12 < andytoshi> but no odd numbers
15:13 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
15:14 < sipa> andytoshi: ?
15:14 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript
15:15 < andytoshi> sipa: i have code, which dates back to the origin of rust-bitcoin, where if you try to serialize (A, B), it'll serialize the concatenation of A and B
15:15 < andytoshi> and (clearly deliberately) i explicitly implemented this for tuples of lengths 2 4 6 and 8
15:15 < andytoshi> and nothing ele
15:15 < sipa> haha
15:51 < andytoshi> sanket1729: (with a patched rust-bitcoin) i have managed to sign a transaction using the miniscript satisfier API :)
15:51 < andytoshi> i.e. i impled `lookup_sig` to actually request a signatrue from the dongle
16:16 -!- afilini [~user@gateway/tor-sasl/afilini] has quit [Remote host closed the connection]
16:16 -!- afilini [~user@gateway/tor-sasl/afilini] has joined ##miniscript
16:32 < sanketcell> andytoshi: awesome
16:37 < andytoshi> i also have only one more dep in icboc, despite adding anyhow and thiserror and a crate to find home directories
16:38 < andytoshi> (and like, doing 100 times as much)
17:07 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]
17:50 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined ##miniscript
19:19 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]
20:11 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined ##miniscript
21:16 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]
23:48 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined ##miniscript
--- Log closed Sat Jan 09 00:00:10 2021