--- Log opened Wed Dec 16 00:00:48 2020 01:55 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 260 seconds] 02:13 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript 02:13 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 02:13 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 02:13 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 246 seconds] 02:15 -!- jonatack [~jon@134.19.179.147] has joined ##miniscript 03:31 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 256 seconds] 03:51 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds] 04:00 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript 04:08 < sanket1729> andytoshi: raised 213 04:28 < darosior> Looking at #213 .. If we are into refactor imho having both derive() and to_pk_ctx for descriptors is quite redundant. We should probably get rid of either one 04:30 -!- jonatack [~jon@134.19.179.147] has quit [Quit: jonatack] 04:33 -!- jonatack [~jon@88.124.242.136] has joined ##miniscript 04:37 -!- aj [aj@cerulean.erisian.com.au] has joined ##miniscript 04:38 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 246 seconds] 04:39 -!- jonatack [~jon@213.152.186.173] has joined ##miniscript 04:44 < sanket1729> The way I look at it is derive() takes wildcards to derived descriptors merely replacing * with child numbers. And to_pk_ctx based methods are required for going to actual script. 04:45 < sanket1729> I have to used those keys downstream. Do you have a better workdflow? 04:53 < darosior> sanket1729 (13:40 ): to_pk_ctx methods are required but to_pk_ctx is, in this case, completely superfluous 04:55 < darosior> "Do you have a better workdflow?" => No lol i just now basically have a get_dummy_ctx method to my global state struct to pass to derivation functions. This allows me to be sure i don't mess up and only derive using the derive() method and never mix with pk_ctx derivation 05:00 < sanket1729> What is your exact suggestion? I don't completely follow what you are suggesting. How can we get rid of to_pk_ctx ? 05:01 < sanket1729> darosior " in this case, completely superfluous". What is this case? 05:02 < sanket1729> I can get behind removing the derive method because it's specific to DescriptorPublicKey. But the to_pk_ctx thing is for generic Pk 05:08 < darosior> "What is this case?" => A derived descriptor 05:08 < darosior> I mean, if you derive your descriptor you can input whatever childNumber to the DescriptorPublickeyCtx 05:09 < darosior> Since the latter has no effect if wildcard != true 05:09 < sanket1729> ah. So you have to remember if you have already derived a descriptor or not 05:09 < darosior> Not really, but we have two ways to achieve the same behaviour (you could not derive your descriptor but use DescriptorPublickeyCtx's chilNumber instead) 05:11 < sanket1729> ok, i get the redundancy 05:11 < darosior> I mean it's not a footgun as such but (maybe i missed something and it already is or) could become one and imo it's a poor API: so my initial suggestion was "since we gonna break the API, let's break it more" :) 05:11 < darosior> And remove one of the two ways 05:12 < sanket1729> probably should also get input from the bdk guys on this 05:13 < darosior> And shesek, ping: shesek :) 05:13 < sanket1729> Some relevant discussion here 05:13 < sanket1729> https://github.com/rust-bitcoin/rust-miniscript/issues/181 05:13 < darosior> But hey i don't have any concrete proposition too.. 05:13 < sanket1729> yeah, even I am not sure 05:14 < sanket1729> But I agree since we are breaking things. It is worth investigating these 06:14 < shesek> the DescriptorPublickeyCtx childNumber did seem redundant to me when I noticed it was added, I even asked about this here and was told that one reason for having it is that its more efficient for cases where you only need the child spk and not the child descriptor. this makes sense to me, I think that having separate ways to derive spks and descriptors is reasonable and potentially useful. I ended up switching to using the ctx child code in bwt 06:14 < shesek> in places where I don't need the child descriptor 06:16 < shesek> one thing that I do find strange is that you can derive() (or use the ctx child code) on non-wildcard descriptors. it would be useful if the type system differentiated wildcard and non-wildcard and prevented that 06:16 < darosior> Right, efficiency is a good point 06:16 < darosior> +1 06:29 < andytoshi> i think we didn't differentiate so that we could get something usable out without designing a super complicated type API in a vacuum 06:29 < andytoshi> we can definitely try it now 06:41 < andytoshi> sanket1729: i wonder if we should just implement our own signmessage which prefixes "miniscript signed message:", outputs a compact bip340 sig in hex, and just claim that as a defacto signmessage protocol 06:42 < andytoshi> or i guess, we should prefix it with a bip340 tag 06:42 < andytoshi> "miniscript/signmessage" or something 06:42 < sanket1729> andytoshi: do you need another protocol. 06:42 < andytoshi> what do you mean 06:42 < sanket1729> There must be something in bitcoin core for sign message 06:42 < andytoshi> there is no protocol 06:42 < andytoshi> lol there is not 06:43 < andytoshi> i envy you for being unaware of this drama 06:43 < sanket1729> lol 06:43 < andytoshi> sanket1729: there is "signmessage"/"verifymessage" which works with p2pkh keys 06:43 < andytoshi> there was no equivalent for p2sh, or segwit v0, or taproot 06:44 < andytoshi> for p2sh there were various ad-hoc multisig-only proposals people made but never anything that stuck because when they proposed to "standardize" it it'd get bikeshed to death about not being general enough 06:44 < andytoshi> so eventually this turned into bip322, which kalle proposed and is very simpilar to how signet signs blocks 06:45 < andytoshi> where you have a pair of pseudo-transactions which cannot be valid on the real network (as they spend the 000..000:ffff output) 06:46 < andytoshi> but this then cannot be verified without a script interpreter, and it has this bizarre two-tier validity model based on Bitcoin Core's current standardness rules, which change frequently and aren't exposed in any library 06:46 < andytoshi> and also it has been bikeshed to death by the likes of luke arguing philosophical things about what signmessage really "means" wrt having control of keys 06:47 < andytoshi> and it has been rewritten multiple times, and i have tried and failed to implement a couple of them because they are underspecified and have no test vectors 06:48 < sanket1729> Another thing, we don't have any signing in miniscript currently. We only have satisfy methods which assume that we have signatures 06:48 < andytoshi> right, we'd basically use the satisfy logic 06:48 < andytoshi> require a bip340 sig of H_"miniscript/signmessage"(decsriptor.scriptpubkey() || message)" 06:49 < andytoshi> then output a (scriptsig, witness stack) pair 06:49 < andytoshi> ok we have to make a decision about timelocks (also something that bip322 did a bunch of iteration on and the current incarnation is super confusing) 06:50 < sanket1729> Yeah, we have supply nsequence and nlocktime externally. 06:50 < andytoshi> i think the "what to do about timelocks" is that you just provide them to the witness-constructor and to the verifier. same as you do with txes 06:50 < andytoshi> right, that's super easy 06:51 < sanket1729> But that should be somehow covered in hash. So that the verifier does not need to understand how to parse miniscript 06:51 < andytoshi> how could the verifier possibly not understand miniscript? 06:51 < sanket1729> Or maybe it verifier needs to understand miniscript 06:51 < andytoshi> yeah 06:51 < sanket1729> I was thinking it looks at hex of it in blockchain 06:51 < sanket1729> hex of spk 06:51 < andytoshi> in what blockchain? 06:52 < sanket1729> The use case signing i control this utxo 06:52 < sanket1729> at bitcoin blockchain at a particular height and a particular tx index, output index 06:53 < andytoshi> so like, you'd actually sign a tx spending that utxo? 06:53 < sanket1729> Nevermind. The verifier needs to understand miniscript. I was wrong :) 06:53 < andytoshi> that introduces general script verification, questions about standardness, requires implementation of multiple insane sighash formats, and is easy to get wrong and accidentally spend the coins 06:54 < andytoshi> ok :) 06:54 < andytoshi> so anyway. i think we should just tack a new method "signmessage" onto the existing satisfier trait 06:55 < andytoshi> and i guess it should output a (scriptpubkey, scriptsig, witness) tuple 06:55 < andytoshi> then we'd add a convenience method which can verify that tuple, and one which takes a descriptor and checks that the spk matches 06:55 < andytoshi> and then just quietly release that in rust-miniscript 06:57 < sanket1729> I don't think it fits in satisfier. Rather I think it should a struct on which we implement satisfier 06:57 < sanket1729> struct signmessage{ msg, locktime, sequence, miniscript} 06:58 < andytoshi> or rather, it'd have a method which takes &self and also a satisfier 06:58 < andytoshi> yeah you're right 06:59 < sanket1729> We will verify that signatures are indeed correct w.r.t to new bip340 style sighash, in lookup_sig methods 06:59 < andytoshi> in a real signmessage protocol we'd want e.g. a sane story for how to do multisignatures (e.g. we should use a dummy tx and PSBT) 06:59 < andytoshi> though maybe with psbt v2 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018300.html we don't need a dummy tx? 07:00 < andytoshi> sanket1729: we'd do signature checks in the interpreter 07:00 < andytoshi> same as we do for transactions 07:00 < andytoshi> though i guess, in this case we can also do it in the satisfier 07:00 < andytoshi> that sounds like it might be hard to do with our current architecture 07:01 < sanket1729> what might be hard to do? 07:01 < andytoshi> inserting signature checks into satisfaction generation 07:01 < sanket1729> Yeah, we would need secp context too 07:02 < andytoshi> yes and also a sighash, and we would need to change the satisfier to somehow take this data 07:02 < sanket1729> sighash comes from the struct right 07:02 < sanket1729> We don't change satisfier at all 07:03 < sanket1729> we implement lookup_sig to additional check whether the given pk, sig pair verifies to the given sighash in the struct over which we are implementing satisfier 07:04 < andytoshi> wdym "we implement lookup_sig" 07:04 < andytoshi> on what? 07:06 < sanket1729> We need to have something on which we can implement satisfier, right? So we need sighash_msg ,Map, Map, nsequence, nlocktime. 07:06 < andytoshi> there are already a ton of things that implement Satisfier 07:06 < andytoshi> why can't we just use those 07:07 < sanket1729> I was trying to also do the signature check in the satisfier. 07:07 < sanket1729> But it's not necessary 07:07 < andytoshi> this seems like a ton of work to achieve that 07:07 < sanket1729> we can do the 2 step thing with the interpreter API 07:08 < andytoshi> wdym 2-step thing? 07:08 < andytoshi> you mean signing and verification? 07:08 < sanket1729> Step 1) There is a get_satisfaction API for descriptor which returns (witness, scriptsig), compute spk from descriptor. 2) Feed into interpreter API with sighash message to check we are signing the correct thing 07:09 < aj> andytoshi: hmm, seems like treating bip322's "standardness" as "expressable as miniscript" would work fine 07:09 < andytoshi> aj: so i tried this a couple weeks ago and can't make heads or tails of bip322 as written 07:09 < andytoshi> and i tried pinging kalle on #bitcoin-core-dev and got no response 07:09 < andytoshi> and i assume he's tired of rewriting bip322 over and over 07:10 < sanket1729> Satisfier could be signing anything. We need to check that is the correct sighash which we can only do via the interpreter API 07:10 < andytoshi> sanket1729: ??? 07:10 < aj> andytoshi: he was offline for a while recently, dunno 07:10 < andytoshi> if somebody provides an invalid siganture you get an invalid satisfaction 07:10 < andytoshi> same as transacitons 07:10 < andytoshi> i don't understand why we want extra checking logic here 07:10 < sanket1729> I mean, it could be sign for a different message 07:10 < andytoshi> so 07:10 < andytoshi> then let's just throw that in the witness, it won't validate, that's fine 07:11 < andytoshi> if people want to check the sigs they're providing, they can do that, same as they do for transactions 07:12 < sanket1729> sanket1729: I guess I just meant as a double check for our API. Here is an example something that can go wrong 07:12 < sanket1729> I give satisfier sigs with sighash messages "Yes". 07:13 < sanket1729> And while calling the API I feed it the message "No". Now note that satisfier does not check the sighash. It will output something like BEGIN SIG: "No" which is invalid 07:13 < sanket1729> But our API currently as it is won't fail 07:14 < andytoshi> yes...the same is true for transaction satisfaction 07:14 < sanket1729> we do check in psbt 07:14 < andytoshi> yes, but this is not psbt 07:14 < andytoshi> we can do an interpreter check, like we do in psbt 07:15 < sanket1729> but we can do the check here. which is what I mean by 2 step. 07:15 < andytoshi> (i don't really think think this is necessary in PSBT either btw, but i accept that it gives more useful error messages than producing a bad tx) 07:15 < sanket1729> because we have all the information. 07:15 < sanket1729> I don't have a strong opinion. My only reasoning was "we can do some checks, we should do those" 07:15 < andytoshi> we can't do the checks though without changing our existing API :) 07:16 < andytoshi> i do think we ought to add an interpreter check, just like in PSBT 07:16 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 07:16 < sanket1729> We can. What I am suggesting won't change any APIs 07:16 < sanket1729> I think 07:16 < sanket1729> 1) Satisfy API 2) Interpreter API 07:17 < sanket1729> Satisfy would give ssig, wit and spk 2) Interpreter would use those along with sighash 07:17 < andytoshi> ah, ok, if that's what you're suggesting then i'm happy 07:19 < sanket1729> This is interesting for taproot if you want to prove script path 07:20 < sanket1729> Actually, it is possible to prove script execution in zero knowledge 07:20 < sanket1729> Prove that you can spend the redeem script without revealing the redeem script. 07:21 < andytoshi> hehe, if we implemented some pretty big hashes in zkp :) 07:21 < andytoshi> russell wrote a simplicity -> arithmetic circuit mapping a couple years ago 07:22 < andytoshi> we could combine that with a zkp of the minicsript->simplicity translation, and the miniscript->spk translation 07:24 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript 07:24 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 07:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 08:44 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 08:52 < sanket1729> andytoshi: I figure you are the best person to ask this since you do this for elements and bitcoin codebases. I have elements-miniscript that is updated to miniscript 4.0.0. There are about 20 commits that I want to cherry-pick into new repository.(not a fork) 08:52 < sanket1729> What is the best way to do this? Do you have scripts that I can alter for this 08:59 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript 11:46 < andytoshi> do you really want to cherry-pick? 11:47 < andytoshi> oh i see, your 20 commits are on the fork 11:47 < andytoshi> you can use git-rebase for this 11:47 < andytoshi> but bear in mind you will have to force-push master on your fork 11:48 < andytoshi> which is fine at the current state of element-miniscript 12:10 < sanket1729> I did the rebase 12:17 < sanket1729> andytoshi: can you look at https://github.com/ElementsProject/rust-elements/pull/68 and publish a release? 13:17 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 13:18 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 13:54 < andytoshi> sanket1729: sure 13:55 < andytoshi> sanket1729: there is an unused function warning, can you make that go away 13:55 < andytoshi> remove the split_anyonecanpay_flag fn i guess 14:55 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds] 14:59 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript 15:15 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 258 seconds] 15:33 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript 17:24 -!- Netsplit *.net <-> *.split quits: michaelfolkson, windsok, RubenSomsen, achow101 17:30 -!- Netsplit over, joins: RubenSomsen, achow101, michaelfolkson, windsok 19:08 < sanket1729> I don't see any warnings. 19:08 < sanket1729> strange 21:58 < sanket1729> I guess the warning in not in the head commit 21:58 < sanket1729> will fix it --- Log closed Thu Dec 17 00:00:49 2020