12019-11-16T07:58:10 *** jonatack has quit IRC
22019-11-16T09:52:21 *** jonatack has joined ##taproot-bip-review
32019-11-16T09:53:21 *** HighOnBtc has joined ##taproot-bip-review
42019-11-16T09:58:20 *** HighOnBtc has quit IRC
52019-11-16T10:56:59 *** mryandao has quit IRC
62019-11-16T10:59:04 *** mryandao has joined ##taproot-bip-review
72019-11-16T11:34:21 *** andytoshi has quit IRC
82019-11-16T13:36:23 *** Chris_Stewart_5 has joined ##taproot-bip-review
92019-11-16T14:10:59 *** Chris_Stewart_5 has quit IRC
102019-11-16T14:16:07 *** Chris_Stewart_5 has joined ##taproot-bip-review
112019-11-16T14:49:39 *** Chris_Stewart_5 has quit IRC
122019-11-16T15:08:43 *** Chris_Stewart_5 has joined ##taproot-bip-review
132019-11-16T15:40:53 *** jonatack has quit IRC
142019-11-16T17:10:36 *** Chris_Stewart_5 has quit IRC
152019-11-16T17:22:08 *** Chris_Stewart_5 has joined ##taproot-bip-review
162019-11-16T18:11:18 *** jonatack has joined ##taproot-bip-review
172019-11-16T18:48:25 *** Chris_Stewart_5 has quit IRC
182019-11-16T19:01:54 *** yaslama has joined ##taproot-bip-review
192019-11-16T19:19:34 *** Chris_Stewart_5 has joined ##taproot-bip-review
202019-11-16T20:02:34 *** Chris_Stewart_5 has quit IRC
212019-11-16T20:15:37 *** yaslama_ has joined ##taproot-bip-review
222019-11-16T20:16:57 *** yaslama has quit IRC
232019-11-16T21:46:16 *** HighOnBtc has joined ##taproot-bip-review
242019-11-16T22:10:42 * pinheadmz https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules
252019-11-16T22:10:55 <pinheadmz> "If there are at least two witness elements left, script path spending is used:"
262019-11-16T22:11:10 <pinheadmz> what if the first byte of the last witness item after annex is removed is NOT 0xc0 ?
272019-11-16T22:12:48 <pinheadmz> I ask because in https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#specification the leaf version 0xc0 or 0xc1 is specified - so Im confused between the two BIPS
282019-11-16T22:13:38 <pinheadmz> I guess my question is: does spend_type have bit 1 set if there are >=2 items on stack after annex is removed BUT ALSO, the last item does NOT start with 0xc0 or 0xc1 ?
292019-11-16T22:15:56 <sipa> if the last item does not start with 0xc0/0xc1 it's a unknown leaf version
302019-11-16T22:16:02 <sipa> and no further rules apply
312019-11-16T22:16:38 <pinheadmz> ok makes sense i think i was confused by this test: "alwaysvalid/unknownversion#fe"
322019-11-16T22:16:44 <pinheadmz> lemme see if i understan the comment "Annex is mandatory for control block with leaf version 0x50"
332019-11-16T22:17:14 <pinheadmz> so leaf version 0x50 is a long way away from being deployed -- but if it ever IS, because that is the magic number for an annex, you ALSO must have an annex - so it is removed
342019-11-16T22:17:53 <sipa> exactly
352019-11-16T22:19:07 <pinheadmz> and if I see an unkown leaf version, I just mark the input as valid, dont even bother computing tx digest, etc
362019-11-16T22:19:33 <sipa> yes, you don't even get the point of executing a script
372019-11-16T22:19:48 <sipa> much less get to the point of encountering a signature to check
382019-11-16T22:19:57 <pinheadmz> right ok
392019-11-16T22:20:30 <pinheadmz> ok, lastly this line: "The leaf version is 0xc0 (i.e. the first byte of the last witness element after removing the optional annex is 0xc0 or 0xc1)" -- what is 0xc1 here?
402019-11-16T22:21:11 <sipa> the leaf version is c[0] & 0xfe
412019-11-16T22:21:29 <pinheadmz> ah ok i see, "The low bit is used to denote whether the has_square_y(Q) holds."
422019-11-16T22:21:33 <pinheadmz> thanks! phew, complicated.
432019-11-16T22:21:37 <sipa> right
442019-11-16T22:22:00 <sipa> it's kind of the other way around: leaf versions only exist because there were a few unused bits in c[0]
452019-11-16T22:22:22 <sipa> but it's necessitated by needing to convey has_square_y(Q)
462019-11-16T22:22:51 <pinheadmz> heh, I see - you only needed one bit, but now you got 7 more you mine as well use :-)
472019-11-16T22:23:38 <pinheadmz> and crypto wise - is this jsut an optimization? presumably if its 1 or 0 a verifier could just try both?
482019-11-16T22:26:09 <sipa> that would break batch verifiability, which is a design goal
492019-11-16T22:27:53 <pinheadmz> cool
502019-11-16T22:59:33 *** b10c has joined ##taproot-bip-review
512019-11-16T23:20:39 *** b10c has quit IRC
522019-11-16T23:25:58 <pinheadmz> the test feature_taproot.py has several scripts with OP_CHECKSIGADD -- but none of them are actually multisig-ing? I guess that keeps the tests simple, one sig per test?
532019-11-16T23:26:52 <pinheadmz> but in practice, like with CMS, each sig could have a different sighash type and require a different sighash & TX digest
542019-11-16T23:28:14 <sipa> more tests welcome
552019-11-16T23:32:47 <pinheadmz> yeah ofc :-) Just making sure IM reading correctly
562019-11-16T23:52:56 *** HighOnBtc has quit IRC