--- Day changed Sat Nov 16 2019 01:52 -!- jonatack [~jon@213.152.161.234] has joined ##taproot-bip-review 01:53 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 01:58 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 276 seconds] 02:56 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 02:59 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 03:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer] 05:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 06:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 06:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 06:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 07:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 07:40 -!- jonatack [~jon@213.152.161.234] has quit [Ping timeout: 265 seconds] 09:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 09:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 10:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review 10:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 11:01 -!- yaslama [~yaslama@bzq-79-181-233-241.red.bezeqint.net] has joined ##taproot-bip-review 11:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 12:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 12:15 -!- yaslama_ [~yaslama@bzq-218-78-150.red.bezeqint.net] has joined ##taproot-bip-review 12:16 -!- yaslama [~yaslama@bzq-79-181-233-241.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 13:46 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 14:10 * pinheadmz https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules 14:10 < pinheadmz> "If there are at least two witness elements left, script path spending is used:" 14:11 < pinheadmz> what if the first byte of the last witness item after annex is removed is NOT 0xc0 ? 14:12 < 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 14:13 < 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 ? 14:15 < sipa> if the last item does not start with 0xc0/0xc1 it's a unknown leaf version 14:16 < sipa> and no further rules apply 14:16 < pinheadmz> ok makes sense i think i was confused by this test: "alwaysvalid/unknownversion#fe" 14:16 < pinheadmz> lemme see if i understan the comment "Annex is mandatory for control block with leaf version 0x50" 14:17 < 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 14:17 < sipa> exactly 14:19 < pinheadmz> and if I see an unkown leaf version, I just mark the input as valid, dont even bother computing tx digest, etc 14:19 < sipa> yes, you don't even get the point of executing a script 14:19 < sipa> much less get to the point of encountering a signature to check 14:19 < pinheadmz> right ok 14:20 < 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? 14:21 < sipa> the leaf version is c[0] & 0xfe 14:21 < pinheadmz> ah ok i see, "The low bit is used to denote whether the has_square_y(Q) holds." 14:21 < pinheadmz> thanks! phew, complicated. 14:21 < sipa> right 14:22 < sipa> it's kind of the other way around: leaf versions only exist because there were a few unused bits in c[0] 14:22 < sipa> but it's necessitated by needing to convey has_square_y(Q) 14:22 < pinheadmz> heh, I see - you only needed one bit, but now you got 7 more you mine as well use :-) 14:23 < pinheadmz> and crypto wise - is this jsut an optimization? presumably if its 1 or 0 a verifier could just try both? 14:26 < sipa> that would break batch verifiability, which is a design goal 14:27 < pinheadmz> cool 14:59 -!- b10c [~Thunderbi@i577BC6EC.versanet.de] has joined ##taproot-bip-review 15:20 -!- b10c [~Thunderbi@i577BC6EC.versanet.de] has quit [Ping timeout: 246 seconds] 15:25 < 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? 15:26 < pinheadmz> but in practice, like with CMS, each sig could have a different sighash type and require a different sighash & TX digest 15:28 < sipa> more tests welcome 15:32 < pinheadmz> yeah ofc :-) Just making sure IM reading correctly 15:52 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 276 seconds] 17:40 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Quit: Bye] 17:50 -!- pyskell [~meh@unaffiliated/pyskell] has quit [Quit: Leaving] 21:42 -!- Aleru [sid403553@gateway/web/irccloud.com/x-uaunxkgpufrmzkyi] has joined ##taproot-bip-review