--- Day changed Tue Nov 17 2020 03:01 -!- Aleru [sid403553@gateway/web/irccloud.com/x-asyxvyzcwscqcemj] has quit [Quit: Connection closed for inactivity] 06:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 08:26 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript 09:34 < sanket1729_> andytoshi: How does this look? https://gist.github.com/sanket1729/e9466db60cdf73e9067fe3cf0934e9c6 09:51 < andytoshi> heh does it actually reduce the repitition? 09:53 < andytoshi> oh i see, it does because wshinner is in both Descriptor and ShInner 09:53 < andytoshi> yeah ok i like this 09:54 < andytoshi> would be good to get feedback from affilini and darosior 09:59 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript 10:17 < darosior> Hmm, what's the rationale already for changing this ? 10:18 < andytoshi> massive code duplication 10:19 < andytoshi> we're going to do something similar in the elements fork because we'll have a blinded() descriptor that wraps sh, wsh, pk, wpkh, taproot 10:19 < andytoshi> here there's a bit less justification since sh(wsh()) is really the only place where there's a lot of eliminable duplication 11:25 < darosior> Thanks 11:49 < andytoshi> i had thought initially that the elements story would be simpler if we also did this upstream, but now i think it doesn't really matter 11:50 < andytoshi> i still want to do this for code cleanliness 11:50 < andytoshi> but if you think it'd disrupt you too much darosior we can hold off 11:50 < andytoshi> s/hold off/not do it/ 11:53 < darosior> No, it's fine, i was prepared for a big breaking change for the next version anyway, but thanks :) 11:53 < darosior> I just wanted to hold off my feedback until i could look in the matter actually as i saw the ping but don't exactly remember the source of duplication 13:01 < sipa> andytoshi, sanket1729_: anyone remember why d: requires a 'z' argument? https://github.com/sipa/miniscript/issues/49 13:03 < andytoshi> sipa: becasue when the inner fragment is executed, the 0/1 that the user provides as a branch condition will still be on the stack 13:04 < andytoshi> i think we're thinking of d as a "single-branch or_i" 13:04 < andytoshi> let me squint at dmitry's comment in more detail 13:04 < sipa> oh, of course 13:04 < sanket1729_> D is DUP IF [X] ENDIF. If [X] is not Z, we have more elements on the stack when it is satisfied? 13:06 < sipa> right, if you satisfy with "sat(X) 1", the 1 would be fed to X 13:06 < sipa> so really sat(d:*) is "1" 13:06 < sipa> not "sat(X) 1" 13:06 < andytoshi> yeah 15:22 < andytoshi> sanket1729_: maybe instead of "satisfaction" and "non-satisfaction" rules we should call them "local" and "global" rules 15:22 < andytoshi> i.e. a miniscript is globally invalid if its redeemscript is too large, but locally invalid if some satisfaction mixes timelocks 15:23 < andytoshi> and "everywhere locally invalid" if every satisfaction is invalid, although the script doesn't break any global rules :P 15:24 < andytoshi> also we should define "locally valid" to imply global validity 15:24 < andytoshi> then we could say that the compiler produces scripts that are everywhere locally valid 15:24 < andytoshi> but we parse any script which is globally valid 15:25 < andytoshi> and sign any script using a locally valid satisfaction 15:43 < sanket1729_> andytoshi: I like the notions of invalidity 15:44 < sanket1729_> But the validity ones are confusing. The compiler producing locally valid seems odd 15:44 < andytoshi> i guess, we'd have analogous "globally standard" and "locally standard" 15:45 < andytoshi> what is odd about it? 15:45 < sipa> is there a need for such a distinction? if you include resource limits as properties on every level, then they become the same 15:45 < sipa> like: validity of any (sub)expression requires that that subexpression's resource limit rules aren't exceeded 15:46 < andytoshi> by every branch? 15:46 < sanket1729_> locally valid is always valid. globally valid may contain some invalid spend paths 15:46 < sanket1729_> By looking at names, globally valid should be one that is always valid(good miniscript) 15:46 < andytoshi> i would prefer "locally valid" to refer only to a branch, and "everywhere locally valid" to mean that every branch is locally valid 15:46 < sipa> andytoshi: well, it's recursive; if a subexpression's resource limits are exceeded, then its parents also have their limits exceeded 15:46 < andytoshi> "globally valid" refers to checks on the csript itself 15:47 < andytoshi> sipa: again, recursing down every branch? like if i have an or_i(valid, invalid) that should just be unilaterally invalid? 15:47 < sipa> andytoshi: yes? 15:47 < andytoshi> how can i express then that the signing logic may be willing to use the valid branch 15:48 < sanket1729_> sipa: This distinction is between miniscripts that are always invlaid(Script size more than 3600) or satisfaction time(contains some path that has more than 201 ops) 15:48 < sipa> oh, you're talking about a much more strict notion of validity here 15:48 < andytoshi> yeah, we are trying to implement a shitload of checks in rust-miniscript which are enforced under different conditions 15:48 < andytoshi> and trying to come up with sane names in our API 15:50 < sipa> sanket1729_: so say we're talking about just the script size more than 3600 for a second 15:50 < sipa> does that need a separate "global" validity notion? it seems to me you can just that any miniscript is invalid if its script encoding is over 3600 bytes 15:50 < sipa> and the root isn't special in this regard 15:51 < andytoshi> my notions of local vs global are about branches, not about subexpressions 15:51 < sipa> oh ok 15:51 < andytoshi> i'm not privileging the root; indeed any subexpression can be globally invalid if its script size is >3600 15:52 < sipa> got it 15:52 < andytoshi> but this is a good observation that there another natural notion of "local" here that people may infer.. 15:52 < andytoshi> hmm 15:54 < andytoshi> for semantic analysis i think it's reasonable to consider a miniscript to be a set of spending conditions (branches) 15:54 < andytoshi> and for limit analysis it's reasonable to consider a miniscript to be a script-tree 15:54 < andytoshi> but these sorta overlap when we consider "satisfaction-specific limits" 15:57 < sanket1729_> andytoshi: How can I drop the .map in your comment? 15:58 < andytoshi> just call .count on the iterator without converting its output 15:59 < sanket1729_> But I need to convert some elements (pk -> pkh) 15:59 < andytoshi> in order to count them? 15:59 < sanket1729_> ah right 15:59 < sanket1729_> oops 15:59 < andytoshi> :) 16:00 < sanket1729_> w.r.t I think that is more an internal issue, right? Our API names don't change 16:00 < sanket1729_> w.r.t naming 16:01 < andytoshi> i'd like all the names on the Context trait to change 16:01 < andytoshi> which are exposed in the API 16:01 < andytoshi> i guess changing that doesn't need to be part of this PR 16:02 < andytoshi> i overlooked that these names were fixed by the trait, you can't change them without changing them everywhere 16:03 < sanket1729_> I like the validity names now that I think about them again 16:04 < sanket1729_> Should have the distinction between consensus and policy rules? 16:04 < sanket1729_> I guess there is no harm in having thme 16:04 < sanket1729_> and could probably be useful blockexplorer. 16:06 < andytoshi> yeah, we should have global/local valid/standard 16:06 < andytoshi> and then one notion of "analyzable" 16:08 < sanket1729_> so check_satisfaction_rules goes to is_locally_valid()? and check_non_satisfaction_rules() is is_globally_valid() ? 16:09 < andytoshi> yep 16:09 < andytoshi> actually 16:09 < andytoshi> is_everywhere_locally_valid() 16:10 < andytoshi> i'm open to suggestions for "everywhere local" :P 16:10 < andytoshi> but i'd prefer just "local" to only refer to individual branches 16:12 < sanket1729_> So, we only change those two names right? 16:13 < sanket1729_> sanity_check() is our current name for analyzable 16:14 < andytoshi> yeah 16:14 < andytoshi> i'm happy with sane/insane for analyzable :P 16:15 < sanket1729_> last thing 16:15 < sanket1729_> https://github.com/rust-bitcoin/rust-miniscript/pull/168#discussion_r525601902 16:16 < andytoshi> i think you should be able to add a method to SortedMultiVec which takes a Ctx parameter and generates the appropriate kind of Miniscript and then sanity checks it 16:16 < andytoshi> it will just take you several tries to get the syntax right :P 16:16 < sanket1729_> okay, let me try. I rememeber doing this and failing 16:22 < sanket1729_> Yes, it works. I don't know what went wrong the first time 16:25 -!- shesek` [~shesek@164.90.217.137] has joined ##miniscript 16:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 16:29 < andytoshi> awesome 16:31 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##miniscript 16:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 16:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 16:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 16:44 < sanket1729_> andytoshi: Added the name refactors as a follow up commit. I can also update the PR to remove that commit and have the changes into respective commits. 16:48 < andytoshi> nah additional commits are fine 16:51 < andytoshi> cool, let's let CI pass and let my local tests pass 16:51 < andytoshi> and then i'll merge this and open a followup PR with a couple tiny things 17:09 < andytoshi> sanket1729_: https://github.com/rust-bitcoin/rust-miniscript/pull/186 ok it turns out they were super minor, i should've just asked you to do them :P 17:09 < andytoshi> the bulk of it is that i ran a spellchecker over the whole codebase 17:18 < sanket1729_> cool 17:18 < andytoshi> i'm reviewing the satisfier PR 17:18 < andytoshi> and then i'm going to PR to shuffle around the satisfied_constraints API a bit 17:18 < andytoshi> and then i think we're good to go to release 17:20 < sanket1729_> that has more generics that I wanted to have 17:20 < andytoshi> satisfied constraints? 17:20 < sanket1729_> That satisfier PR 17:20 < andytoshi> ah 17:21 < sanket1729_> I tired to combine something to remove duplicate code, but ended up complicating other parts 17:21 < andytoshi> frustrating 17:21 < andytoshi> i think this might just be inherently pretty generic stuff 17:22 < andytoshi> yeah, i see...some of it would've been saved if ToPkCtx were an associated type 17:23 < andytoshi> but i think that turned out to be unworkable 17:23 < sanket1729_> Yeah, associated traits are unstable. Maybe 5 years down 17:23 < andytoshi> and conceptually isn't really right, you can imagine some types might work with many different contexts 17:23 < andytoshi> lol 17:24 < andytoshi> is changing the main Miniscript::satisfy function to try malleable satisfactions if it can't do nonmalleable ones 17:24 < andytoshi> i don't think we want to do that 17:27 < sanket1729_> why not? 17:27 < sanket1729_> Better to satisfy than not right? 17:28 < sanket1729_> or should we have a separate function? 17:28 < andytoshi> i think we should have a separate function 17:28 < andytoshi> the user should know that they're producing a malleable signature if they are 17:29 < sanket1729_> okay, will update the PR. satisfy_malleable() function 17:29 < andytoshi> thanks 17:29 < sanket1729_> Should that try nonmalleable one first? 17:29 < sanket1729_> or directly the malleable one? 17:29 < andytoshi> heh good question 17:29 < andytoshi> probably it should directly do the malleable one 17:29 < andytoshi> we should write a fuzz test to check that the malleable one always produces signatures at least as good as the nonmalleable one 17:30 < andytoshi> actually hmm 17:30 < sanket1729_> after psbt hash preimages? 17:30 < andytoshi> eh, we could write a fuzztest now 17:30 < sanket1729_> It may fail often 17:30 < sanket1729_> but yeah 17:31 < andytoshi> it is interesting to consider that maybe the malleable signer will produce more compact signatures in some cases 17:31 < andytoshi> or maybe in all cases that it's able to make different decisions 17:32 < andytoshi> this certainly is a dangerous function ... it produces smaller witnesses which can be malleated into larger ones. so you think you're improving your fee properties but actually you're worsening them 17:33 < sanket1729_> true 17:33 < sipa> i believe that for "nonmalleable" miniscripts any non-malleable satisfaction will be the smallest among all satisfactions for the same set of conditions 17:34 < sipa> but that would be a good property to check 17:34 < sanket1729_> I don't think that is true. 17:34 < sipa> i'm curious about a counterexample then 17:35 < sanket1729_> because, for example hash or(hash,time) we satisfy hash over time. 17:35 < andytoshi> "nonmalleable" means everywhere locally nonmalleable 17:35 < sanket1729_> because hashes are weak and time is strong(covered by nlocktime signed by signature) 17:35 < andytoshi> lol "hashes are weak but time is strong" is pretty metal 17:36 < sanket1729_> that is strange consequence of our assumptiosn 17:36 < sipa> or(hash,time) is always malleable 17:36 < sipa> so that can't occur 17:37 < sipa> neither has "s" property, so an or over them can't be nonmalleable 17:37 < andytoshi> well, if the locktime is set so that the time branch is invalid, it's ok, but then there's only one choice for either the mal-signer or the nonmal-signer 17:37 < sanket1729_> and(pk,or(hash,time)), out typesystem does not detect it currently but the satisfaction with sig and preimage is non-mall 17:37 < sipa> sanket1729_: wut? 17:38 < sipa> all or_x fragments require that at least one of its arguments has the "s" property for non-malleability 17:38 < sanket1729_> hash and time as non-s afaik 17:38 < sipa> and hash and time are both non-s 17:38 < andytoshi> sipa: it's non-malleable in real life, even though it's "malleable" according to the miniscript type system 17:39 < andytoshi> assuming that the tx locktime prevents the time branch frome being taken 17:39 < sanket1729_> yep 17:39 < sipa> ah, i see 17:39 < sipa> sorry, i misread 17:39 < andytoshi> but. i don't see this as a counterexample to the non-malleable signer being best 17:39 < andytoshi> if the locktime can't be satisfied, there is no choice about what branch to take 17:39 < andytoshi> and if it -can- be satisfied, then the typesystem is correct 17:40 < sipa> right, in some cases this may be satisfied in a non-malleable way, but if you just have the miniscript (and not yet knowledge about nlocktime or revealed hashes), then it should be treated as malleable 17:40 < sipa> so my claim is only about miniscripts that are non-malleable in general, according to the current type system 17:40 < sanket1729_> This is under the assumption that non-s satisfactions are cheaper than the `s` ones which I don't think is necessarily true 17:40 < sanket1729_> I can try to come with counter exmaple 17:41 < sipa> sanket1729_: hmm, interesting 17:41 < andytoshi> i'm also curious if there's a counter-example to "the malleable signer can't come up with a witness which, after it has been malleated, is still smaller than what the nonmalleable signer would've done" 17:41 < andytoshi> for arbitrary (potentially malleable miniscripts 17:42 < andytoshi> and assuming, i guess, that the nonmalleable signer would've succeeded at all 17:42 < sipa> sanket1729_: i believe you may be right 17:42 < sipa> by having a choice between a big non-s branch and a small s branch 17:43 < sanket1729_> or(thresh(10,hash....),pk) 17:43 < sipa> yeah 17:44 < andytoshi> i think we can make our nonmalleable signer reason correctly in the case that the big non-s branch is impossibel due to timelocks 17:45 < andytoshi> and i if the big non-s branch -is- possible ... then sure, the malleable signer will produce a small witness, but a network attacker can maybe turn it into something that the nonmalleabel signer would've done 17:45 < andytoshi> or worse 17:45 < sanket1729_> I think that is true. 17:45 < andytoshi> i think the malleable signer should try to return an upper bound as to how badly its return-value might get malleated 17:46 < andytoshi> though then we might have to think about noncanonical things >.< 17:46 < sipa> andytoshi: my satisfier already does this 17:46 < sanket1729_> an attacker can always convert a malleable to non-malleable solution. 17:46 < andytoshi> sipa: you have a malleabel satisfier? 17:46 < sipa> andytoshi: no, i mean this: 17:47 < sipa> 17:44:32 < andytoshi> i think we can make our nonmalleable signer reason correctly in the case that the big non-s branch is impossibel due to timelocks 17:47 < andytoshi> ah! 17:47 < sipa> oh, i have a malleable satisfier too 17:47 < andytoshi> nice. have you thought about how hard it'd be for the malleable satisfier to try to upper-bound the size of malleations of its witness? 17:48 < andytoshi> it might be trivial but it might be super hard, and it's not obvious to me which.. 17:48 < sipa> if you're concerned about that i think you should use nonmalleable satisfactions... 17:48 < sanket1729_> > i think we can make our nonmalleable signer reason correctly in the case that the big non-s branch is impossibel due to timelocks. 17:48 < sanket1729_> The new PR does this 17:49 < andytoshi> sanket1729_: oh awesome 17:49 < andytoshi> sipa: lol that's fair 17:49 < sanket1729_> I think an attacker can always convert a malleable signer solution to non-malleable signer solution. So, there is light bound 17:49 < andytoshi> though i suppose it's possible that somebody sends you a descriptor with coins on it, which you have the keys for but which is malleable 17:49 < andytoshi> and you're forced to choose between losing the coins and obeying your morals 17:50 < sipa> andytoshi: obviously you should sign, but you shouldn't worry about how big things can get 17:50 < sipa> it's too late to even bother reasoning about that 17:50 < andytoshi> i mean, you have to set the fee to -something- 17:50 < andytoshi> worst case you can look at the max number of stack entries your script will take and multiply that by 520 17:51 < sipa> if you know what set of conditions is satisfied you can compute the size of the malleable satisfaction exactly 17:51 < sipa> it's only in multisig-we-dont-know-who-will-be-present situations that you don't know this, i think 17:51 < andytoshi> yes but a malleator might change the set of conditions, in this hypothetical 17:52 < andytoshi> he gives you and(pk,or(true,thresh(10,hash,hash,hash,...)))) 17:52 < sipa> you mean non-third-party malleation? 17:52 < sipa> as in malleable by one of the signers? 17:52 < andytoshi> no, i mean third-party 17:52 < sipa> third parties shouldn't be able to change the conditions 17:52 < andytoshi> yes but in this hypothetical they can 17:53 < andytoshi> in the script i posted 17:53 < andytoshi> they can change the `true` condition to the one where youh vae to provide 10 hash preimages 17:54 < sipa> by "conditions" i meant "the set of available private keys, the set of known hash preimages, the timelocks implied by nlocktime/nsequence values" 17:54 < andytoshi> ah yes 17:54 < andytoshi> sorry, i meant "conditions" like "branches" 17:54 < andytoshi> 01:51 < sipa> if you know what set of conditions is satisfied you can compute the size of the malleable satisfaction exactly 17:54 < andytoshi> this is what i'm asking ... i'm not sure if you know the -worst-case- size 17:54 < andytoshi> without needing to take non-canonical things into account 17:55 < sipa> ah, i see 17:55 < sanket1729_> Yes, we would need non-cannonical things then 17:55 < andytoshi> barf 17:55 < sipa> you're talking about a malleator making things bigger to interfere with relay 17:55 < sanket1729_> The malleator would satisfy both children of or_b 17:55 < andytoshi> i think then it's not worth doing, we should just say "you're on your own" if someone is using malleable csripts 17:55 < andytoshi> sipa: yeah 17:55 < sipa> andytoshi: yeah, that 17:55 < sipa> signing malleable scripts is already a weird recovery-like scenario 17:56 < sipa> so what if it doesn't relay? retry later 17:56 < andytoshi> and when someone shows up here with "somebody took one of my keys and put a million bitcoins on and(pk,or(true,thresh(10,hash,hash,hash,...)))), how do i set my feerate?" 17:56 < andytoshi> we can revisit 17:56 < sanket1729_> andytoshi: lol 17:56 < andytoshi> yeah good point "retry later" 17:57 < sanket1729_> andytoshi: Why should signatures by unavailable vs impossible? 17:58 < andytoshi> sanket1729_: i think i'm confusing counterparty and 3rd-party malleability again 17:58 < andytoshi> but my thinking is 17:58 < andytoshi> "impossible" should mean "there's a timelock in here that can't be satisfied because the locktime is set wrong" 17:58 < andytoshi> and everything else should just be "unavailable", under the assumption that somebody might come along and use the branch 17:59 < andytoshi> but i see...if we restrict to 3rd-party malleators, then a missing sig is "impossible" 17:59 < sanket1729_> btw, I just realized a flaw in our algorithm. We cannot selectively satisfy some locktimes and no satisfy other locktimes afterall nlocktime is just a single number. 18:00 < andytoshi> i think our algorithm takes the locktime as given? 18:00 < andytoshi> at least, all our Satisfier impls always use a fixed locktime. i hope 18:00 < sanket1729_> Yep, but the current implementation in the PR is wrong I think 18:00 < andytoshi> so the result of satisfying a timelock should always be either Witness::Impossible or a weak empty stack 18:01 < andytoshi> ah kk 18:01 < sipa> without knowing nlocktime/nsequence you can't construct valid signatures anyway 18:01 < sanket1729_> because it assumes timelock as Impossible without checking the nlocktine 18:01 < andytoshi> good point sipa 18:01 < sipa> so there isn't much risk in reasoning incorrect about these 18:01 < andytoshi> sanket1729_: i think you're right that missing sigs should be "Witness::Impossible" 18:02 < andytoshi> it just feels a bit weird to me, "impossible" seems too strong a word 18:06 < sipa> "Unavailable" ? 18:06 < andytoshi> sipa: these are the terms we're using to distinguish between witnesses that a 3rd party might produce but we can't (for whatever reason) 18:07 < andytoshi> e.g. hash preimages that we don't have the preimage to 18:07 < sipa> yeah, i was suggesting a better term :) 18:07 < andytoshi> oh lol 18:07 < andytoshi> so, we're using Unavailable for that...and Impossible for things like timelocks where the locktime invalidates it 18:08 < andytoshi> and the question is, under what category does pk() fall if you don't have the key 18:08 < sipa> ah, why the need to distinguish? 18:08 < andytoshi> to do the right thing w.r.t. nonmalleable signing, when you have branches with timelocks 18:08 < andytoshi> which would be malleable, if the locktime were high enough 18:08 < andytoshi> but in some cases are not, and we can sign more smartly 18:09 < sipa> at signing time you always need to know the nLockTime 18:09 < andytoshi> yes 18:09 < sipa> so either it's available, or it isn't 18:09 < andytoshi> consider the example sanket posted above: and(pk,or(hash,time)) 18:09 < andytoshi> if the timelock can be taken, then we should refuse to sign this 18:09 < andytoshi> but if it can't be taken, we should take the hash branch 18:10 < sipa> yes 18:10 < sipa> either you have two non-sig branches under the or, which is invalid for a non-malleable signer 18:10 < andytoshi> contrast to and(pk,or(hash,hash)) 18:10 < andytoshi> which we should never sign under any circumstances 18:10 < sipa> or you have just one (because the time conflicts with the locktime) and all is good 18:11 < andytoshi> so, we need to distinguish between "the right branch is a timelock that's impossible to satisfy, we're good" and "the right branch is a hash preimage that we happen not to know the preimage for, but maybe somebody does" 18:12 < sipa> somebody being another signer? 18:12 < sipa> if they do, you should have it at signing time 18:12 < sipa> if they don't, nobody is assumed to know it 18:12 < andytoshi> that doesn't make sense though 18:12 < andytoshi> in a HTLC there's always somebody who knows the hash preimage initially 18:13 < andytoshi> there's never a case when literally nobody knows a hash preimage 18:13 < sipa> right, of course 18:13 < andytoshi> and regardless, even if you "should" have it, if you don't have it, and you call the satisfy function, it should do something safe 18:14 < andytoshi> i think, our assumption is that "if i know a hash preimage then everyone does" rather than "if i don't know a hash preimage then nobody does" 18:14 < andytoshi> or actually our assumption might be "somebody knows a hash preimage" .. i think this is what we mean, algorithmically, by "weak" 18:15 < andytoshi> i.e. regardless of our own knowledge we assume hash preimage branches can be taken by a 3rd party 18:15 < sipa> right the stated assumption is "the attacker only has access to hash preimages that honest users have access to as well" 18:15 < sipa> (attacker in the context of malleability, so a third party) 18:15 < sipa> but that does not imply that one honest participant knowing a hash preimage means that all honest participants do 18:16 < sipa> (and the one that knows may not be participating) 18:16 < andytoshi> yeah .. it's also not really possible to implement in practice. if you're "supposed" to have a preimage but for some reason you don't, our algorithms have to do something 18:16 < andytoshi> and i think, what we've encoded in the word "weak", is something simpler 18:16 < andytoshi> which is just "an attacker hash access to all hash preimages" 18:17 < andytoshi> s/hash/has/ :- 18:17 < andytoshi> ) 18:18 < sipa> can we just fast-forward to a taproot world where all hash based scripts are replaced with adaptor sigs? 18:18 < sipa> (not sure that actually fundamentally makes any of this reasoning easier though...) 18:19 < andytoshi> heh it would be nice 18:19 < andytoshi> on both counts 18:25 < sanket1729_> updated the PRs 18:25 < sanket1729_> PR 18:26 < andytoshi> thanks. though i might be nearly done work for the day. or at lesat for a few hours 18:28 < andytoshi> lol sanket1729_ i only see one commit 18:29 < andytoshi> oh weird github is doing something funky 18:29 < andytoshi> oh, no, it just looks ilke you pushed the wrong thing 18:54 < sanket1729_> andytoshi: sorry 18:54 < sanket1729_> updated 20:32 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 20:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript