--- Log opened Wed Jan 12 00:00:28 2022 08:54 <@sipa> Hmm, a bit of a dilemma around that PR. It only does the (CS CSA ... CSA NUMEQUAL) construction, but that is suboptimal for n-of-n multisig, where a (CSV ... CSV CS) would be slightly better. 08:56 <@sipa> The latter can already be represented in miniscript, but not in a convenient way (it needs deeply nested and_v). What do people think about either supporting and_v with more than 2 argument, or even having a shorthand multi_v(k1,k2,...,kn) = and_v(v:pk(k1),v:pk(k2),...,pk(kn)) ? 09:28 < andytoshi> sanket1729: maybe i'm being dumb but i don't understand the multi_a construction in your rust-miniscript PR 09:28 < andytoshi> it looks ilke CHECKSIG CHECKSIGADD ... CHECKSIGADD NUMEQUAL 09:28 < andytoshi> why is the first checksig not a checksigadd? 09:28 <@sipa> That would be unspendable. 09:29 < andytoshi> oh never mind i am an idiot 09:29 < andytoshi> checksigadd expects there to be an accumulator value, which on the first key there is not 09:30 < andytoshi> you could do 0 CHECKSIGADD CHECKSIGADD ..., and that would wokr 09:30 < andytoshi> but be pointlessly wasteful 09:31 < andytoshi> sipa: actually, worse than unspendable(?), i think it would be stealable 09:31 <@sipa> also, 1-of-n could be more efficiently written as CS CSA ... CSA 0NOTEQUAL. 09:31 <@sipa> Avoiding the push. 09:31 < andytoshi> oo neat 09:32 <@sipa> And n-of-n needs CSV CSV ... CSV CS, which is yet one opcode shorter. 09:32 < andytoshi> so, it would be a bit of a chore to add this to miniscript as we already have a n: modifier which suffixes 0NOTEQUAL 09:32 < andytoshi> and we'd need to distinguish that in the parer 09:32 <@sipa> Hmm. 09:33 < andytoshi> the n-of-n construction i believe is already part of miniscirpt 09:33 <@sipa> The parser is the least of my concern; just the proliferation of fragments needed to encode all this is worrisome. 09:33 < andytoshi> as and_v(and_v(...)) 09:33 < andytoshi> sipa: yeah, that's fair 09:33 < andytoshi> tbh i don't think 1-of-n is going to be a very common case for n>2 09:33 < andytoshi> and for n=2 i think our existing or constructions should be sufficient 09:33 < andytoshi> even without csa 09:34 <@sipa> andytoshi: Yes, please scroll up, I just talked about the and_v nesting. 09:34 < andytoshi> sipa: sorry, i think i got netsplit or something, i don't see anything from >12 hours ago 09:34 <@sipa> Hmm, a bit of a dilemma around that PR. It only does the (CS CSA ... CSA NUMEQUAL) construction, but that is suboptimal for n-of-n multisig, where a (CSV ... CSV CS) would be slightly better. 09:34 <@sipa> The latter can already be represented in miniscript, but not in a convenient way (it needs deeply nested and_v). What do people think about either supporting and_v with more than 2 argument, or even having a shorthand multi_v(k1,k2,...,kn) = and_v(v:pk(k1),v:pk(k2),...,pk(kn)) ? 09:34 < darosior> andytoshi: there are the logs at gnusha 09:35 < darosior> https://gnusha.org/miniscript/ 09:35 < andytoshi> thanks darosior 09:36 < andytoshi> sipa: concept ACK supporting n-ary and_v 09:36 < andytoshi> and maybe and_b as well 09:37 < andytoshi> and or_b 09:37 <@sipa> Making and_v n-ary would actually simplify the script parser, I think. 09:37 < andytoshi> i think we've avoided doing this in the past because we wanted to make everything n-ary, but that's basically an open research problem, or because it'd complicate the compiler if some binary fragments were n-ary and others were only 2-ary 09:38 < andytoshi> or something liek that 09:38 < andytoshi> sipa: i think you're right 09:38 <@sipa> I thought the earlier discussion was about n-ary things in the policy language, not miniscript. 09:38 < andytoshi> yes, but the situation in miniscript has bearing on that 09:39 < andytoshi> because if the policy language had n-ary and and or, and these needed to be mapped to a tree of 2-ary miniscript fragments, that's a hard optimization problem 09:39 <@sipa> Is it? I think this is purely a notational thing. 09:39 < andytoshi> i might be conflating multiple discussions, it's been a while 09:39 < andytoshi> in any case -- if we wanted to support n-ary and_v, and_b, or_b, directly in miniscript, i am in favor of that 09:40 <@sipa> Supporting n-ary stuff in the policy language definitely complicates the compiler. 09:40 <@sipa> But I think making and_v etc n-ary is just syntactic sugar. The internal data structure for miniscript can remain exactly the same. 09:41 < andytoshi> ah yep 09:41 <@sipa> Like e.g. the l: modifier is actually an or_i(0,X) 09:41 < andytoshi> right 09:41 <@sipa> wrapper 09:41 < andytoshi> although it may be, for efficiency reasons, that we would want to change the data structures to actually have a higher branching factor 09:41 < andytoshi> (i guess that's totally independent of the syntax, we could even do that now) 09:41 <@sipa> Yeah, that's a reasonable implementation choice I think, but not a necessity. 09:43 <@sipa> The C++ code is almost entirely recursion free now (only signing still is, and there is a PR open to change that), so I'm not too concerned about keeping things in nested form really. 09:44 < andytoshi> very nice 09:44 < andytoshi> i think rust-miniscript still has a lot of recursion, but that was something of a deliberate decision on our part, to save ourselves the effort while script lengths were bounded anyway 09:44 < andytoshi> but i guess post-taproot we've gotta address that 09:46 <@sipa> https://github.com/sipa/miniscript/blob/master/bitcoin/script/miniscript.h#L352L432 may be useful 09:47 <@sipa> It's a generic "apply recursive algorithm over the tree, without explicit recursion" algorithm. 09:48 < andytoshi> oo slick 09:48 < andytoshi> yeah something like that would be awesome, our concern was that our non-recursive code would be much harder to maintain 09:49 < andytoshi> but this would let it more-or-less keep its recursive form 09:49 <@sipa> Yeah, indeed, the refactor for ToString/ToScript to use this approach was pretty mechanical: https://github.com/sipa/miniscript/pull/83 10:35 -!- Netsplit *.net <-> *.split quits: jnewbery, paairs, jeremyrubin, enick_368, fjahr, blkncd, achow101, elsirion, darosior, sanket_cell_, (+14 more, use /NETSPLIT to show all of them) 10:39 -!- sandipndev [sandipndev@2600:3c00::f03c:92ff:fe8e:dce6] has joined ##miniscript 10:39 -!- sanket_cell [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##miniscript 10:39 -!- Netsplit over, joins: _aj_, michaelfolkson, _0x0ff, jeremyrubin, fjahr, achow101, blkncd, robertspigler, @sipa, darosior (+12 more) 11:03 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 240 seconds] 11:20 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 12:59 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 252 seconds] 13:39 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 19:23 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 240 seconds] 19:53 < sanket1729> achow101: Quick question about bip371(taproot psbt), how is psbt input sighash type field to be used for schnorr signatures? Technically speaking, we might want u8 instead of u32. 19:53 < sanket1729> BIP371 does not mention anything about it. Defaulting to BIP 174, it suggests using SIGHASH_ALL in absence of field 19:53 < sanket1729> I think we want SIGHASH_DEFAULT to save 1 byte 19:54 < sanket1729> perhaps, we should have a separate field for it? 19:55 < achow101> if the sighash type is not specified, it's up to the signer to decide 19:55 < achow101> for taproot, the preference should be SIGHASH_DEFAULT 20:05 < sanket1729> Thanks 20:42 -!- enick_368 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 21:57 -!- meshcollider [meshcollid@user/meshcollider] has quit [Ping timeout: 256 seconds] 22:00 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined ##miniscript --- Log closed Thu Jan 13 00:00:29 2022