--- Log opened Mon Oct 03 00:00:37 2022
00:50 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
01:06 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
01:43 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
04:52 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
07:22 < salvatoshi> Hey @sanket1729, I will start working soon on support for taproot scripts for the Ledger bitcoin app. I was wondering: how stable is the set of fragments (and their properties for sanity etc.) defined for taproot miniscripts? And if it's not fully stable yet - is there an interesting-enough stable subset that I could target for a first release?
07:23 <@sipa> I don't think we've defined anything at all for taproot-miniscript?
08:17 < salvatoshi> @sipa any blocker for that to happen? And any way I can help? I'd like to get involved, as it's quite mission-critical for my roadmap!
08:18 <@sipa> I think on the C++ side we really want segwit-miniscript done first, before introducing taproot changes.
08:18 <@sipa> (and we're very close)
08:19 <@sipa> https://github.com/bitcoin/bitcoin/pull/24149
08:19 < darosior> salvatoshi: it is for me as well, i'm going to start thinking about it very soon
08:20 < darosior> But first i'll rebase 24149 :p
08:20 <@sipa> After that... probably some discussion about what changes are needed? I vaguely recall some talking here long ago, but I have no idea where that discussion went.
08:22 <@sipa> darosior: FWIW, I have a very nice fuzz test corpus for the 4 tests now, with several months of CPU time in it. And using techniques like taking the smart/stable corpus, and converting them to scripts/string and feeding those in the respective corpuses.
08:22 < darosior> On top of my head: multi_a, resource limitations tweaks, and then probably most of the changes would be on the side of the compiler?
08:22 < darosior> sipa: nice!
08:22 <@sipa> Also some new rules we can rely on (some standardness stuff became consensus).
08:22 <@sipa> MINIMALIF, in particular?
08:23 < darosior> Yes, but should we change the type system in Taproot context just to save one byte?.. 
08:24 <@sipa> for fragments where it matters we may instead want to use a separate name instead (like say d: and y: are really the same opcodes, but y: has different typing rules, and is only usable in taproot).
08:31 < darosior> sipa: i have a slightly related question, because it's been blocking my progress on #24149 follow-ups. In Bitcoin Core currently we simulate signing with the dummy signer to estimate the size of a spending witness. But we have all the information we need from the descriptors, we don't need to simulate signing. I've been working on a patch for doing
08:31 < darosior> that but it's getting a bit invasive. Do you think it's worth it?
08:31 < darosior> I think it'll help a lot for things like https://github.com/bitcoin/bitcoin/pull/24149#issuecomment-1213092373.
09:01 -!- jonatack [~jonatack@user/jonatack] has joined ##miniscript
09:23 <@sipa> darosior: Haven't had time to look in detail, but conceptually it makes a lot of sense to me for descriptors to just get witness size estimates from descriptor logic directly.
11:27 < jeremyrubin> sipa salvatoshi I think rust mini script does have taproot script support presently? Unless I'm mistaken
11:27 < jeremyrubin> Maybe it's not standardized? But it seems to work. 
11:27 < jeremyrubin> (ponders in multisig emitted fragments)
11:33 <@sipa> Ok, I didn't know about that. It's fine to have extensions of course, but I'd really like to see this documented and standardized so everyone can scrutinze the same thing.
11:35 < darosior> Yes it does but iirc it is experimental
16:53 < jeremyrubin> sanket1729 andytoshi why do the Policy fragments And/Or take vecs and not just a tuple/array?
16:55 < jeremyrubin> or rather Box<(Self, Self)>
16:56 < jeremyrubin> or (Box<Self>, Box<Self>) (req'd for the self-ref)
17:18 < andytoshi> jeremyrubin: because eventually they will be n-ary
17:18 < andytoshi> interesting that Box<(Self, Self)> wouldn't be doable
17:21 < jeremyrubin> ah either is OK
17:22 < jeremyrubin> you just need one heap allocation somewhere
17:23 < andytoshi> arguably we should replace the vec with a tuple though, we have no immediate plans to figure out n-ary policies
17:23 < andytoshi> and a bunch of other immediate plans that will take us the next $indefinite_future
17:24 < andytoshi> sanket1729: thoughts on doing this, while we're breaking Policy anyway?
17:31 < jeremyrubin> I think it would be fine to also just remove the And and Or variant and replace them with a static function And and Or which takes the same args and stubs in a threshold...
17:31 < jeremyrubin> altho i guess thresh can't take the probabilities
17:36 < andytoshi> oh you're talking about concrete::Policy
17:36 < jeremyrubin> it applies to both 
17:37 < andytoshi> semantic::Policy already only has thresholds iirc
17:37 < jeremyrubin> Miniscript itself doesn't really need it IMO since n-ary in the repr doesn't matter too much
17:38 < jeremyrubin> but as a frontend, I sorta think policy should strive to have safe constructors 
17:38 < andytoshi> the only place we have n-ary and/or is in policy::Concrete, which is supposed to represent a distinct language from miniscript which could indeed have n-ary and and or
17:38 < andytoshi> wdym "safe constructors"
17:38 < jeremyrubin> so NonZero is also kind a weird one for example 
17:38 < jeremyrubin> ah
17:38 < jeremyrubin> that like the enum variants don't error, to the extent possible, on translation/compilation
17:39 < jeremyrubin> so it's weird that they support Vec in policy but still throw a BinaryOp error
17:39 < andytoshi> i mean, it's always the case that if you manually construct these objects you can make invalid things that will panic
17:39 < andytoshi> for literally every object in the library i'm pretty sure
17:39 < andytoshi>  if you want to avoid that then use the actual constructors
17:40 < jeremyrubin> there aren't smart constructors for policy concrete tho
17:40 < andytoshi> there is from_str
17:40 < jeremyrubin> i agree if there were smart constructors that'd make more sense
17:40 < jeremyrubin> lol
17:40 < jeremyrubin> from_str is a constructor i suppose
17:41 < andytoshi> yes .. it is the only constructor
17:41 < andytoshi> and literally the only way that we ever construct these things outside of tests
17:41 < jeremyrubin> well who is we here ;)
17:41 < andytoshi> the people who designed and implemented miniscript
17:42 < jeremyrubin> i mean, templating into a string in order to translate out of it from rust is just sort of weird design?
17:42 < andytoshi> i'm sorry we did not document "these types are public only because it'd be impossible to satisfy every use case without exposing the innards. do not do this unless you really know what you're doing"
17:42 < andytoshi> you are welcome to come up with a different design
17:42 < jeremyrubin> ok
17:43 < andytoshi> the rust compiler also does this btw
17:43 < jeremyrubin> does what?
17:43 < andytoshi> it is designed to be interfacted via string, and if you directly construct AST types and shit you will cause errors
17:43 < jeremyrubin> ah
17:43 < andytoshi> it's basically the only sensible way to write a library for a separate laguage
17:43 < jeremyrubin> i think it would definitely be a good idea to not expose the enum how it is
17:43 < jeremyrubin> it's pretty easy to make it private to construct
17:44 < andytoshi> that would break a ton of special-case stuff
17:44 < andytoshi> including e.g. template-matching on certain-shaped descriptors
17:44 < andytoshi> if you write a full regex language (or something) for filtering and matching descriptors then you can make the constructors private
17:45 < jeremyrubin> hmm
17:46 < jeremyrubin> so the way that i've done similar things is by having a into mirror struct that doesn't impl compile 
17:46 < jeremyrubin> and you can't RT it at a type level, except via to_str -> from_str
17:46 < jeremyrubin> that gives you the power of pattern matching while prevent dumbass users like myself from doing what shouldn't be done 
17:47 < andytoshi> RT?
17:47 < andytoshi> i don't understand how you can allow arbitrary pattern matching without letting users make invalid structures
17:47 < jeremyrubin> Round Trip
17:47 < andytoshi> there is no way to make a pub(readonly) enum
17:48 < jeremyrubin> you have Policy and ViewPolicy
17:48 < jeremyrubin> impl From<Policy> for ViewPolicy
17:48 < andytoshi> ah ok .. so you can consrtuct a fucked up ViewPolicy but why would you
17:48 < andytoshi> interesting idea
17:48 < jeremyrubin> and you can call ViewPolicy::to_string
17:48 < andytoshi> right
17:48 < jeremyrubin> and Policy::from_str
17:48 < andytoshi> right
17:49 < jeremyrubin> but you don't allow From<ViewPolicy> for Policy
17:49 < jeremyrubin> if you are feeling particularly lazy, you can also make Viewable a type tag
17:49 < andytoshi> heh, that is our MO..
17:49 < jeremyrubin> struct Viewable;
17:49 < jeremyrubin> struct Invisible(())
17:49 < jeremyrubin> Policy<Viewable>
17:49 < jeremyrubin> Policy<Invisible>
17:50 < jeremyrubin> and you just need to annotate all the branches with the tag T
17:50 < jeremyrubin> it can be a phantomdata
17:50 < jeremyrubin> idk if theres a benefit of that vs zst, but the layouts are identical, so i bet it's very fast to actually convert 
17:51 < andytoshi> lol i wish
17:51 < andytoshi> but in any case .. it's plausible that our exsting tags could be adapted, for Miniscript at least
17:51 < andytoshi> like, we have segwit/taproot/etc contexts
17:51 < andytoshi> we could have a "VIewOnly" context or something
17:51 < jeremyrubin> yeah that seems like one way to do it
17:51 < jeremyrubin> Viewable can also be a trait
17:51 < jeremyrubin> trait Viewable
17:52 < jeremyrubin> and make the existing contexts impl Viewable if they should be 
17:52 < andytoshi> actually i'm not sure this works .. if we use a tag, and users can mutate/construct Policy<ViewOnly>
17:52 < andytoshi> how do you prevent them from doing the same to a Policy<Actual>
17:52 < jeremyrubin> struct Actual(())
17:52 < jeremyrubin> the () is private
17:52 < jeremyrubin> so it can't be constructed by a user
17:52 < andytoshi> ok, yeah, i see
17:52 < jeremyrubin> ah but i guess they can modify the other field?
17:53 < andytoshi> ah .. yeah.
17:53 < jeremyrubin> I think it needs to be just an inner wrapper over all the data then
17:53 < jeremyrubin> which is fine
17:53 < andytoshi> ok, that's pretty rough, i think it'd be cleaner to just duplicate the whole type then
17:53 < andytoshi> anyway we should add some docs for now telling people not to construct shit directly unless they are willing to cut themselves
17:54 < andytoshi> adding Yet Another Miniscript Datastructure is probably too invasive for right now while we're doing the taproot stuff and other cleanups
17:54 < jeremyrubin> it might also be cool to add some macros that can stitch together a string 
17:54 < jeremyrubin> that way if you *are* doing it programmatically, at least you have a valid string at the end
17:54 < andytoshi> yeah -- that'd require syntax enxts
17:54 < andytoshi> right
17:55 < jeremyrubin> that's basically the main reason i use the ast
17:55 < andytoshi> you're welcome to open a wishlist issue about this, maybe somebody will show up and do it
17:55 < andytoshi> yeah, i do the same thing
17:55 < jeremyrubin> xwdym
17:55 < jeremyrubin> I thought no one uses the ast outside of tests :p
17:55 < andytoshi> :P
17:55 < jeremyrubin> maybe i'll do it after TAB
17:55 < andytoshi> ok you caught me
17:56 < jeremyrubin> if it can be done it will be done
17:56 < andytoshi> for sure
17:56 < andytoshi> we just didn't have any good solution
17:56 < andytoshi> i like this ViewStruct idea
17:56 < jeremyrubin> btw
17:56 < jeremyrubin> i'm chasing it down and am a couple version back base
17:56 < andytoshi> but we'll want to also support some "nice" programmatic way to do construction, ideally with compile-time error catching
17:57 < jeremyrubin> but does max_satisfaction_weight ever panic / should it?
17:57 < jeremyrubin> I can see if it's been touched lately since i last rebased
17:57 < jeremyrubin> but may have found a panic
17:57 < andytoshi> oh neat
17:57 < jeremyrubin> lemme give you my script real quick...
18:04 < jeremyrubin> tr(72cd6e8422c407fb6d098690f1130b7ded7ec2f7f5e1d30bd9d521f015363793,{{{thresh(2,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),thresh(2,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808
18:04 < jeremyrubin> e3a43b9e657dca77c0))},{thresh(2,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),thresh(2,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0))}},{{and_v(v:thresh(2,pk(c6e
18:04 < jeremyrubin> 90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),older(6)),and_v(v:thresh(1,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),older(18))},{and_v(v:pk(72e11f1ccdeac36aa7507ea
18:04 < jeremyrubin> fa5a0d9ca5e03de5d40d2c398e9b10d3c0a004905),and_v(v:thresh(2,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),older(1))),and_v(v:pk(72e11f1ccdeac36aa7507eafa5a0d9ca5e03de5d40d2c398e9b10d3c0a004905),and_v(v:thresh(1,pk(c6e90fd4f35e753c84e80df064c10dc8f0b4bc1dc
18:04 < jeremyrubin> 81d0f2651b1779c0b8e3a9f),s:pk(b320989f8a02c3b628cf342fec6a681c704a7cefe60808e3a43b9e657dca77c0)),older(12)))}}})#6247e7ms
18:04 < jeremyrubin> ops
18:04 < jeremyrubin> lemme pastebin that
18:05 < jeremyrubin> https://gist.githubusercontent.com/JeremyRubin/761d4c97a69a96ec51e4a9f729d6835c/raw/1c5e6fe1b66a6dbb5a85bf9676ae156a2c22a2dc/script
18:05 < jeremyrubin> so actually it's not max_sat_weight
18:05 < jeremyrubin> it's address which is panicing on it for me
18:06 < jeremyrubin> this is in wasm btw
18:06 < jeremyrubin> im gonna put more loop{}'s to debug...
18:06 < andytoshi> i'd try to do a unit test outside of wasm
18:07 < jeremyrubin> good point
18:19 < jeremyrubin> ok it seems happy outside of wasm
18:19 < jeremyrubin> the code is kinda sketchy in this address computation thing
18:22 < jeremyrubin> i'm thinkin it is this lock poison thing
18:23 < jeremyrubin> or maybe the secp context sanity checks for wasm
--- Log closed Tue Oct 04 00:00:38 2022