--- Log opened Mon Jun 28 00:00:51 2021 01:55 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:992:7ee3:6f49:438] has joined ##miniscript 02:04 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:992:7ee3:6f49:438] has quit [Quit: I am away from my computer] 05:33 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 06:49 -!- meshcollider [meshcollid@user/meshcollider] has quit [Quit: :wave:] 06:54 -!- roconnor_ is now known as roconnor 06:56 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 07:05 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript 07:10 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 07:19 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 07:34 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 08:37 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 08:57 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 09:30 <@sipa> achow101: regarding the taproot psbt BIP: i found it surprising that the script tree is a map from control block to scripts, rather than the other way around (as what a signer needs is kind of the opposite)... it has benefits though, like permitting duplicate scripts to be represented naturally 09:30 <@sipa> is that the reason for doing it that way? 09:30 < achow101> sipa: yes. the parser can flip it back the other way. we do this trick for the global xpub field too. 09:35 <@sipa> you may want to add that PSBT_IN_TAP_LEAF_SCRIPT is only needed for the leaves that a signer is expected to be able to sign with (and isn't necessarily the entire tree, though that may interfere with the ability to introspect the semantics) 09:37 < achow101> I think andytoshi and sanket1729 have some comments on the (in)ability to introspect the entire tree. 09:38 <@sipa> if the expectation is going to be that the entire tree needs to be included in the PSBT, then we should use a different encoding - this one is super inefficient for large trees 09:38 <@andytoshi> sipa: i had that expectation ... but on further thought i don't think it's reasonable 09:38 <@andytoshi> you might sanely have a tree that has millions of branches 09:38 <@andytoshi> and then no matter what encoding you use 09:38 <@sipa> i don't think it's reasonable, and i don't think it's useful either, actually 09:38 <@sipa> PSBT is for signing, not for analyzing scripts 09:39 <@sipa> you should analyze the script before deciding to participate in it, not at signing time 09:39 <@andytoshi> true, but a year or so ago we were talking about PSBT as being a sort of descriptor encoding 09:39 <@andytoshi> and descriptors should have the whole tree 09:39 <@sipa> oh, i realized that doesn't work, because it lacks key derivation information 09:39 <@andytoshi> ah yeah good point 09:39 <@sipa> PSBT key derivation is for individual keys, not generic 09:40 <@andytoshi> right 09:40 <@andytoshi> ok, so i think i'm ok with this then.. 09:40 < achow101> sipa: with the PSBT_GLOBAL_XPUB, it can be generic 09:40 <@andytoshi> though sanket1729 also raised the point on a blockstream call that even if you don't expect to have the whole tree, you probably do want the ability to merge merkle paths somehow 09:40 <@andytoshi> for efficiency 09:41 <@andytoshi> achow101: i'm not sure i understand. can you encode a ranged descriptor with PSBT_GLOBAL_XPUB ? 09:41 <@andytoshi> do you need to put every key in the range, into the map? 09:42 < achow101> andytoshi: with PSBT_GLOBAL_XPUB, it becomes possible to infer the ranged descriptor. The xpub provided is a parent xpub with its key origin info. so given a child key and its key origin, you can infer which xpub is its parent by prefix matching the key origin 09:42 <@sipa> you can't actually 09:43 <@sipa> because you don't know the key in the descriptor was ranged or not 09:43 <@sipa> +whether 09:43 <@sipa> but it's pretty close indeed 09:44 < achow101> oh right 09:44 <@sipa> andytoshi: so even if we want to go in the direction of PSBT-as-binary-descriptor encoding, i do expect it'll have some peculiarities (at the very least... it can't contain signatures etc), so in that case, it could also add a "taproot tree must be complete" requirement in that context 09:45 <@andytoshi> sipa: yeah that makes sense to me 09:45 <@sipa> (i'm also not entirely convinced there is no need for not having the ability to specify hidden subtrees in descriptors actually - they obviously lose analyzability, but there may be reasonable use cases where that isn't an issue, and either privacy or performance reasons benefit from having hidden subtrees) 09:47 <@andytoshi> heh roconnor has been making that argument (and i suspcet he plans to write a ML post or something abuot it soon.>) 09:48 <@andytoshi> i think it might break APIs in rust-miniscript, or at least add a bunch more error paths where there currently aren't any 09:48 <@andytoshi> but i may be wrong about that, there is much left in rust-miniscript that is infallible 09:48 <@andytoshi> isn't much left* 09:49 < roconnor> andytoshi: wants me to write a mailing post, but I don't plan to. I thought it was always part of the tr descriptor plans, though rereviewing the github suggests that I may have been imagining those explicit plans. 09:49 <@sipa> yeah, i can see that; so far the descriptors in Bitcoin Core have had the distinction between fully analyzable ("IsSolvable"), and completely opaque (raw() and addr() descriptors, which are kind of second-class citizens) 09:49 <@sipa> and iirc rust-miniscript never supported the latter, which isn't unreasonable 09:49 <@andytoshi> rust-miniscript (so far) has entirely avoided supporting the opaque ones 09:49 <@andytoshi> yeah 09:49 <@sipa> but with tr it does become perhaps reasonable to support partially-analyzable ones 09:50 <@andytoshi> yeah i think so 09:50 <@andytoshi> certainly it would be good to have some sort of descriptor-like structure that you could pull out of the blockchain 09:50 <@sipa> roconnor: i think i always thought of that as a possibility that never was decided one 09:50 <@sipa> *on 09:50 <@andytoshi> which currently is "a complete descriptor except all the keys are concretized" 09:51 < roconnor> hidden branches is conceptually no different from hidden inner key. 09:51 <@andytoshi> hmmm that's an interesting observation 09:51 < roconnor> hidden inner key is simply the taproot-optimized version of a hidden branch. 09:53 < roconnor> for example, being a musig part owner of a taproot key doesn't imply control of the funds if the hidden inner key isn't known (to be a NUMS point or whatever). 09:53 <@andytoshi> true -- though we view that as an explicit security footgun and bip341 advises that you always make the hidden script be OP_RETURN if you aren't using it 09:54 <@andytoshi> (you can't make the inner key be NUMS without the outer key also being unspendable) 09:54 <@andytoshi> heh oh, and if miniscript doesn't support "0" as a script then this is as good a reason as any 09:54 <@andytoshi> to null out taproot paths 09:56 <@sipa> andytoshi: that's not actually what BIP341 says 09:56 <@sipa> (but it's morally equivalent) 09:56 <@sipa> it says tweaking as: Q = P + H_TapTweak(P)*G if the script tree is empty 09:56 <@sipa> as opposed to Q = P + H_TapTweak(P || merkle_root)*G 09:58 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 09:58 <@andytoshi> oh. i'm surprised i didn't know that, i had thought that i'd read through all of bip341 by now 09:59 * andytoshi shame 10:15 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 10:17 <@sanket1729> So, taproot psbt the participants need to communicate previously on what scriptPath they are taking to sign the transaction. 10:17 <@sanket1729> I was thinking it would be useful to collect as many signatures as possible, and see if you can do the key path and try all script paths to find the most efficient one 10:18 <@sipa> i think for nearly all PSBT uses, the number of scripts is going to be small enough that doing so isn't really a problem 10:21 <@sanket1729> Let's in a malicious counterparty psbt setting, attacker could reduce the feerate of transaction by broadcasting other branch. In the current psbt segwit specification, we can do the wosrt case fee estimate, but with taproot psbt we are losing that 10:23 <@sanket1729> Maybe we can request the entire complete descriptor as external data 10:25 <@sipa> or just refuse to sign when the data isn't present? 10:25 <@sipa> signers aren't obligated to sign when they don't have enough information to ascertain their criteria are met 10:25 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 10:28 <@sanket1729> Yes, makes sense. So, are we updating the BIP 1) to include a tree like structure in per input? Or 2) using the current proposal to provide multiple paths or 3) Recommend users that want the tree to provide the descriptor data as additional data that is not covered in psbt 10:29 <@sipa> my vote is for (2) 10:29 <@sipa> it's the simplest for unsophisticated signers 10:30 <@sipa> go over the scripts, see what you can sign, and construct an output by concatenating witness + control block + script, the latter two coming directly from the PSBT fields 10:30 < achow101> are we anticipating that few updaters will provide all leaf scripts? 10:30 <@sipa> (and, due to the commitment structure, I believe this is even perfectly safe, even without verifying that the PSBT data matches the output) 10:32 <@sipa> achow101: maybe turn it around - i think anything working with descriptors (at least without wildly different additions to it than what exists) just isn't going to be able to work with giant trees in the first place 10:33 <@sipa> and if we're talking about things with maybe up to 10 branches, i don't think it all matters very much 10:35 <@sanket1729> If we go for 2) the current mapping is control-path -> leaf_version. I guess the expectation that witness_script field would contain the relevant script 10:36 < achow101> sipa: but if we are expecting full trees, I would rather that we have a tree field 10:36 <@sipa> it's control_block -> {script, leaf_version} 10:36 < achow101> sanket1729: it's leaf_version + script 10:36 <@sanket1729> sorry 10:36 <@sipa> sanket1729: the witness_script field is for P2WSH 10:36 <@sanket1729> Sorry, I misread 10:37 <@sipa> achow101: i think that'll make it a lot more complex for signers 10:37 <@sanket1729> It's optional right? 10:37 <@sipa> certainly encoding both the full tree and individual leafs is even worse than just either of them! 10:37 <@sipa> (in terms of encoding size...) 10:39 <@sipa> you can make everything optional, but it may create incompatibilities; e.g. signer X only looks at the full-tree field, updater Y only creates individual-leafs fields 10:39 <@sipa> so now if you want to create compatible software on either side, it really has to store/support both 10:40 <@sipa> so i'm strongly in favor of just having one of the two 10:41 < achow101> agreed 10:41 <@sipa> and have a mild preference for individual leafs, because optimizing for the simple case makes sense here i think 10:42 < roconnor> isn't that a reason to go with solution (1) , a tree-like structure with a single leaf revealed is the same as a merkle branch, and as you add more leaves you get a somewhat optimized structure, and if you add all the leaves you get the full tree structure? 10:43 <@sipa> it's still more complicated to use, as signers need to decode the tree encoding 10:44 < roconnor> that is true. 10:44 <@sanket1729> I am leaning to 2) now, for simplicity reasons. Also agreed, that having two places to look for is not good idea 10:45 <@sanket1729> In the worst case for large n, that is log(n) times the space required? 10:45 < achow101> if signers are going to require full trees, I think it is reasonable to put the complexity burden on them as they are the ones asking for it 10:45 <@sipa> achow101: i think very few signers are going to require full trees 10:46 <@sipa> and those that do, will be more sophisticated ones 10:48 < achow101> ok.. 10:48 < achow101> will rust-miniscript be requiring full trees? 10:49 <@sipa> if we'd want a tree structure, i have found that using a list of (depth, script) tuples in DFS order isn't too hard to work with 10:49 <@sipa> so i'm also not opposed to that 10:49 < achow101> indeed, we do that (optionally) for outputs 10:53 <@sanket1729> It can work without full trees, for some features like worst case fee estimation will fail now because of hidden nodes. I think we will end up providing additional API that allows taking in a complete descriptor 10:53 <@sipa> sanket1729: actually, i don't think this is a problem 10:53 <@sipa> because the signatures commit to the leaf hash 10:54 <@sipa> so they aren't malleable across 10:56 <@sanket1729> This is about the case where the counter party has signing power. or(path1, path2) I sign path1, but path2 with low fee rate is broadcasted first. Ideally while signing with path1, I want to sign such that `path2` could also be confirmed 10:56 < achow101> At worst they could still use a duplicate leaf script that has a larger control block 10:59 <@sanket1729> where path1 and path2 are two different leafs. In settings like atomic swaps(non-trusted counter party), delaying a conformation can also be security issue. 10:59 <@sipa> sanket1729: so what? the leaves are independent, so you signing or not has no impact on the ability for other parties to broadcast a spend with leaves you don't know about 10:59 < roconnor> sipa: since leaf hashes are repeatable (TIL) I can create a taproot with the same leaf repeated at a much deeper depth, and malliate your signature onto the deeper version? 11:00 <@sipa> roconnor: ugh, yes 11:00 < roconnor> I'd like to propose an ammendment to taproot ... 11:00 <@sipa> though you shouldn't have agreed to participate in such a scheme in the first place 11:01 < roconnor> I don't know. Normally speaking if I script says I can get access to funds after a specific time-lock, do I really care about the other branches? 11:02 < roconnor> I don't know. I don't really have a well thought out idea here. I'll have to look at my notes to see if I have a concrete scenario. 11:02 <@sipa> yeah, i regret not committing to the depth of a leaf now 11:04 < roconnor> I falsely beleive that the canonical order of branches somehow made leaves non-repeatable (or at worst identical). 11:05 <@sipa> we could propose an annex that says "spend only valid if leaf depth is X" 11:05 < roconnor> not a terrible idea. I think we had some general ideas regarding a max-weight annex item. 11:06 < roconnor> that would maybe be more robust. 11:06 <@sipa> right, that's even better, and subsumes this 11:06 < roconnor> probably something we want anyways. 11:16 < roconnor> I guess we are stuck with general witness malleability for repeated scripts at the same depth? 11:19 <@sipa> could have an annex that commits to the entire branch, but at annoyingly high cost 11:20 < roconnor> probably better to use a different pubkey version at that point. 11:21 <@sipa> in general i think concerns about malleability are something that matters at analysis time 11:21 <@sipa> at signing time, you really don't care about malleability anymore - you just want your money 11:23 <@sipa> but it is a downside that this now another complexity pushed onto such a malleability-analyzer 11:34 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 11:59 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 12:03 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 12:09 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 12:21 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has quit [Quit: I am away from my computer] 12:36 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 12:39 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 12:44 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 272 seconds] 12:57 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 13:01 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has joined ##miniscript 13:01 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] 13:31 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 13:32 -!- michaelfolkson2 [~michael@2a00:23c7:6080:9301:f025:227d:3e76:811c] has left ##miniscript [Textual IRC Client: www.textualapp.com] 13:35 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds] 13:43 < roconnor> what were the malleability preconditions for miniscript? That pubkeys are not reused in the expression? 13:48 <@sipa> yeah; the analysis can't deal with that 13:51 < achow101> why doesn't the sighash commit to the depth? 13:52 <@sipa> i think the answer is just nobody thought of that 14:01 <@andytoshi> yeah, i think we talked about committing to weight (or max weight), decided that this would put too much complexity on the signer, then didn't really revisit that design space 14:06 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 14:10 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 258 seconds] 14:17 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 16:02 -!- jeremyr__ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 16:02 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Read error: Connection reset by peer] 16:28 -!- jeremyr__ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 16:29 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 16:56 -!- andytoshi [~apoelstra@s66-183-0-205.bc.hsia.telus.net] has quit [Ping timeout: 244 seconds] 16:56 -!- andytoshi [~apoelstra@s66-183-0-205.bc.hsia.telus.net] has joined ##miniscript 17:22 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 17:24 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 17:28 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] 17:44 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 18:49 <@sanket1729> I really like the idea of committing to max weight. Seems like a clean way to solve witness malleability problem. We don't actually care about malleability, we only care the tx gets confirmed 18:50 <@sanket1729> Can it not be optional, so only signers that want to have this guarantee(in case of malicious counter parties) can use it 18:59 <@sanket1729> > if I script says I can get access to funds after a specific time-lock, do I really care about the other branches 19:00 <@sipa> i don't see how it could be anything but optional 19:00 <@sipa> given that it doesn't exist 19:00 <@sanket1729> roconnor: I think you do, because right around the time you are about to broadcast your transaction, the other party can create a tx with another satisfaction. In general, I think it is good to know all descriptors 19:01 <@sanket1729> I don't see how this is different than other party simple having another deep leaf 19:01 <@sipa> but will this affect your actions at signing time? 19:01 <@sipa> if the only way of getting your funds out is through a malleable spend, you're not going to refrain from using it 19:02 <@sanket1729> Yes, my bad 19:02 <@sanket1729> I got confused 19:02 <@sanket1729> > because the signatures commit to the leaf hash 19:02 <@sanket1729> duh, 19:02 <@sipa> even if that wasn't the case 19:02 <@sipa> if the only way of getting your funds out is through something suboptimal, you're still going to get your funds out 19:03 <@sipa> my point is that malleability matters at generator/setup/analysis time, not at signing time 19:04 <@sipa> so what if it may be malleated and confirms slowly - if you don't sign you're not getting your money at all 19:04 <@sanket1729> understood. 19:08 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 19:15 <@sanket1729> Agreed, it won't affect signing time actions. At setup time, should one always have to look at the entire taptree output, so this is a non-issue in practise? 19:19 <@sanket1729> In all cases, you want to look at output taptree. If you are not looking at hidden branches, you are assuming you don't have the funds anyways. 19:23 <@sipa> in some cases i can imagine this is fine 19:24 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 19:24 <@sipa> e.g. if you're ok with participating in a 1-of-N setup now, you perhaps also don't care about participating in a scheme where you know you have the ability to spend unilaterally, but don't know what other spending conditions exist 19:24 <@sipa> s/don't care about/don't mind to' 19:29 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 258 seconds] 19:38 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 19:45 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 272 seconds] 19:58 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 20:06 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] 20:35 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 20:56 -!- jeremyr__ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 20:56 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Read error: Connection reset by peer] 21:00 -!- jeremyr__ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 21:12 < roconnor> the affect of malleability at signing time has to do with selecting fees. 21:12 < roconnor> *effect 21:13 < roconnor> I mean, potentially. 21:17 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 21:21 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] 21:51 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 21:55 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 258 seconds] 22:20 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 22:25 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 258 seconds] 22:55 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 23:00 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds] 23:13 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined ##miniscript 23:31 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] --- Log closed Tue Jun 29 00:00:51 2021