--- Log opened Thu Jan 09 00:00:04 2020 00:46 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 01:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 03:32 -!- jonatack [~jon@atoulouse-656-1-807-188.w86-221.abo.wanadoo.fr] has joined #bitmetas 03:41 -!- jonatack [~jon@atoulouse-656-1-807-188.w86-221.abo.wanadoo.fr] has quit [Ping timeout: 268 seconds] 03:42 -!- jonatack [~jon@134.19.179.179] has joined #bitmetas 04:55 -!- jonatack [~jon@134.19.179.179] has quit [Ping timeout: 260 seconds] 06:00 < jl2012> sipa: I think calling leaf-version = 0xc0 is better than 0........the reason is "0" is not actually used in the protocol, while 0xc0 is used in the calculation of the tapleaf_hash 06:08 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitmetas 06:09 < sipa> jl2012: i don't understand 06:11 < jl2012> "0xc0" is the value we use to calculate tapleaf_hash. But "0" is just for human; it is not a value used in the protocol 06:12 < sipa> would it help if we changed the definition of the leaf hash to use the leaf version directly (rather than the mangled 2*l ^ 0xc0 function)? 06:12 < jl2012> "the protocol" means "the code" 06:13 < sipa> yes 06:14 < sipa> what if we changed the code for the tapleaf hash to be a function of l instead of one of c[0] & 0xfe 06:15 < jl2012> (c[0] ^ 0xc0) >> 1 ? 06:20 < sipa> yes, that'z how leaf version is defined in #185 06:23 < jl2012> I think code simplicity is more important than human readability. "c[0] & 0xfe" is simpler 06:24 < sipa> agree 06:24 < jl2012> for human, we just define leaf_version = c[0] & 0xfe (as before) 06:25 < sipa> but i don't see the problem with defining leaf version as (c[0] & 0xfe) >> 1 06:25 < sipa> eh 06:25 < sipa> (c[0] ^ 0xc0) >> 1 06:25 < jl2012> the problem is we are defining a value that is not used anywhere in the code 06:25 < sipa> it will be 06:26 < jl2012> where? 06:26 < sipa> the tapscript branch will become "if (leaf_version == 0) { " 06:26 < jl2012> this is implementation details 06:27 < sipa> then i don't understand what you're talking about 06:28 < sipa> we can also not define leaf versions at all, and just say "tapscript applies when c[0] & 0xfe == 0xc0" 06:29 < sipa> but the point of introducing a term is because it makes things clearer for humans reading the spec 06:29 < jl2012> in the code, you can define leaf_verison = ((c[0] ^ 0xc0) >> 0) + 123; and the tapscript branch will become "if (leaf_version == 123) { " 06:29 < sipa> yes 06:29 < sipa> but that would be confusing 06:29 < sipa> the question is what way of specifying it is clearest 06:29 < jl2012> so that "0" has not absolute meaning in the protocol 06:30 < sipa> that's a nonsensical statement 06:30 < jl2012> but 0xc0 has an absolute meaning 06:30 < sipa> you can define the same semantics in any number of ways 06:30 < sipa> jl2012: yes that's the point! 06:30 < sipa> i want that 0xc0 centralized in a single place in the spec 06:31 < sipa> rather than spread out over every possible future leaf version 06:32 < sipa> so we make it part of the definition of leaf_version 06:32 < sipa> and can explain right there why the 0xc0 is there 06:33 < jl2012> 0xc0 is just the result of "c[0] & 0xfe" 06:33 < sipa> i think we're talking past each other 06:33 < jl2012> it is not superior to other even values, e.g. 0xc2, which could be the next tapleaf_version 06:34 < sipa> this definition (c[0] ^ 0xc0) >> 1 means that the intended leaf versions can just be 0, 1, 2, 3, ... 06:35 < sipa> rather than every time needing to explain why leaf versions can't have their lower bit set, or have to have their top two bits set 06:35 < jl2012> "take c[0]; & it with 0xfe; this is the leaf_version; this is also the first byte when you calculate the leaf_hash" 06:36 < sipa> that's what we used to do, and i think it was confusing 06:36 < jl2012> vs. "take c[0]; & it with 0xfe and this is the first byte when you calculate the leaf_hash; and leaf_version = c[0] ^ 0xc0) >> 1" 06:37 < sipa> it doesn't address the problem that the knowledge of what bits are acceptable to set/not set leak into every leaf version choice 06:38 < sipa> i don't understand your criticism 06:38 < jl2012> in the original one you need to do bitwise calculation only once; the new one you do it twice 06:38 < sipa> if anything, the compiler will optimize that away 06:39 < sipa> my question is simply what is the clearest way to explain the behavior 06:39 < jl2012> and once is better than twice; because the second one is for nothing but human readability 06:39 < sipa> i don't understand 06:40 < sipa> we move the 0xc0 to exactly one place 06:41 < jl2012> but now you have 3 constants: 0xfe (for &); 0xc0 (for ^); 0 (the leaf_version) 06:41 < jl2012> rather than only 2 constants: 0xfe (for &); 0xc0 (the leaf_version) 06:41 < sipa> yes 06:41 < sipa> but a harder to explain one 06:41 < jl2012> less constants is preferable 06:41 < sipa> i disagree 06:41 < sipa> sorry 06:43 < sipa> in general i would agree, but starting leaf versions at 0xc0 feels so unnatural to me, and so easily overlooked why, that i think this approach is preferable 06:44 < jl2012> just like most people counts from 1; count from 0 is unnatural to most people 06:45 < sipa> certainly a lot more understandable than counting from 192 06:45 < jl2012> and, while unlikely, we might someday use 150/151 (OP_DIV/MOD) as leaf version 06:46 < jl2012> that would be version 172 with the xor thing 06:47 < jl2012> and is extremely difficult to understand 06:47 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has left #bitmetas [] 06:51 < jl2012> these are the possible values: 0x7e, 0x80, 0x84, 0x96, 0x98, 0xba and above 06:52 < jl2012> so 0xba might be a more natural value to use, rather than 0xc0 06:57 < jl2012> 102/103 VERNOTIF/ELSE is also a valid pair 11:35 < aj> (l<<1)^0xc0 gives 0xc0..0xfe for l=0..31, then the remaining distinguishable (l,opcode) pairs are (32,0x80), (34,0x84), (43,0x96), (44,0x98), (61..63,0xba..0xbe), (83,0x66), (95,0x7e) 11:36 < aj> if you do ((l*2)+0xba)%256 instead, you get 0xba..0xfe for l=0..34 with 86,98,99,101,110,111 being the leftovers matching to 0x66,0x7e,0x80,0x84,0x96,0x98 11:36 < aj> doesn't seem terribly likely we'll run out of leaf versions though 11:51 < aj> yeah, i think having the formula and saying distinguishable leaf versions are 0..32 (and also 34,43,44,61..63,83,95 if needed) and tapscript is leaf version 0 is clearer than saying distinguishable leaf versions are even numbers between 186..254,128,132,150,152,102,126 and tapscript is 192 12:13 < jl2012> i think 0x80 is (0x80 ^ 0xc0) * 2 = 128 13:15 < aj> (0x80^0xc0)/2 not *2 ? 13:51 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitmetas 18:26 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in] 19:16 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 19:20 -!- jonatack [~jon@88.124.242.136] has joined #bitmetas 21:23 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitmetas --- Log closed Fri Jan 10 00:00:03 2020