--- Log opened Tue Jun 15 00:00:38 2021
09:32 < andytoshi> sanket1729: thresh_m_tr() ?
09:32 < andytoshi> for a fragment that uses CHECKSIGADD
09:34 <@sipa> i was thinking thresh_a
09:34 < andytoshi> oo i like that too
09:34 < andytoshi> it's nice that it's the same length
09:34 <@sipa> (in that it's a tresh using adds; in the long term it may not be taproot specific, if a successor happens and CHECKSIGADD also exists there)
09:34 <@sipa> thresh
09:35 <@sipa> no real strong opinion though
09:50 < michaelfolkson> Now this darosior PR has been merged and thresh has been relaxed to include n-of-n when would one use thresh() and when would one use multi() for a n-of-n? Does it matter? If not why do we need multi() anymore?
09:50 < michaelfolkson> https://github.com/sipa/miniscript/pull/55
09:50 <@sipa> you're confusing the policy language with miniscript
09:51 < michaelfolkson> Aha thanks, will revisit
09:51 <@sipa> the newly added n-of-n and 1-of-n multi miniscripts will likely never be used
09:51 <@sipa> they're always inferion to constructions using and or or
09:51 <@sipa> (we think)
09:54 <@sanket1729> About storing timelock info as type information vs struct
09:54 <@sanket1729> sipa: What do you think about https://github.com/sipa/miniscript/pull/41#discussion_r585298649?
09:58 <@sipa> sanket1729: is the situation different from malleability?
10:01 <@sanket1729> Actually it is not. I think I should add those as type information then
10:02 <@sipa> yeah i think it's very similar
10:06 <@sanket1729> now, I think I have to come up letters for representing different timelock combinations _mst operator. Any suggestions?
10:38 <@sanket1729> andytoshi: Come of think of it, we should also represent timelock information in rust-miniscript debug information. How about using consecutive characters g,h,i,j,k ?
13:51 < andytoshi> lol, yeah, that's okay with me
13:51 < andytoshi> i think this "single letter" type system has outgrown its readability but i don't have any other suggestions
13:57 <@sipa> it's not something end users should see anyway
13:57 <@sipa> but, sure
16:00 <@sipa> andytoshi: we renamed thresh_m to multi, so multi_a?
16:00 < andytoshi> oh right
16:00 < andytoshi> sounds good to me
16:01 < andytoshi> and yeah, agreed users shouldn't ever see the type system, so i don't feel too strongly about it
16:01 < andytoshi> but it kinda feels like something that was designed in the 90s :)
16:01 < andytoshi> all these inscrutable single-letter codes
16:04 <@sipa> you're giving the 90s way too little credit
16:04 <@sipa> Java was designed in 1995 FFS
16:04 <@sipa> this feels more like a '60 thing
16:05 -!- roconnor [~roconnor@host-184-164-16-124.dyn.295.ca] has joined ##miniscript
16:05 -!- mode/##miniscript [+o andytoshi] by sipa
16:05 < roconnor> oh people have ops.
16:06 <@sipa> indeed, andytoshi prayed to the Gods of Libera, and his wishes were granted
16:06 < roconnor> that's impressive.
16:07 <@sipa> andytoshi: i'm ok with inventing a more readable type system notation and using that on website/debug output etc
16:07 <@sipa> roconnor: context:
16:08 <@sipa> 16:01:20 < andytoshi> and yeah, agreed users shouldn't ever see the type system, so i don't feel too strongly about it
16:08 <@sipa> 16:01:27 < andytoshi> but it kinda feels like something that was designed in the 90s :)
16:08 <@sipa> 16:01:41 < andytoshi> all these inscrutable single-letter codes
16:08 <@sipa> 16:04:28 <@sipa> you're giving the 90s way too little credit
16:08 <@sipa> 16:04:42 <@sipa> Java was designed in 1995 FFS
16:08 <@sipa> 16:04:50 <@sipa> this feels more like a '60 thing
16:09 <@andytoshi> so, the specific thing i had in mind was gdb ... which according to wikipedia was created in 1986, but i imagine it was inspired by something that already existed..
16:09 <@andytoshi> ah "DBX" from 1981
16:18 <@sipa> hmm, what should the maximum number of keys in a multi_a be?
16:23 <@sipa> i believe that 4038 is the largest that could fit in a 1-input 1-output 400000 WU transaction
16:56 <@sipa> maybe we want a separate multi_v (?) that does the "pk1 OP_CHECKSIGVERIFY pk2 OP_CHECKSIGVERIFY ... pk(n-2) OP_CHECKSIGVERIFY pk(n-1) OP_CHECKSIG" pattern, distinct from multi_a?
16:56 <@sipa> or do we want multi_a to automatically use that pattern when k==n ?
17:02 <@sipa> such a multi_v may be useful outside of tr as well, as it's not restricted to 20 keys
17:16 <@andytoshi> i like multi_v as a separate fragment
17:16 <@andytoshi> i don't think multi_a should do it automatically
17:16 <@andytoshi> though the compiler shuold be smart enough to choose the right on
17:16 <@andytoshi> i think the multi_v may already exist as a series of and_vs
17:17 <@sipa> right, in miniscript it does
17:18 <@sipa> i'm just writing this as a stand-alone descriptor thing for bitcoin core now
17:18 <@sipa> so i'm just going to only have multi_a
17:20 <@sipa> which does make me wonder if we shouldn't still have a multi_v that's just a shorthand for and_v(v:pk(A),and_v(v:pk(B),...pk(C))..))
--- Log closed Wed Jun 16 00:00:39 2021