--- Log opened Fri Jan 10 00:00:03 2020 00:56 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined #bitmetas 01:23 < jl2012> Yes 01:41 < jl2012> in terms of understandability, I think "every even number >= 192" is better than "count from 0 after xor and shift" 01:42 < jl2012> in the first case, 128 is 128, 192 is 192, 254 is 254 01:43 < aj> "every even number >= 192 and some others" vs "0..32 and some others" is the comparison for the leaf version; the encoded version is the same each way 01:44 < aj> the "encoding" just captures the "why do i have to be >=192 and even" part 01:46 < jl2012> otherwise it's like those number pattern question "if 0 = 192, 1 = 194, 31 = 254, 32 = ?" 01:46 < jl2012> and the correct answer is 128 01:46 < jl2012> "why not 256?" "because of this xor and that shift" 01:47 < aj> "because that's what the encoding is" 01:52 < jl2012> if you were not very familiar with bitwise operations, xor is really difficult to understand. I think (c[0] - 0xc0) & 0xfe is easier to understand for most (although I still think 192 = 192 is better) 01:53 < aj> hm 01:56 < aj> i wonder if this isn't all a bit backwards; we want to go from an human-friendly version "0" and "1" to 0xc0 and 0xc2 (or whatever), not the other way around. maybe call "c[0] & 0xfe" the "script rules identifier" and have ver2sri(v) = ((v*2)+192)%256 so that tapscript is "script rules version 0" but has "script rules identifier 0xc0" ? 01:58 < aj> with footnote explaining that this means versions 0..31, 32, etc are distinguishable from v0 p2wsh spends, due to ver2sri(v) and ver2sr(v)|1 both not matching valid p2wsh opcodes? 01:59 < aj> if we're going from human numbers then that's just a constexpr function that gets evaluated at compile time and there's no need to worry about bitops potentially being faster than *,+,% 02:00 < aj> oh, not "32, etc" with that formula. ykwik 02:00 < aj> oh, not "32, etc" with that formula. ykwim 02:20 < jl2012> It's not very human-friendly as we are not good at doing xor 02:21 < jl2012> and nothing is friendlier than "x is x" 02:23 < jl2012> the process from 192->0, 194->1, etc, no matter with xor/shift or minus/shift, would take at least a few seconds to calculate 02:24 < jl2012> and a 5-year-old child could easily count all even numbers between 192 and 254 02:24 < aj> writing ver2sri(1) and letting the computer work it out seems pretty simple 02:24 < aj> sure but the 5 year old child has to remember it's 192 and not 184 or 176 or 210 02:25 < jl2012> with xor or minus you still need to remember the 192 as constant 02:25 < aj> we have computers to remember how to do maths for us 02:26 < aj> i don't calculate sha256 sums in my head either 03:38 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 260 seconds] 04:02 -!- meshcollider [meshcollid@209.141.50.204] has quit [Ping timeout: 268 seconds] 04:19 < aj> jl2012: maybe https://github.com/sipa/bips/pull/185#issuecomment-573013822 works; lets you just ignore leaf version and use 0xc0 directly, but still (imho) has the explanatory benefits sipa was trying to get at 04:21 < sipa> aj: small nit: distinguishing P2WPKH from P2WSH is harder, as 0x02 and 0x03 are valid opcodes too 04:24 < aj> sipa: hm, i thought i avoided saying you could distinguish those? 04:25 < aj> maybe i needed "/other/ valid P2WSH opcodes" 04:28 < sipa> ah! 04:35 < jl2012> sipa: is it possible to find the probability of a random compressed/uncompressed key to be a must-fail or must-pass script? 04:37 < jl2012> I think uncompressed keys are more likely to be must-fail, with more potential opcodes 04:38 < aj> what does "must-pass" mean? with an empty stack, or is it okay so long as anyone can calculate the stack? 04:38 < jl2012> aj: there could be several level of "must-pass". Some are more easy to identify 04:39 < aj> or perhaps for these purposes the stack is a single element that looks like a DER signature? 04:40 < jl2012> 02xxxx1C{28 bytes} OP_2DROP would look like a "must pass" script 04:41 < jl2012> because P2WPKH has 2 witness elements 04:46 < jl2012> but knowing a script to be "must pass" is not helpful to distinguish P2WPKH from P2WSH 04:46 < jl2012> so only "must-fail" and "not-must-fail" matter 04:47 < jl2012> I think most random string are already "must-fail" due to unparsable 04:48 < aj> well, there's no valid checksig ops if the script looks like an uncompressed key, i think; so your analysis is already at <=1 sigop which is pretty good; presumably with 2DUP's and a script that looks like an uncompressed pubkey you could get >1 sigop though 04:53 < jl2012> you can just try to execute it. Every opcodes except CHECKSIGs could be executed without UTXO 04:55 < jl2012> if it passes than you are out of luck 04:56 < jl2012> I think the empty array as public key is valid in consensus? 04:59 < sipa> i think so 05:01 < jl2012> so it's possible to have a valid CHECKSIG in a compressed key 05:02 < jl2012> but it has to come with 2 empty input 05:02 < jl2012> an empty key and an empty sig 05:04 < sipa> it's an interesting question: what percentage of (uniformly chosen) spks up to a certain length even parse correctly 05:12 < sipa> oh, i can use gramtropy to count the number of parseable scripts 05:21 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitmetas 05:57 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 268 seconds] 05:59 -!- jonatack [~jon@213.152.161.239] has joined #bitmetas 07:42 -!- jonatack [~jon@213.152.161.239] has quit [Ping timeout: 265 seconds] 07:48 < aj> nickler: going to rebase #23 (add weak generator mode for bip-schnorr impl and test vecs) sometime or..? 08:22 -!- meshcollider [meshcollid@209.141.50.204] has joined #bitmetas 08:24 < sipa> aj: i'm not convinced about having both leaf version and script rules identifier 08:27 < aj> "script rules identifier" doesn't really roll off the tongue either 08:38 < sipa> if it wasn't for the possibility of leaf versions beyond 31, i'd say just define the leaf version as the 5 middle bits of c[0] 09:00 < aj> sipa: here's what it looks like with "leaf version" dropped, and "script rules identifier" renamed to "leaf version" (so tapscript is 0xc0 not 0 again), maybe that works? https://github.com/ajtowns/bips/blob/18f123e95a5bf12ff000674a5a4c2ddbbad543d0/bip-taproot.mediawiki#cite_note-7 09:02 < sipa> aj: the leaf version actually can be 0x50, but picking that makes an annex mandatory :p 09:02 < aj> no, you could ensure you always pick a Q that has to be negated :p 09:03 < sipa> haha 09:08 -!- meshcollider [meshcollid@209.141.50.204] has quit [Ping timeout: 260 seconds] 09:14 < sipa> aj: you didn't rename things in bip-tapscript (it still says "leaf version 0") 09:14 < aj> sipa: yeah and there's a typo too "fule" instead of "rule" 09:16 < aj> quick commit fixing those pushed on the same branch mentioned in the #185 comment 09:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitmetas 11:21 < sipa> aj: the code examples still use 2 * leaf_version ^ 0xc0 11:22 < aj> grr :( 11:59 < sipa> aj, jl2012: fwiw, counting scripts consisting of just defined opcodes (no nops, no disabled opcodes), with non-stradling pushes and balanced if/notifs, i get very close to 2^210 33-byte scripts 12:00 < aj> checking for else only within if/endif? 12:01 < sipa> yes, actually testing for balancedness 12:01 < jl2012> IF ELSE ELSE ENDIF is valid 12:01 < sipa> oh, i'm not taking into account that you can do IF ELSE ELSE ENDIF 12:01 < sipa> let me change that 12:01 < sipa> doesn't affect the number 12:02 < sipa> 2^210.054 12:02 < jl2012> out of 2^(33*8)? 12:03 < sipa> yeah 12:03 < jl2012> but why no nops? 12:03 < sipa> because i forgot, i guess, and i realized when i mentioned it here :) 12:03 < sipa> also most disabled opcodes are actually still valid inside branches 12:03 < sipa> i could permit those too 12:04 < jl2012> what about PUSHDATA2 and 4? 12:05 < jl2012> 1, 2 and 4 12:05 < jl2012> you can't have OP_FROMALTSTACK as the first opcode 12:08 < sipa> actually i was counting some disabled opcodes 12:08 < sipa> i've changed it now to only allow disabled opcodes inside conditions 12:08 < sipa> and added nops 12:08 < sipa> now i'm at 2^208 :) 12:08 < jl2012> some are invalid even in unexecuted branch 12:09 < sipa> yeah, not including those 12:09 < sipa> but there are plenty more impossible to satisfy scripts 12:09 < sipa> e.g. 4 5 OP_EQUALVERIFY is impossible 12:10 < jl2012> 0 VERIFY 12:10 < sipa> yeah 12:10 < jl2012> FROMALTSTACK as the first opcode 12:10 < sipa> i suspect this is a small subset only, but i may be wrong 12:11 < jl2012> 1/256 of all random script starts with FROMALTSTACK? 12:11 < sipa> log2(1-1/256) = 0.0056 12:12 < jl2012> >=5 byte pushes followed by arithmetic opcodes 12:12 < jl2012> " >= 5 byte" 12:13 < sipa> aj: going to fix? 12:13 < aj> oh, distracted 12:13 < sipa> i'll squash in your commits 12:13 < sipa> *cherry-pick 12:16 < aj> output_pubkey_tag ^ leaf_version, "^" not "|" ? weird 12:17 < sipa> ? 12:17 < aj> in taproot_sign_script, you xor the low bit with the highbits instead of or'ing, seems weird 12:18 < aj> you? we? whatever 12:18 < sipa> ah! 12:18 < sipa> i did that so i wouldn't need to figure out the precedence between ^ and | 12:19 < aj> wouldn't have mattered? but fair enough 12:19 < sipa> ah, perhaps not 12:19 < sipa> at least it would prevent linters complaining about unclear precedence :p 12:20 < aj> true! 12:22 < aj> oh wow, it used to be + not | 12:22 < aj> maybe + and ^ are scary 12:23 < sipa> right 12:24 < aj> don't know what the maybe is there for, + and ^ are scary full stop 12:25 < sipa> there are cryptographic primitives that are based purely on + ^ and << :) 12:29 < aj> wouldn't be surprised if you could do cryptographic primitives on the _precedence_ of those operators, without actually performing them 12:29 < aj> anyway, force pushed a squashed cleanup; still on top of your commit, so rebase/reword as you like if you like 16:46 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 260 seconds] 16:59 < jeremyrubin> when I read this in the code I was also scared and suggested splitting it into two lines 17:00 < jeremyrubin> I kinda wonder -- is there a magic number we can multiply by to extract the version? 17:02 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-peewdyazmopwzjvg] has joined #bitmetas 17:48 -!- andytoshi [~apoelstra@96.53.77.134] has joined #bitmetas 17:48 -!- andytoshi [~apoelstra@96.53.77.134] has quit [Changing host] 17:48 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitmetas --- Log closed Sat Jan 11 00:00:03 2020