--- Log opened Thu Sep 30 00:00:22 2021
09:11 < darosior> We should probably update doc/descriptors.md with information about Miniscript. Do you think a link to the website woul be sufficient?
09:11 <@sipa> darosior: "k" should be IsSane, yes
09:12 < darosior> Yeah it's what ended up being merged :p
09:15 <@sipa> oh, good
09:15 <@sipa> :p
10:39 < sanket1729> darosior: I am okay with #77, but I think we have some misunderstanding that can be resolved in the future.
10:40 < darosior> Happy to chaty
10:40 < darosior> chat*
10:41 < darosior> I think so too
10:43 -!- jnewbery_ [~john@user/jnewbery] has joined ##miniscript
10:44 -!- jnewbery [~john@user/jnewbery] has quit [Ping timeout: 265 seconds]
10:48 < sanket1729> Even if witness script is a stack element, I think Miniscript.GetStackSize() should not have it because it assumes miniscript is in segwitv0. 
10:48 < sanket1729> One day we would have a Descriptor.GetStackSize() (like the rust impl) that would do the +1. As for the check, the policy rule size check explicitly removes the witness script element. So, I don't see a special reason to do add it.
10:49 < darosior> All the codebase (including the other checks) assume segwitv0, why would it be important for this check to not assume it?
10:49 < sanket1729> Because it has applications beyond checking
10:49 < sanket1729> And it is easy to do
10:50 < darosior> "Because it has applications beyond checking" That's an answer to your own previous point
10:51 < sanket1729> I don't follow
10:51 < darosior> Scratch my last message. Sorry, i think i misread your sentence. 
10:51 < sanket1729> I mean GetStackSize() is of independent interest too
10:52 < darosior> So the argument is to have this very small part of the codebase not assume segwitv0 because it's easy to do? I say it's inconsistent and makes the logic harder to follow: better to have all checks in one place
10:53 < sanket1729> I am suggesting GetStackSize() should return size without the witness script. CheckStackSize() should assume segwitv0
10:56 < sanket1729> Only our checks should assume segwitv0. Other APIs should be independent on where the miniscript is used
10:57 < sanket1729> Again really minor. Okay keeping things as is
11:00 < darosior> But literally all APIs assume segwit v0, they would all need to be changed for v1
11:00 < sanket1729> Which ones?
11:02 < darosior> Wait do we have a spec for Taproot Miniscript? I expected the type system would change given the change in Script. If that's the case then Parse, Decode, ToString, ToScript, etc.. Everything would need to be refactored for v1
11:05 < sanket1729> we don't have a spec. That's why I think it's really minor and be discussed later. We would have new Terminals for `multi_a` and remove `multi`. Parse, Decode, ToString, ToScript would be updated for it.
11:12 < sanket1729> Anyways, I think it's left for future. And move forward on things. 
16:41 < sanket1729> sipa: I am considering the following API for rust-bitcoin which constructs a Taproot Tree from Vec<(depth, Script)>. I would sort this vec according to depth and keep on inserting elements in breadth first style(highest depth first). Do you see anything wrong with this?
16:41 < sanket1729> The advantage of this is that users don't have to care about specifying the exact tree stucture.
16:42 < sanket1729> The descriptor support would be as specified in output descriptors doc
16:43 < sanket1729> I am wondering if there is any advantage for users to re-arrange the tree if the depths are fixed
17:18 <@sipa> sanket1729: that's how the bitcoin core does it, if i understand you correctly
17:18 <@sipa> it has a DFS-ordered list of (depth, leaf)
17:18 <@sipa> oh, breadth first... is that unambiguous?
17:20 < sanket1729> Yes it is
17:21 < sanket1729> But not if we fix a construct it
17:21 < sanket1729> This is offering a programatic way to construct taproot tree
17:22 < sanket1729> The descriptor parsing etc would be as described in bitcoin core
17:23 <@sipa> i'm talking about internally in bitcoin core, not descriptors
17:23 <@sipa> in descriptors it's the {{,}{,}}} style nested notation
17:23 < sanket1729> Yes, but it requires the users to call the Add API in a specific way
17:24 <@sipa> but internally, that is converted to a flat list of (depth, leaf) nodes
17:24 < sanket1729> From reading the doc-comment it appears that Add must be called in Depth first order
17:25 <@sipa> that too
17:25 <@sipa> but that's not what i'm talking about
17:26 <@sipa> the internal representation for descriptors also uses this flat list representation
17:26 < sanket1729> I see, but the ordering in the flat list is important
17:26 <@sipa> yes, it matters
17:26 <@sipa> it affects the hash
17:28 < sanket1729> So, what I am suggesting is list where we sort the list(in the above way) to get the some Tree. Users don't have to think about specifying Depth first order etc
17:30 <@sipa> that's a reasonable way to design a tree, i think
17:30 <@sipa> but it can't represent everything
17:30 <@sipa> if you do exactly the same, but don't do the sorting, however you can
17:31 < sanket1729> Yes, my question is do we care about it in taproot application?
17:31 < sanket1729> If the depth of leafs are fixed and we permute the tree, does it matter?
17:32 <@sipa> it may, in advanced situations, where you want to selectively hide part of the tree
17:36 < sanket1729> Thanks, I will probably implement both APIs, a simpler easy to use API where users provide a list without any enforcement on ordering. And another one which has a precondition on dfs ordering for specifying exact tree.
17:38 <@sipa> i don't understand why you'd bother with the sorting
17:39 <@sipa> just don't do that, you lose no functionality, and the result can represent everything
17:40 <@sipa> or do it optionally; i guess it makes it easier to satisfy a valid DFS order
17:41 < sanket1729> I want external users to call TaprootTree::from(Vec<(depth, Script)>). And I don't want to burden them specifying DFS order
17:41 < sanket1729> Wait, is every vec<depth, script> a valid tree?
17:41 < sanket1729> assuming depths are valid
17:42 < sanket1729> that is they add 2**depth_tree
17:43 <@sipa> it's actually fairly simple to write a an algorithm that deterministically reorders a [(depth,leaf)] (sort which sum(2^-d for d in depths)=1) into a valid tree
17:44 <@sipa> so it depends on how you map lists to trees
17:46 < sanket1729> Is there a bijection between those all valid taptrees and [(depth, leaf)] (assuming sum(2^-d for d in depths = 1))?
17:47 <@sipa> no
17:47 <@sipa> there is only one between (depth,leaf) lists which correspond to a DFS walk of a huffman tree
17:48 <@sipa> but there is a simple algorithm that can reorder any walk of a huffman tree into a DFS ordered one
17:48 <@sipa> O(log n) memory, O(n) time
17:48 <@sipa> in such a way that if it's already DFS, it stays the same
18:04 < sanket1729> If I understand what you are saying. I did wanted some form of canonical ordering on the list for easier use of API to covert it into a valid tree, you are suggesting that there I should not have any ordering because it loses expression
18:08 < sanket1729> scratch all of that
18:08 < sanket1729> I think I get what you are saying now :)
18:39 <@sipa> if the caller doesn't care about ordering they can also sort themselves
23:56 -!- meshcollider [meshcollid@user/meshcollider] has quit [Remote host closed the connection]
--- Log closed Fri Oct 01 00:00:23 2021