--- Day changed Thu Nov 19 2020
01:27 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds]     
01:29 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript     
02:16 -!- jonatack [~jon@213.152.161.149] has quit [Read error: Connection reset by peer]     
02:19 -!- jonatack [~jon@213.152.161.249] has joined ##miniscript     
03:40 -!- jonatack [~jon@213.152.161.249] has quit [Quit: jonatack]     
04:10 -!- jonatack [~jon@109.202.107.147] has joined ##miniscript     
06:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
07:00 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript     
07:00 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
07:00 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript     
08:04 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
10:16  * shesek is eagerly waiting for v3.0.1 (:
10:21 < andytoshi> heh we're definitely going to 4.0
10:21 < andytoshi> we broke a lot of the API
10:22 < andytoshi> i think you'll be really happy with the new interpreter API
10:22 < andytoshi> i'll pr in 20-30 minutes, i think i have a plan for what i want to add now
10:23 < shesek> very cool, looking forward to see what you came up with
10:39 < andytoshi> sanket1729_: i didn't realize, we didn't expose from_str_insane for Descriptor ... i wonder if we should
10:39 < andytoshi> i guess not
10:41 < sanket1729_> I don't have a strong opinion. Honestly, that was not deliberate and I forgot about it
10:48 < andytoshi> also can you make sense of this comment https://github.com/rust-bitcoin/rust-miniscript/blob/e18d52c078e62cb2a14cffa20bad3ecdf6382965/src/psbt/finalizer.rs#L224
10:48 < andytoshi> i'm just gonna remove it
10:49 < sanket1729_> yes     
10:49 < sanket1729_> you can remove it
10:56 < andytoshi> sigh why does https://docs.rs/bitcoin/0.25.2/bitcoin/util/bip143/struct.SigHashCache.html#method.signature_hash take a Script as the scriptcode
10:56 < andytoshi> when the witness script is a Vec<u8> in the actual transaction
10:57 < andytoshi> i guess, there is a general problem with rust-bitcoin where scripts are Vec<u8> internally and they should be Cow
10:57 < andytoshi> there is no way to convert byteslices to scripts without cloning which sucks
10:58 < andytoshi> https://github.com/rust-bitcoin/rust-bitcoin/issues/522
11:17 -!- otoburb [~otoburb@unaffiliated/otoburb] has joined ##miniscript     
12:29 < andytoshi> sanket1729_: shesek: https://github.com/rust-bitcoin/rust-miniscript/pull/191
12:31 < andytoshi> maybe check out examples/verify_tx.rs to see the motivation for this
12:31 < andytoshi> or better, look at the diff in src/psbt/finalizer.rs ... it's way simpler _and_ it does the right thing with sighashflags now
12:32 < andytoshi> a lot of the diff is moved code actually
12:32 < sanket1729_> reviewing
12:33 < andytoshi> oh oops i added `util.rs` which i wound up never using, one sec i'll rebase that away
12:34 < sanket1729_> I also added a util.rs in satisfy_fail PR
12:35 < andytoshi> did yours have any code in it? :P
13:20 < sanket1729_> the inferred descriptor is really cool
13:20 < sanket1729_> Nice way to get around Nocheck
13:21 < sanket1729_> serialize and deserialize :)
13:24 < andytoshi> yeah :P i'm a bit embarrassed that didn't occur to us before transmuting did
13:51 < andytoshi> sipa: think we want sortedmusig as well as musig?
13:52 < sanket1729_> reviewed. Was not as bad as I thought it would be. 
13:53 < andytoshi> also is shwpkh a thing?
13:53 < andytoshi> i guess it is
14:01 < sipa> sh(wpkh(...))? yes
14:01 < sipa> that's even very common in practice
14:02 < andytoshi> oh kk
14:03 < sipa> andytoshi: hmm, not sure what people have settled on as standardizing musig
14:03 < sipa> sorting may be implicitly part of it, especially if you want the factor-1-for-first-term optimization
14:04 < andytoshi> yeah that makes sense
14:04 < sipa> and if there is still room for pushing for a standard, making it sort implicitly may be a generally good idea
14:05 < andytoshi> a related question is, what is the standardness situation with descriptors/miniscript .. is it time we wrote a bip?
14:05 < andytoshi> should we wait til after taproot integration?
14:06 < andytoshi> i'd like a way to combine public keys because in elements we have this extra blinding key that should be shared by all participants in a descriptor....and i'd like as much as possible to reuse constructions that bitcoin uses
14:06 < sipa> i haven't followed up... but outstanding issues were the way we encode timelock/height, and the time/height combination stuff
14:07 < andytoshi> ah ok, so, we settled out the time/height combination stuff (it's permissible but the type system should detect it and you really shouldn't use scripts where this happens)
14:07 < sipa> (which means i'd like to see those documented and explained on the site at least)
14:07 < andytoshi> and i think we never sorted out timelock/height...iirc shesek did something that looked cool and then turned out to be pretty involved
14:08 < andytoshi> right, understood. we didn't write out the timelock mixing stuff, i'm pretty sure
14:08 < sipa> after that, i think it makes sense to start some kind of standardization... not sure if that means a BIP
14:08 < sipa> one issue is that descriptors inherently have lots of optional parts
14:08 < andytoshi> i think that if bip44/49/84 make sense as BIPs (these just define a bunch of bip32 paths) then descriptors probably do as well
14:09 < andytoshi> hmm, yeah
14:09 < sipa> e.g. it's totally reasonable that one implementation only aims at segwit stuff
14:09 < sipa> or doesn't include (all of) miniscript
14:09 < andytoshi> right
14:09 < sipa> so maybe the first step would be creating some sort of repository with all "fragments", and say you're free to implement any or all or none of them... but if you do, they correspond to exactly these scriptPubKeys
14:10 < sipa> so something will either not work, or match the spec
14:10 < andytoshi> right, that sounds reasonable
14:11 < andytoshi> i guess we could put the script encoding and all the type props into a json structure ... which would also make these easy to integrate into Core functional tests
14:11 < sipa> spec should include the descriptor fragment notation, the scriptPubKey it corresponds to, and perhaps some notion of how it relates to PSBT fields
14:11 < andytoshi> right
14:11 < sipa> as in a way, you can see PSBT fields as an encoding for (subsets of) information in a descriptor
14:11 < andytoshi> yea     
14:12 < sipa> (excluding the final/partial sigs fields, and UTXO fields)
14:12 < sipa> but redeemscript/witnessscript/bip32 fields all map quite neatly to descriptor aspects
14:13 < andytoshi> interesting, there are a couple layers here
14:13 < andytoshi> the key encoding maps to the bip32 fields
14:13 < sipa> i also think the spec document for miniscript fields can just link to the miniscript spec site, and say "under condition that the type system explained there works out"
14:14 < andytoshi> pk and the hashes map to the pk:signature and hash:preimage fields
14:14 < sipa> it doesn't need to repeat everything
14:14 < andytoshi> sh/wsh/etc map to redeemscript/witnessscript/non_witness_utxo
14:14 < andytoshi> I think it'd be helpful if we had the specs in a machine-readable format that we could store in the bips repo (if a BIP is indeed how we want to approach this)
14:15 < andytoshi> then agreed, we could just link to that
14:15 < andytoshi> oh, i see, you're referring even to "what these types mean"
14:15 < andytoshi> that could remain on your site
14:16 < sipa> something else i had been musing about is whether we want a binary encoding for descriptors
14:16 < andytoshi> hmm, it's a bit difficult as there isn't really a binary encoding for the keyorigin stuff, is there?
14:16 < andytoshi> i guess we could define one
14:16 < sipa> as the human-readable form is rather involved, and needs an actual parser to deal with... which has stack exhaustion issues if done naively
14:17 < sipa> and there are applications that just don't actually need the string representation ever
14:17 < andytoshi> even a binary encoding would probably lend itself to naive recursive parsing
14:17 < sipa> say a hw signer that needs a way to register what sPKs it considers "its own"
14:17 < andytoshi> right
14:18 < sipa> but fair... maybe a binary parser isn't all that much simpler
14:19 < andytoshi> the coldcard, as one example, uses a lot of encodings that are actually ascii strings...i kinda wish more hwws would do this
14:19 < andytoshi> but i could be convinced that you could make the binary encoding much easier/safer
14:19 < andytoshi> by e.g. adding length prefixes
14:19 < sipa> or... sending them as PSBT fields
14:19 < sipa> that could be the binary encoding
14:21 < andytoshi> are you suggesting using the existing PSBT format (which i think covers all the information in a descriptor) as the "binary encoding" of a descriptor
14:21 < sipa> yeah
14:21 < sipa> just musing
14:21 < andytoshi> yeah, that sounds reasonable to me actually
14:21 < sipa> but given the overlap, it's not crazy
14:22 < andytoshi> if you were writing a hww that wanted to sanity check things, it could just pull the data it cared about out of PSBT
14:22 < andytoshi> and if it wanted to show a complete thing to the user ... it pretty-much needs the string representation
14:22 < sipa> yeah
14:25 < sipa> anyway, i think the first step there is finalizing the miniscript spec with the time/height stuff (both how to encode it, and the conflict detection typesystem)
14:26 < andytoshi> i concur
14:29 < sipa> cool
14:38 < sipa> actually maybe we can go as far as saying "output descriptors are a human-readable notation for (complete sets of) script-related PSBT fields"
14:39 < andytoshi> yeah, i like that
14:39 < andytoshi> then miniscript would be "just the witness script" or something like that
14:40 < andytoshi> not that i think we should be talking about miniscript really
14:40 < andytoshi> i think it causes confusion unless you're actually implementing descriptor support
14:40 < andytoshi> better to treat it as just part of descriptors
14:41 < sipa> yeah
15:51 < andytoshi> it would be nice if we could write conversion between descriptors and PSBT, but we can't quite do this becaues PSBTs are tied to an unsigned tx
15:51 < andytoshi> we could define a standard way to do this where we use a dummy tx, like in BIP 322
15:52 < sipa> the script fields are all independent of that, though
15:52 < andytoshi> right, but without it, the PSBT won't parse
15:53 < andytoshi> we could just say, stick the minimal 1-in-1-out tx in there (with zeroed out prevout, fffffff sequence, etc)
15:53 < sipa> do we need to?
15:54 < sipa> it's well defined without it... "this descriptor translates to these txin PSBT fields"
15:54 < sipa> to test it, you can put whatever transaction along with it, if need be
15:54 < andytoshi> that's true but if you try to serialize/parse it to actually put it on the wire, with existing PSBT libraries, i'm afraid they'll error out
15:54 < andytoshi> i think rust-bitcoin's psbt parser will
15:55 < sipa> they should
15:55 < sipa> but that's not what i mean... the only point of turning it into a full PSBT is for testing
15:56 < sipa> the script fields created don't depend on what tx is being signed
15:56 < sipa> i don't think we disagree, except about the fact that that dummy tx you add for testing needs or doesn't need to be part of the standard
15:56 -!- jonatack [~jon@109.202.107.147] has quit [Ping timeout: 260 seconds]     
15:56 < andytoshi> right but you need to store/transmit those fields somehow right?
15:56 < sipa> yes     
15:57 < sipa> but the spec can be "descriptor X turns into PSBT txin fields Y", without ever caring or even knowing that such a thing as a full PSBT exists
15:57 < andytoshi> ah yeah, ok
15:58 -!- jonatack [~jon@213.152.162.104] has joined ##miniscript     
15:59 < andytoshi> sanket1729_: force-pushed the interpreter to fix 1.29 compilation. will do the other changes in additional commits, so you don't have to sift through a rebase of 1000s of loc
17:35 -!- roconnor [~roconnor@host-104-157-230-3.dyn.295.ca] has quit [Ping timeout: 260 seconds]     
17:46 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]     
18:05 -!- roconnor [~roconnor@host-104-157-230-3.dyn.295.ca] has joined ##miniscript     
19:57 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript     
22:37 -!- jonatack [~jon@213.152.162.104] has quit [Ping timeout: 260 seconds]     
22:39 -!- jonatack [~jon@213.152.162.79] has joined ##miniscript     
23:00 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]     
23:04 -!- roconnor [~roconnor@host-104-157-230-3.dyn.295.ca] has quit [Remote host closed the connection]     
23:04 -!- roconnor [~roconnor@host-104-157-230-3.dyn.295.ca] has joined ##miniscript