12019-11-06T00:14:23 *** notmandatory has quit IRC
22019-11-06T00:15:36 *** michaelfolkson has quit IRC
32019-11-06T00:29:26 *** soju has joined ##taproot-bip-review
42019-11-06T00:34:15 *** soju has quit IRC
52019-11-06T00:48:11 *** Chris_Stewart_5 has joined ##taproot-bip-review
62019-11-06T00:54:57 *** jb55 has quit IRC
72019-11-06T00:57:25 *** lightlike has quit IRC
82019-11-06T01:10:47 *** pinheadmz has quit IRC
92019-11-06T01:10:56 *** Chris_Stewart_5 has quit IRC
102019-11-06T01:27:53 *** thestack has quit IRC
112019-11-06T01:49:45 *** pglazman has quit IRC
122019-11-06T02:01:34 *** raj_149 has joined ##taproot-bip-review
132019-11-06T02:32:43 *** nick_freeman has joined ##taproot-bip-review
142019-11-06T02:36:03 *** nick_fre_ has quit IRC
152019-11-06T03:28:06 *** pinheadmz has joined ##taproot-bip-review
162019-11-06T03:37:10 *** nick_freeman has quit IRC
172019-11-06T03:42:17 *** nick_freeman has joined ##taproot-bip-review
182019-11-06T04:10:47 *** nick_freeman has quit IRC
192019-11-06T04:20:30 <instagibbs> r251d, i think those variables could stand to be named, I agree
202019-11-06T04:31:28 *** pinheadmz has quit IRC
212019-11-06T04:31:59 *** pglazman has joined ##taproot-bip-review
222019-11-06T05:40:31 *** pglazman has quit IRC
232019-11-06T06:01:48 *** CubicEarth has quit IRC
242019-11-06T06:26:59 *** HighOnBtc has quit IRC
252019-11-06T06:41:51 *** xoyi- has joined ##taproot-bip-review
262019-11-06T07:15:15 *** andytoshi has quit IRC
272019-11-06T08:00:26 *** eltneg has quit IRC
282019-11-06T08:29:42 *** xoyi- has quit IRC
292019-11-06T08:31:30 *** Tibo has quit IRC
302019-11-06T08:36:37 <aj> sipa: what's with the swap/if/endif for 4-of-10k ? just use CSA directly for that?
312019-11-06T08:45:30 <digi_james> Hmm. Wondering what the witness stack size limit is? Straight-up CSA would require 10k-4 wit stack elements for all the 0's?
322019-11-06T08:48:22 <digi_james> If I understand correctly, in sipa's example the 0's are in the tapscript, which is one wit element.
332019-11-06T08:49:15 <gmaxwell> aj: Probably because I needlessly primed him with mention of IF-gating.
342019-11-06T08:52:05 <digi_james> gmaxwell: There are no witness stack length limits, right?
352019-11-06T08:52:32 <digi_james> I mean, nr of elements in wit stack.
362019-11-06T08:59:53 *** b10c has joined ##taproot-bip-review
372019-11-06T09:00:55 <gmaxwell> Just that implied by the maximum transaction size.
382019-11-06T09:02:01 <digi_james> Thank you
392019-11-06T09:02:06 <gmaxwell> One of the ideas behind taproot is that it makes vastly more expensive scripts reasonable to use-- because mostly you use a cooperative resolution, and the complex script just exists as a threat.
402019-11-06T09:02:45 <gmaxwell> So thats a good reason to be pretty permissive with limits. Limits also greatly complicate automated script generation, composition, etc.
412019-11-06T09:05:05 <aj> digi_james, gmaxwell: the witness stack has a 1000 element limit including during execution
422019-11-06T09:05:37 <aj> (see script/script.h MAX_STACK_SIZE)
432019-11-06T09:10:18 <digi_james> aj: Oh thx, whereas witness element can be <= 10k I recall. So it seems one would have push the null's required for csa to the tapscript.
442019-11-06T09:10:32 <digi_james> Sorry, 10kB
452019-11-06T09:23:44 <aj> digi_james: for segwit v0 the script can be 10k in length; the witness data then fulfils that. taproot drops that limit
462019-11-06T09:24:59 <aj> digi_james: there's limits on how big each element on the stack can be, see MAX_SCRIPT_ELEMENT_SIZE eg
472019-11-06T09:28:15 *** willcl_ark has quit IRC
482019-11-06T09:39:03 <digi_james> aj: I am thinking through our (4-of-largeN) CSA example again: So our (CSA) tapscript occupies just one witness element, right? If its satisfaction requires 10k witness elements (mostly nulls), we hit MAX_STACK_SIZE upon execution, because these are pushed on the script stack at once before tapscript evaluation. If we use the (if gated) modified CSA tapscript, only 4 satisfying witness elements are
492019-11-06T09:39:03 <digi_james> pushed to the stack before modified CSA is run, and no limits are hit, is this correct?
502019-11-06T09:44:06 *** willcl_ark has joined ##taproot-bip-review
512019-11-06T09:57:43 <aj> digi_james: see https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki "Stack + altstack element count limit" -- you'd be limited to 996 empty signatures and 4 valid signatures on the stack
522019-11-06T10:01:28 <digi_james> aj: Thanks. So we have a workaround for that limit now :)
532019-11-06T10:01:43 <aj> digi_james: i think something like DEPTH {2k+1} EQUALVERIFY { IFDUP NOTIF <p> CHECKSIGVERIFY ENDIF 1SUB }*n DEPTH 0 EQUAL
542019-11-06T10:02:39 <aj> digi_james: would let you have a witness stack of {number of keys to skip, valid signature}*k + {nuber of keys to get to the end} to get to a k-of-{very large n} multisig
552019-11-06T10:12:34 <digi_james> aj: Oh you mean without CSA? Nice!
562019-11-06T10:16:54 <aj> oh, maybe there needs to be a OP_DROP before the DEPTH in the above? probably some other tweaks needed to make it actually work too
572019-11-06T10:19:25 <digi_james> I had to look up op_depth :)
582019-11-06T10:31:26 *** jonatack has joined ##taproot-bip-review
592019-11-06T10:49:14 <gmaxwell> sounds like a good script for someone to flesh out and test.
602019-11-06T10:49:29 <gmaxwell> (and potentially somewhat useful)
612019-11-06T11:05:13 *** k7 has joined ##taproot-bip-review
622019-11-06T11:07:07 *** k7 has left ##taproot-bip-review
632019-11-06T11:07:09 *** k7 has joined ##taproot-bip-review
642019-11-06T11:07:35 *** k7 has left ##taproot-bip-review
652019-11-06T11:21:20 *** daniel_____ has joined ##taproot-bip-review
662019-11-06T11:46:06 *** Chris_Stewart_5 has joined ##taproot-bip-review
672019-11-06T11:53:15 *** real_or_random has quit IRC
682019-11-06T11:55:32 *** real_or_random has joined ##taproot-bip-review
692019-11-06T12:20:46 *** orfeas has joined ##taproot-bip-review
702019-11-06T12:20:53 *** pyskell has quit IRC
712019-11-06T12:45:00 *** stacie has joined ##taproot-bip-review
722019-11-06T12:54:11 *** Chris_Stewart_5 has quit IRC
732019-11-06T12:59:21 *** Chris_Stewart_5 has joined ##taproot-bip-review
742019-11-06T13:07:37 *** jonatack has quit IRC
752019-11-06T13:19:27 *** nick_freeman has joined ##taproot-bip-review
762019-11-06T13:33:01 *** HighOnBtc has joined ##taproot-bip-review
772019-11-06T13:51:49 *** lightlike has joined ##taproot-bip-review
782019-11-06T13:56:47 *** HighOnBtc has quit IRC
792019-11-06T14:05:53 *** Chris_Stewart_5 has quit IRC
802019-11-06T14:09:00 *** Chris_Stewart_5 has joined ##taproot-bip-review
812019-11-06T14:27:29 <instagibbs> warning, OP_DEPTH isn't in miniscript :P
822019-11-06T14:27:32 <instagibbs> IIRC
832019-11-06T14:29:37 *** jonatack has joined ##taproot-bip-review
842019-11-06T14:36:02 *** pinheadmz has joined ##taproot-bip-review
852019-11-06T14:49:11 *** pyskell has joined ##taproot-bip-review
862019-11-06T15:15:52 <aj> OP_DEPTH doesn't compose so isn't miniscript friendly
872019-11-06T15:38:14 *** HighOnBtc has joined ##taproot-bip-review
882019-11-06T15:49:03 *** soju has joined ##taproot-bip-review
892019-11-06T15:53:50 *** pglazman has joined ##taproot-bip-review
902019-11-06T15:54:16 *** HighOnBtc has quit IRC
912019-11-06T16:10:45 *** pinheadmz has quit IRC
922019-11-06T16:39:59 *** michaelfolkson has joined ##taproot-bip-review
932019-11-06T17:06:42 *** soju has quit IRC
942019-11-06T17:20:51 *** CubicEarth has joined ##taproot-bip-review
952019-11-06T17:30:28 *** stacie has quit IRC
962019-11-06T17:37:41 *** stacie has joined ##taproot-bip-review
972019-11-06T18:02:43 <gmaxwell> miniscript has a lot of limitations, so that isn't a surprise.
982019-11-06T18:03:35 <gmaxwell> though I think this example has the largest spending weight difference I've seen yet for an optimized script vs what miniscript could make. (for thing which miniscript could model)
992019-11-06T18:06:02 *** orfeas has quit IRC
1002019-11-06T18:11:01 *** michaelfolkson has quit IRC
1012019-11-06T18:15:57 *** jb55 has joined ##taproot-bip-review
1022019-11-06T18:30:08 *** michaelfolkson has joined ##taproot-bip-review
1032019-11-06T18:34:43 *** stacie has quit IRC
1042019-11-06T18:39:14 *** pinheadmz has joined ##taproot-bip-review
1052019-11-06T18:48:27 *** pyskell has quit IRC
1062019-11-06T19:20:26 *** stacie has joined ##taproot-bip-review
1072019-11-06T19:21:57 *** b10c has quit IRC
1082019-11-06T19:28:55 <sipa> aj: a more composable/depthless version would be:
1092019-11-06T19:30:00 <sipa> 0 (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE <key> CHECKSIGADD ENDIF)* 4 EQUAL
1102019-11-06T19:31:33 <sipa> aj: i think you need 0NOTEQUAL somewhere as well due to minimalif rule
1112019-11-06T19:35:56 <sipa> the (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE <key> CHECKSIGADD ENDIF) sequence turns a stack ending with [sig,c>0,n] into [sig,c,n], and a stack ending in [sig,0,n] into [n+(sig valid)]
1122019-11-06T19:39:41 <sipa> actually, this does not work, as it doesn't guarantee exactly 8 elements were popped off the stack
1132019-11-06T19:41:49 <sipa> you'd need something (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE SWAP <key> CHECKSIGVERIFY ADD1 ENDIF)* 4 EQUALVERIFY
1142019-11-06T19:42:06 <sipa> there must be a way to avoid 3 SWAPs
1152019-11-06T19:48:41 *** stacie has quit IRC
1162019-11-06T19:53:34 <gmaxwell> stuff like that makes me wish every opcode had two bits for 'swap' and 'dup' embedded in them, and great sympathy for CISC cpu designers.
1172019-11-06T19:54:17 <sipa> and a conditional execution bit, and control register? :)
1182019-11-06T19:55:12 <sipa> having a separate explicit input stack and temporary variables stack would also do wonders
1192019-11-06T20:58:05 *** michaelfolkson has quit IRC
1202019-11-06T21:18:42 <Chris_Stewart_5> Has anyone committed to updating the hard coded test vectors found here? https://github.com/sipa/bitcoin/tree/taproot/src/test/data
1212019-11-06T21:19:10 <Chris_Stewart_5> It's useful for library developers
1222019-11-06T21:19:22 <Chris_Stewart_5> sighash.json 6 years :$
1232019-11-06T21:20:22 <pinheadmz> sipa: https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#transaction-digest says key_value is 0x00 but in the code I see 0x02
1242019-11-06T21:20:24 <pinheadmz> https://github.com/sipa/bitcoin/blob/527ed7d4b230a694ee223a000cd5fd7495a00fcb/src/script/interpreter.cpp#L1447
1252019-11-06T21:20:44 <pinheadmz> s/key_value/key_version
1262019-11-06T21:20:50 <sipa> pinheadmz: fix it!
1272019-11-06T21:21:26 <pinheadmz> :+1:
1282019-11-06T21:22:25 <pinheadmz> any rationale for 2 instead of 0?
1292019-11-06T21:23:49 <sipa> yes, because it used to be equal to the first byte of the pubkey (ignoring the sign bit)
1302019-11-06T21:23:56 <pinheadmz> ah
1312019-11-06T21:23:56 <sipa> 0 makes most sense now
1322019-11-06T21:24:24 <pinheadmz> oh wait haha, "fix it!" -- the BIP or the code?
1332019-11-06T21:24:45 <pinheadmz> sounds like change the code to 0 in both those places i linked?
1342019-11-06T21:26:20 <sipa> yes, the bip was updated from 2 to 0 when xonly was introduced
1352019-11-06T21:26:24 <sipa> but the code wasn't
1362019-11-06T21:26:30 <pinheadmz> ok
1372019-11-06T21:26:31 <sipa> i'll do it in my next rebase
1382019-11-06T21:26:37 <pinheadmz> ok! cheers
1392019-11-06T22:14:30 *** HighOnBtc has joined ##taproot-bip-review
1402019-11-06T22:24:31 *** pinheadmz has quit IRC
1412019-11-06T22:44:35 *** Chris_Stewart_5 has quit IRC
1422019-11-06T22:50:02 <maaku> gmaxwell: have you seen the J1 forth CPU? it has those sorts of bits embedded in its opcode decoding
1432019-11-06T22:56:13 *** Chris_Stewart_5 has joined ##taproot-bip-review
1442019-11-06T23:15:08 *** Chris_Stewart_5 has quit IRC
1452019-11-06T23:19:00 *** soju has joined ##taproot-bip-review
1462019-11-06T23:53:45 *** michaelfolkson has joined ##taproot-bip-review
1472019-11-06T23:56:48 *** michaelfolkson has quit IRC