--- Log opened Fri Feb 18 00:00:02 2022
00:20 < darosior> I agree with andytoshi on both points, see my comment on the gist from the other day
00:21 < darosior> sipa: cool, it can be a PR to the Miniscript repo, i'll integrate it afterward
01:30 < darosior> Ok, so once fixed the coverage of the dumb miniscript_random fuzz target is pretty good: http://download.darosior.ninja/dump/miniscript_random_dumb_coverage/src/script/index.html
02:13 -!- sipa [~sipa@user/sipa] has quit [Quit: Bridge terminating on SIGTERM]
02:13 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has quit [Quit: Bridge terminating on SIGTERM]
02:13 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Quit: Bridge terminating on SIGTERM]
02:13 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: Bridge terminating on SIGTERM]
02:15 -!- meshcollider [meshcollid@jujube.ircnow.org] has quit [Ping timeout: 256 seconds]
02:17 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
02:22 -!- meshcollider [meshcollid@jujube.ircnow.org] has joined ##miniscript
02:31 -!- sipa [~sipa@user/sipa] has joined ##miniscript
02:31 -!- mode/##miniscript [+o sipa] by ChanServ
02:31 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined ##miniscript
02:31 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
04:38 < darosior> sipa: so i've summed up the recent discussions in an issue https://github.com/sipa/miniscript/issues/98. What do you think about re-centralizing into the Miniscript repo? Do you prefer that we instead just keep working on the Bitcoin Core branches?
05:12 <@sipa> @darosior Entirely up to you 
05:24 <@sipa> It's somewhat easier for me to do it as PRs to the miniscript repo, but that's more work for you to then integrate it into your branches.
05:26 < darosior> Let's do that, but the update for the latest refactorings will be bulky
05:56 < darosior> https://github.com/sipa/miniscript/pull/99
05:58 <@sipa> great,
08:49 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
08:50 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript
09:48 < jeremyrubin> howdy; i'm working on the finalizer logic in rust-miniscript for CTV... for some reason the script: <H> CTV DROP OP_1 doesn't know it's satisfiable from the psbt code  (patches for reference https://github.com/sapio-lang/rust-miniscript/commits/sapio-lang) 
09:50 < jeremyrubin> (I need to rebase onto the newest stuff sometime)
09:51 < jeremyrubin> but i'm getting a CouldNotSatisfy error
09:55 < jeremyrubin> https://github.com/sapio-lang/rust-miniscript/blob/835647e39c18442f2b231a12a25b5823349c62ca/src/miniscript/satisfy.rs#L966 it looks like the code around this part might be off?
09:57 < jeremyrubin> should CTV be has_sig do we think?
11:08 <@sipa> darosior: Does it matter that FindInsaneSub() returns a NodeRef? Would it be ok if it returned a Node* instead?
11:08 <@sipa> (it'd be a much simpler implementation with a Node*)
11:51 < sanket1729> jeremyrubin: has sig denotes whether the fragment has signature in satisfaction. If has_sig is set to true, the witness cannot be changed by any third party. Which I think is natively true for CTV? If it's not true, you can use satisfy_mall API instead to produce satisfaction
12:30 < jeremyrubin> Yeah sadly the version I'm on doesn't have that APi yet 
12:31 < jeremyrubin> I may need to start upgrading :/
12:31 < jeremyrubin> (very tedious to rebase)
13:03 < sanket1729> I see it here: https://github.com/sapio-lang/rust-miniscript/blob/835647e39c18442f2b231a12a25b5823349c62ca/src/miniscript/satisfy.rs#L1117 . Don't know if it is actually exposed as an high level API
13:12 < jeremyrubin> ah so the satisfy is exposed, but not the finalize_mall which gets added sometime later
13:12 < jeremyrubin> but I think it'd be reasonable to set CTV to be has_sig
13:54 <@sipa> darosior: Opened 101 and 102. I have a few more changes, but I'll PR those after these are in: (a) making the fuzzer not have access to all privkeys and preimages (b) pad scripts to get ops count to 201, always (c) type-guided GenNode (with more rules than before, and even faster)
--- Log closed Sat Feb 19 00:00:04 2022