--- Log opened Tue Jan 07 00:01:02 2020 02:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 248 seconds] 04:39 -!- jonatack [~jon@213.152.161.170] has joined #bitmetas 06:37 -!- jonatack [~jon@213.152.161.170] has quit [Read error: Connection reset by peer] 06:41 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitmetas 07:17 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds] 10:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitmetas 13:39 < sipa> what do people think of https://github.com/sipa/bips/pull/185 ? 13:39 < sipa> it changes the definition of leaf versions such that tapscript just becomes v0 15:10 < jeremyrubin> The xor thing seems complicated 15:13 < jeremyrubin> found a typo 15:15 < sipa> jeremyrubin: yeah, but it moves all the logic and reasoning for setting the high bits to one place 15:15 < sipa> rather than forcimg it onto every leaf version choice 15:15 < jeremyrubin> How useful is this static analysis property at all? 15:16 < jeremyrubin> It seems a bit weird 15:16 < sipa> it comes at no cost 15:16 < jeremyrubin> Is that range not possible to become valid in the future in new witness script versions 15:17 < sipa> well, up to the future 15:17 < sipa> if they never get defined, no 15:17 < sipa> if they do get defined, yes 15:18 < sipa> for some annex use cases the static analysis property my be essential 15:20 < jeremyrubin> I hadn't paid too close attention to this earlier. 15:20 < jeremyrubin> (i.e., I reviewed the control byte range, but not that it was to impose on which opcodes would be used in script in the future) 15:20 < sipa> oh, no! 15:20 < sipa> you misunderstand 15:21 < sipa> this is about which opcodes are valid in P2WSH 15:21 < jeremyrubin> yes 15:21 < sipa> they can't change without hardfork 15:21 < jeremyrubin> What? 15:21 < jeremyrubin> I thought it's a soft fork? 15:21 < sipa> all oocodes in range 0xc0-0xff immediately fail the script 15:21 < sipa> so we *know* they cannot occur in p2wsh spends 15:21 < jeremyrubin> How is that possible in a new segwit v? 15:22 < sipa> this is about p2wsh, not about new segwit v 15:22 < jeremyrubin> I guess then it's not p2wsh? it's p2wshv2 15:23 < sipa> well or more realistically, taprootv2, or groot, or ... 15:24 < sipa> each new witness version can choose some way to distinguish itself that does not conflict with any earlier defined versions 15:24 < sipa> in practice it may never matter 15:24 < jeremyrubin> Doesn't looking at the scriptPubKey tell us this isn't a p2wsh or a p2wpkh? 15:24 < sipa> sigh 15:24 < sipa> read 15:25 < jeremyrubin> Read which part? 15:25 < jeremyrubin> What you just said? 15:25 < sipa> the point is being able to recognize spends without access to the inputs 15:25 < sipa> *outputs 15:26 < jeremyrubin> ah 15:28 < sipa> specifically, for an annex that increases weight (e.g. when we have a very expensive opcodes that needs little data, but still want to maintain some weight-per-cpu-usage ratio), it may be essential thst you can compute tx weight correctly without knowing the inputs to the tz 15:28 < sipa> *tx 17:29 < aj> sipa: yeah, think 185 makes sense 21:44 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 21:49 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitmetas --- Log closed Wed Jan 08 00:00:01 2020