1 2019-11-20T00:11:19  <elichai2> sipa: I just went over the meeting, awesome explanations :)
  2 2019-11-20T00:11:19  <elichai2> I have one question, can any of these algorithms be of use in signing too? I can't see how any of them can be constant time in relation to the secret
  3 2019-11-20T00:12:05  <elichai2> (I'm actually not sure I looked at the signing mult function in libsecp)
  4 2019-11-20T00:15:42  <elichai2> sipa: arghh I disagree on "it has no hashes". You can't do the (e, s) because the whole term need to be devided by the nonce, so you need to have the nonce. But if you do ecdsa "without hashes" then it's broken. (unless you sign on some preknown constant ie opposite of fiat shamir)
  5 2019-11-20T00:16:35  <elichai2> At least that's my understanding (which I might be wrong :) )
  6 2019-11-20T00:18:46  <sipa> elichai2: i don't understand
  7 2019-11-20T00:19:30  <sipa> ECDSA certainly needs the message to be a hash, if that's what you mean - it's absolutely broken otherwise, but the requirements on that hash are very low (just preimage resistance, i think)
  8 2019-11-20T00:19:59  <sipa> but apart from that, there is no 'challenge' value like schnorr has (which is the 'e' in the (e,s) form, or the hash in the (R,s) form)
  9 2019-11-20T00:22:22  <elichai2> Isn't that just because ecdsa is multiplied by the multiplicative inverse of the nonce?
 10 2019-11-20T00:22:49  <elichai2> Arghh I confused myself
 11 2019-11-20T00:23:07  <sipa> ECDSA effectively uses r=R.x as challenge
 12 2019-11-20T00:23:36  <sipa> so another way of looking at it is that for ECDSA, the (R,s) and (e,s) forms are the same (as you can interpret r both as an encoding of R, or as the challenge itself)
 13 2019-11-20T00:27:25  <elichai2> Looked again at the equations, and even if I remove the division by k I still can't make like (e, s)
 14 2019-11-20T00:27:53  <elichai2> The fact that the nonce is by itself in schnorr helps a lot
 15 2019-11-20T00:29:24  <sipa> the equation is sR = mG + rP, where R is some point whose X coordinate is r
 16 2019-11-20T00:30:14  <sipa> treating ECDSA as "(R, s)": compute r=R.x, and verify the equation
 17 2019-11-20T00:30:42  <elichai2> Oh I see now. The (e,s) is natural because we have e=H(R,m). For ecdsa A. We don't have that naturally. B. we can't get anything useful out of the equation without knowing R
 18 2019-11-20T00:30:55  <elichai2> Am I understanding correctly?
 19 2019-11-20T00:30:58  <sipa> treating ECDSA as "(e, s)" (with e=r), compute R as (mG+rP)/s, then extract R.x and compare it with e
 20 2019-11-20T00:31:45  <sipa> i'm saying the opposite: ECDSA is actually already in (e, s) form (if you call e=R.x)
 21 2019-11-20T00:32:23  <sipa> it's just confused because e is just computed directly from the R point... so it looks like it's encoding R itself
 22 2019-11-20T00:32:53  <elichai2> What will be the security if you split e up?
 23 2019-11-20T00:33:06  <sipa> what do you mean split e up?
 24 2019-11-20T00:33:21  <elichai2> I.e verify like this: e==R.x[:32]
 25 2019-11-20T00:33:25  <elichai2> Or something like that
 26 2019-11-20T00:33:37  <elichai2> Can you make "short ecdsa signatures"?
 27 2019-11-20T00:34:00  <sipa> that's a great question
 28 2019-11-20T00:34:09  <elichai2> * e==R.x[:16]
 29 2019-11-20T00:34:10  <sipa> but it's hard to answer without an accepted security proof
 30 2019-11-20T00:34:49  <sipa> like... as far as provable security goes, under standard assumptions, ECDSA is insecure with either a short or a long 'e' :p
 31 2019-11-20T00:35:23  <elichai2> It's easier to think with hash functions, but shortening a point seems scary lol (in terms of uniformity)
 32 2019-11-20T00:35:42  <elichai2> Lol yeah
 33 2019-11-20T00:36:07  <sipa> ok, let's redefine ECDSA signatures as (e,s) for which H((mG + eP)/s) = e
 34 2019-11-20T00:36:19  <sipa> so replacing "x coordinate of" with a hash function
 35 2019-11-20T00:36:38  <elichai2> Hmm that sounds like you can just use a shorter hash
 36 2019-11-20T00:36:43  <sipa> which is *not* ECDSA, to be clear
 37 2019-11-20T00:37:14  <elichai2> Haven't read Bone's paper on the requirement of hash functions for schnorr sigs so idk what's the proofs there and if they could be applied
 38 2019-11-20T00:37:31  <sipa> http://www.neven.org/papers/schnorr.pdf ?
 39 2019-11-20T00:37:36  <elichai2> Yes
 40 2019-11-20T00:37:45  <sipa> no Bone involved
 41 2019-11-20T00:37:47  <elichai2> Ops no Bone
 42 2019-11-20T00:37:55  <elichai2> Neven == Bone :P
 43 2019-11-20T00:37:59  <sipa> also, do you mean Boneh?
 44 2019-11-20T00:38:15  <elichai2> (for some reason in my mind lol)
 45 2019-11-20T00:38:31  <elichai2> Yes you'll need to excuse me, it's 3am here heh
 46 2019-11-20T00:39:27  <elichai2> That's why https://eprint.iacr.org/2018/483
 47 2019-11-20T00:39:43  <elichai2> Got me confused that this was also Neven+Boneh
 48 2019-11-20T00:51:33  *** pglazman has joined ##taproot-bip-review
 49 2019-11-20T01:02:05  *** andrewtoth has quit IRC
 50 2019-11-20T01:02:31  *** andrewtoth has joined ##taproot-bip-review
 51 2019-11-20T01:25:45  <luke-jr> this channel should be logged :/
 52 2019-11-20T01:25:54  <aj> it is logged?
 53 2019-11-20T01:26:03  <harding> http://www.erisian.com.au/taproot-bip-review/
 54 2019-11-20T01:26:46  *** ChanServ sets mode: +o harding
 55 2019-11-20T01:27:10  *** harding changes topic to "Discussion about the Taproot BIP Reviews.  More information: https://github.com/ajtowns/taproot-review; logs: http://www.erisian.com.au/taproot-bip-review/ ; meeting logs: http://www.erisian.com.au/meetbot/taproot-bip-review/2019"
 56 2019-11-20T01:27:24  *** harding sets mode: -o harding
 57 2019-11-20T02:07:14  *** pglazman has quit IRC
 58 2019-11-20T02:42:51  *** pglazman has joined ##taproot-bip-review
 59 2019-11-20T03:25:02  *** gmaxwell has joined ##taproot-bip-review
 60 2019-11-20T03:35:03  <gmaxwell> sipa: https://pdfs.semanticscholar.org/7d54/3246aedff2a9bea4a9a964691126a0f3e050.pdf gives a concrete attack on shortned schnorr signatures, under a very slightly contrived hash function that meets the security requirements normally used in proofs for full length schnorr signatures. Thus proving they are weaker and more fragile, if not showing they are pratically so.
 61 2019-11-20T03:35:33  <gmaxwell> I believe there exists another paper that shows them insecure in a musig-ish sort of setting with an attack like nicker's recent blockstream blogpost.
 62 2019-11-20T03:36:05  <gmaxwell> I vaguely recall there being another attack that I can't find that Adam Back had mentioned previously, so you might want to ask him.
 63 2019-11-20T03:38:29  <gmaxwell> nothingmuch: you mentioned orphaning a number of times but typically signatures are not sent with blocks, but well before them in loose transactions. I think it's unlikely that saving 16 bytes per signature would make a difference in the common case.  (and against some attack block specifically constructed to not have prepropagated data, the attacker could stuff with whatever they want).
 64 2019-11-20T03:39:43  *** pglazman has quit IRC
 65 2019-11-20T03:39:58  <gmaxwell> nothingmuch: also in the long run I expect that on 'a longer time horizon' aggregation would be used, which makes the small offsets in the signature size more irrelevant.
 66 2019-11-20T03:41:13  *** pglazman has joined ##taproot-bip-review
 67 2019-11-20T03:41:16  <gmaxwell> Also, wrt batching, it's a rather large speedup... and in particular,  the taproot check as well as future musig combining for aggregation can be combined into a common batch operation, allowing biger batches in practice for more speeup.
 68 2019-11-20T03:44:13  <gmaxwell> waxwing
 69 2019-11-20T03:44:30  <gmaxwell> waxwing: RFC6979 is awful for complicated political reasons.
 70 2019-11-20T03:46:11  <gmaxwell> waxwing: essentially, it wanted to use an unmodified NIST approved random generation function exactly like it's supposted to be use, with the message/key as the freeform random inputs ... so that FIPS certified stuff could use it while retaining their FIPS certification.
 71 2019-11-20T03:47:17  <gmaxwell> It also has to deal with NIST curves, most (all?) of which have N such that the size is really far from a power of two, and bias is a real concern.
 72 2019-11-20T03:49:04  <gmaxwell> the bip-schnorr recommended nonce procedure is the same (IIRC) as the EdDSA one.
 73 2019-11-20T03:49:26  <gmaxwell> (except for the whole prehashing the secret part, which isn't compatible with ... well.. anything interesting)
 74 2019-11-20T03:49:35  *** pglazman has quit IRC
 75 2019-11-20T03:53:00  <nothingmuch> gmaxwell: yes, i later realized compact blocks completely moot my point ;-)
 76 2019-11-20T03:53:45  <nothingmuch> s/point/concern/;
 77 2019-11-20T03:56:22  <nothingmuch> i suppose that flawed assumption being interpreted too charitably by nickler and sipa was why i felt i needed to follow up
 78 2019-11-20T03:58:26  <gmaxwell> well bandwith is certantly an issue too, orphaning aside.
 79 2019-11-20T03:58:54  <gmaxwell> There is actually a third design option that wasn't mentioned. Which is esentially use a short schnorr signature but communicate in r,s form.
 80 2019-11-20T03:59:01  *** shesek has joined ##taproot-bip-review
 81 2019-11-20T03:59:30  <gmaxwell> This would give all the batch advantages, but if you really cared about space or bandwidth, you could convert to short e,s form for communication/storage an convert back for checking hashes.
 82 2019-11-20T04:00:00  <gmaxwell> The reason I never promoted that is because I consider the shortned schnorr signature security story, at least at the 256 bit security level, kinda dubious.
 83 2019-11-20T04:00:24  <sipa> * 128 security level
 84 2019-11-20T04:00:31  <gmaxwell> If we were talking about a 448 bit curve or something, then I think a shortned signature might be more interesting.
 85 2019-11-20T04:00:49  *** pglazman has joined ##taproot-bip-review
 86 2019-11-20T04:02:44  <gmaxwell> also, if you really prefer saving 16 bytes over a factor of 2 validation speed and don't care about less clear security properties... BLS signatures are the obvious thing to use instead of shortned schnorr.
 87 2019-11-20T04:06:38  *** HighOnBtc has quit IRC
 88 2019-11-20T04:10:32  <nothingmuch> gmaxwell: i'm having trouble understanding how those are interchangiable after staring at it for a while... is there a name for this variant i could look up?
 89 2019-11-20T04:11:10  <sipa> nothingmuch: interchange what with what?
 90 2019-11-20T04:11:13  <sipa> schnorr with bls?
 91 2019-11-20T04:12:09  <nothingmuch> no, <e,s> and <r,s> forms (is r a typo fo R here? or a differently defined scalar?)
 92 2019-11-20T04:12:22  <sipa> nothingmuch: in schnorr?
 93 2019-11-20T04:12:35  <sipa> it's the first paragraph in the bip
 94 2019-11-20T04:12:59  <nothingmuch> sipa: see gmaxwell's remark on third design option, 14 min ago
 95 2019-11-20T04:13:11  <sipa> e = hash(R || P || m)
 96 2019-11-20T04:13:38  <sipa> so you can convert (R, s) into (e, s) by just computing the hash of R||P||m
 97 2019-11-20T04:13:46  <nothingmuch> initially i assumed R,s was meant, but i don't see how you can convert back from e,s to R,s form
 98 2019-11-20T04:14:11  <sipa> and convert (e, s) into (R, s) by computing R = sG - eP
 99 2019-11-20T04:14:52  <nothingmuch> oh, right! i think this is an indication i should have gone to sleep a while aog
100 2019-11-20T04:14:57  <sipa> haha
101 2019-11-20T04:30:32  *** pglazman has quit IRC
102 2019-11-20T06:07:57  *** pglazman has joined ##taproot-bip-review
103 2019-11-20T06:44:43  *** kabaum has quit IRC
104 2019-11-20T07:00:56  *** Moller40 has quit IRC
105 2019-11-20T07:08:52  *** pglazman has quit IRC
106 2019-11-20T08:30:32  *** rottensox has quit IRC
107 2019-11-20T08:40:45  *** davterra has quit IRC
108 2019-11-20T08:41:56  *** davterra has joined ##taproot-bip-review
109 2019-11-20T09:35:09  *** kabaum has joined ##taproot-bip-review
110 2019-11-20T10:03:50  *** kabaum has quit IRC
111 2019-11-20T10:04:18  *** kabaum has joined ##taproot-bip-review
112 2019-11-20T10:45:14  <waxwing> aj, the feedback questionnaire requires an email address, is that really needed? i'm guessing it's just part of the interface of what you used and you didn't choose it?
113 2019-11-20T11:11:37  *** kabaum has quit IRC
114 2019-11-20T11:19:50  *** Chris_Stewart_5 has joined ##taproot-bip-review
115 2019-11-20T12:11:39  *** kabaum has joined ##taproot-bip-review
116 2019-11-20T12:13:15  *** andytoshi has joined ##taproot-bip-review
117 2019-11-20T12:13:15  *** andytoshi has joined ##taproot-bip-review
118 2019-11-20T12:32:37  *** Chris_Stewart_5 has quit IRC
119 2019-11-20T12:38:11  *** Chris_Stewart_5 has joined ##taproot-bip-review
120 2019-11-20T13:02:43  *** kabaum has quit IRC
121 2019-11-20T13:03:45  <nothingmuch> i have some very vague questions about the various extension mechanisms - the segwit version, the annex, the tapscript version, OP_SUCCESS* stuff, and finally key version (did i miss any?), and for most of these it's not clear to me when one is preferred over the other...
122 2019-11-20T13:06:26  <nothingmuch> also the sigops semantics mention key size but not key version, which implies key_version != 0 would not cause them to succeed - is that as intended?
123 2019-11-20T13:09:29  <nothingmuch> most confusingly i can't think of a use case for the annex that doesn't imply some other mechanism is also used, and i was also thrown off by the tapscript version being per leaf, since the script tree is a logical disjunction so i'd expect wallets would always want to know the exact definition of all leaves
124 2019-11-20T13:29:10  *** jonatack has joined ##taproot-bip-review
125 2019-11-20T13:37:54  <instagibbs_> nothingmuch, leaf version is defined at the "code block" or whatever it's called, so you cannot have different leaf versions per output
126 2019-11-20T13:39:24  <nothingmuch> instagibbs_: oh! thank you that makes more sense
127 2019-11-20T13:56:31  <instagibbs_> the annex, well, just think of any use where you'd want non-third-party malleable witness data.
128 2019-11-20T14:17:49  *** rottensox has joined ##taproot-bip-review
129 2019-11-20T14:19:48  <nothingmuch> instagibbs_: i think i don't understand how that's qualitatively different than adding other elements to the witness stack but assuming different tapscript version instead of consensus rule that adds meaning to the annex?
130 2019-11-20T14:24:07  *** shesek has quit IRC
131 2019-11-20T14:24:31  *** shesek has joined ##taproot-bip-review
132 2019-11-20T14:39:27  *** daniel__ has quit IRC
133 2019-11-20T14:41:54  *** kabaum has joined ##taproot-bip-review
134 2019-11-20T14:50:59  *** HighOnBtc has joined ##taproot-bip-review
135 2019-11-20T15:07:13  *** andrewtoth_ has joined ##taproot-bip-review
136 2019-11-20T15:08:08  *** andrewtoth has quit IRC
137 2019-11-20T15:10:10  *** andrewtoth_ has quit IRC
138 2019-11-20T15:10:57  *** Chris_Stewart_5 has quit IRC
139 2019-11-20T15:21:17  *** Chris_Stewart_5 has joined ##taproot-bip-review
140 2019-11-20T15:26:53  *** andrewtoth has joined ##taproot-bip-review
141 2019-11-20T15:34:26  *** jonatack has quit IRC
142 2019-11-20T15:38:56  *** mryandao has quit IRC
143 2019-11-20T15:39:24  *** afk11 has quit IRC
144 2019-11-20T15:39:52  *** sipa has quit IRC
145 2019-11-20T15:40:06  *** Chris_Stewart_5 has quit IRC
146 2019-11-20T15:40:20  *** andrewtoth has quit IRC
147 2019-11-20T15:43:10  *** mryandao has joined ##taproot-bip-review
148 2019-11-20T15:43:33  *** afk11 has joined ##taproot-bip-review
149 2019-11-20T15:46:45  *** sipa has joined ##taproot-bip-review
150 2019-11-20T15:50:26  <ZmnSCPxj_> nothingmuch: annexes are attested to by any signatures checked; other elements on the witness stack may have looser requirements
151 2019-11-20T16:01:15  *** ajonas has quit IRC
152 2019-11-20T16:05:38  *** jonatack has joined ##taproot-bip-review
153 2019-11-20T16:06:37  *** kabaum has quit IRC
154 2019-11-20T16:15:18  <sipa> nothingmuch: the difference is that the annex is independent of script
155 2019-11-20T16:15:40  <sipa> as it does not become a stack element for script
156 2019-11-20T16:16:07  <sipa> it's more a txin-level extension (like nSequence)
157 2019-11-20T16:17:31  *** Chris_Stewart_5 has joined ##taproot-bip-review
158 2019-11-20T16:22:23  *** andrewtoth has joined ##taproot-bip-review
159 2019-11-20T16:28:09  <sipa> as for what upgrade mechanism to use for what:
160 2019-11-20T16:29:10  <sipa> * OP_SUCCESSx to introduce new opcodes in script, as it permots doing so without incrementing any version numbers or whatnot
161 2019-11-20T16:30:50  <sipa> * Upgradable pubkey types to introduce new digital signature schemes. OP_SUCCESSx can also be used for those, but you'd need to add an equivalent to all 3 (CHECKSIG, CHECKSIGVERIFY, CHECKSIGADD) every time
162 2019-11-20T16:31:27  *** HighOnBtc has quit IRC
163 2019-11-20T16:33:50  <sipa> * Leaf versions are better for large structural changes to script that aren't just introducing new opcodes (this can also be done using OP_SUCCESSx, but there were a few unused bits in the control block, so better use it)
164 2019-11-20T16:35:56  <sipa> * witness versions and witness prpgram length can be changed to replace the taproot structure with something else (e.g. something adding graftroot or cross-input aggregation)
165 2019-11-20T16:59:52  <nothingmuch> ZmnSCPxj_, sipa: thanks that cleared up the differences
166 2019-11-20T17:01:12  *** michaelfolkson has joined ##taproot-bip-review
167 2019-11-20T17:01:18  <nothingmuch> what's the advantage of introducing new opcodes without incrementing version numbers?
168 2019-11-20T17:03:25  <nothingmuch> regarding new pubkey types, is the assumption that key_version != 0 data will never be 32 bytes in length? (ignoring the OP_SUCCESS possibility)
169 2019-11-20T17:04:32  <instagibbs_> nothingmuch, more flexible deployment I think, and preserve's the leaf version byte for bigger upgrades
170 2019-11-20T17:04:37  *** michaelfolkson has quit IRC
171 2019-11-20T17:05:23  <sipa> nothingmuch: version numbers are limited and require serialized deployment
172 2019-11-20T17:05:26  <nothingmuch> also i realized my misunderstanding re key_version, it's only in the digest, right?
173 2019-11-20T17:05:56  <sipa> "vX is these opcodes, v(X+1) is all those plus Y, v(X+2) adds these additional ones"
174 2019-11-20T17:06:25  <sipa> nothingmuch: yes, key version is just in the sighash
175 2019-11-20T17:06:42  <sipa> and yes, new key types will use a length different from 32
176 2019-11-20T17:07:05  *** michaelfolkson has joined ##taproot-bip-review
177 2019-11-20T17:09:54  <sipa> nothingmuch: while with OP_SUCCESSx you just introduce a new opcode, potentially even in parallel with other ones already in the pipeline
178 2019-11-20T17:10:13  <nothingmuch> is it fair to say different rule sets can be partially ordered by the ops that they used, and these incomparability classes are totally ordered by leaf version numbers?
179 2019-11-20T17:10:38  <sipa> ... mostly
180 2019-11-20T17:11:05  <sipa> of course, you could also say "this bit in the leaf version has this effect, and independently this bit has another effect"
181 2019-11-20T17:11:07  <nothingmuch> because leaf version increments may not be monotone?
182 2019-11-20T17:11:12  <sipa> right
183 2019-11-20T17:11:17  <nothingmuch> ah, right
184 2019-11-20T17:12:16  <sipa> but both op_successx and leaf versions can be used to effectively.completely replace the script language with something else, if desired
185 2019-11-20T17:12:31  <sipa> it's just more natural to do it with leaf versions
186 2019-11-20T17:15:13  <nothingmuch> yeah i was a bit surprised that OP_SUCCESSx was syntactically such a departure from NOPs, despite being superficially similar, but it seems like a more sensible design
187 2019-11-20T17:15:42  <sipa> they're so much more powerful
188 2019-11-20T17:19:38  <nothingmuch> so for a hypothetical future soft fork, the choice mainly comes down to whether or not new rules can be made to naturally compose with existing opcodes (in which case OP_SUCCESS), if not but it still fits in with the execution model & tx structure (handwavy), leaf version, falling back to witness version?
189 2019-11-20T17:24:24  <sipa> right, but there is a huge difference beteeen using a new witness version and a leaf version
190 2019-11-20T17:25:18  <sipa> the former is only revealed to the network when spending (and because different leaves can have a different leaf version, only when a script that actually uses it), while a new witness version is visible to the network at creation time
191 2019-11-20T17:27:59  <nothingmuch> wait since leaf version is provided at spend time, doesn't that mean that non-monotone ruleset changes wrt to leaf version may be unsafe, since they can change intended spending conditions at output creation?
192 2019-11-20T17:29:00  <sipa> nobody will create a script with an undefined leaf version
193 2019-11-20T17:29:19  <nothingmuch> ah i see, the tree also commits to it
194 2019-11-20T17:29:26  <sipa> the one creating the address knows all the leaf versions potentially involved in it
195 2019-11-20T17:29:29  <sipa> yeah
196 2019-11-20T17:30:05  <nothingmuch> sorry, i misinterpreted instagibbs_'s correction of my misunderstanding above
197 2019-11-20T17:31:17  <nothingmuch> (as saying leaf version was in the codeblock *instead* of tree, and i thought i just invented the version in the tree)
198 2019-11-20T17:31:30  <nothingmuch> ok i think that's finally everything i'm confused about sorted, but i'm sure there will be more =)
199 2019-11-20T17:41:54  *** mryandao has quit IRC
200 2019-11-20T17:42:12  *** mryandao has joined ##taproot-bip-review
201 2019-11-20T17:59:57  *** sanoj has joined ##taproot-bip-review
202 2019-11-20T18:01:51  *** pglazman has joined ##taproot-bip-review
203 2019-11-20T18:15:03  *** afk11 has quit IRC
204 2019-11-20T18:15:54  *** afk11 has joined ##taproot-bip-review
205 2019-11-20T18:22:23  *** davterra has quit IRC
206 2019-11-20T18:22:51  *** davterra has joined ##taproot-bip-review
207 2019-11-20T18:40:35  *** Chris_Stewart_5 has quit IRC
208 2019-11-20T18:41:41  <ZmnSCPxj_> re: but both op_successx and leaf versions can be used to effectively.completely replace the script language with something else, if desired
209 2019-11-20T18:42:19  <ZmnSCPxj_> It is possible to define an op_successx such that the rest of the program after it will be written in a different language other than Bitcoin SCRIPT.
210 2019-11-20T18:42:40  <ZmnSCPxj_> Thus it is possible to completely replace the script language using op_successx
211 2019-11-20T18:43:18  <ZmnSCPxj_> This remains compatible with existing SCRIPT interpreters, as they will stop parsing with a success upon reading any OP_SUCCESSX.
212 2019-11-20T18:43:47  *** Chris_Stewart_5 has joined ##taproot-bip-review
213 2019-11-20T18:43:52  <sipa> ZmnSCPxj_: yeah, that's what i was referring to
214 2019-11-20T18:44:29  <sipa> the fact that op_successx is processed before actual execution starts means it can be used to redfine all of script (though in a slightly convoluted way)
215 2019-11-20T18:55:53  <nothingmuch> ZmnSCPxj_: isn't it the entire program, not just the rest of the program after it?
216 2019-11-20T18:56:25  <nothingmuch> that said, the motivation behind this mechanism is so that defining new opcodes that are largely compatible can be done with minimal changes to interpreters when appropriate, right?
217 2019-11-20T18:57:27  <sipa> nothingmuch: no, any OP_SUCCESSx anywhere in the program (even in otherwise seemingly unexecuted branches) will cause instant success
218 2019-11-20T18:57:51  <sipa> oh, sorry, you were correcting ZmnSCPxj_ on this
219 2019-11-20T18:57:56  *** kabaum has joined ##taproot-bip-review
220 2019-11-20T18:58:21  <nothingmuch> (iow remotivation, generally that should not be desired, since leaf version can be changed instead)
221 2019-11-20T18:59:34  <sipa> nothingmuch: the idea is that e.g. it can be used so that a new opcode changes overall semantics (e.g. a new 64-bit OP_ADD64 could lift restrictions on the size of numeric values everywhere)
222 2019-11-20T18:59:52  <sipa> i agree this is somewhat less necessary due to leaf versions
223 2019-11-20T19:02:05  <nothingmuch> is it accurate that an interpreter that has an additional opcode that does not interact like that should be able to interpret old programs with no considerations apart from what block height the opcode comes into effect?
224 2019-11-20T19:02:37  <nothingmuch> s/has/supports/
225 2019-11-20T19:03:02  <sipa> i don't understand your question
226 2019-11-20T19:04:54  <nothingmuch> suppose there is a soft fork that adds OP_FOO which asserts something about the annex for instance, and does not change semantics globally, after that definition has been added to the interperter's implementation are there additional considerations re compatibility apart from when that individual opcode was added?
227 2019-11-20T19:06:06  <sipa> if it's redefining an OP_SUCCESSx, there should be no considerations - as the mere presence of an OP_SUCCESSx before meant it was an automatic success to spend
228 2019-11-20T19:06:19  <nothingmuch> i'm trying to think whether that can interfere with validation of scripts before this OP_FOO soft fork is activated (seems not)
229 2019-11-20T19:07:05  <nothingmuch> so then suppose there is both OP_FOO and OP_BAR, - the implementations should likewise be compatible regardless of the order they actually get activated, right?
230 2019-11-20T19:07:24  <sipa> well of course the implementation must make sure that script semantics prior to the softfork are unaffected by the introduction of OP_FOO
231 2019-11-20T19:08:11  <sipa> but that's relatively easy in many cases (e.g. change a "return true;" to "if (softfork) { ... } else { return true; }")
232 2019-11-20T19:08:28  *** michaelfolkson has quit IRC
233 2019-11-20T19:08:39  <nothingmuch> is it fair to say that OP_SUCCESS is specifically intended softforks that should not affect semantics in that way? (since otherwise might as well change leaf version?)
234 2019-11-20T19:09:15  <sipa> the leaf version only has 5 bits
235 2019-11-20T19:11:06  <nothingmuch> i guess this question is too vague, but basically "if desired" - apart from conserving leaf version bits is there any reason to do that?
236 2019-11-20T19:12:08  <sipa> i think OP_SUCCESSx is designed for everything: it can be used for otherwise-non-interacting-opcodes or for large-redesigns-of-script
237 2019-11-20T19:12:23  <instagibbs_> parallel softfork proposals for two op_success redefinitions(provide they don't conflict) vs conflicting leafe version
238 2019-11-20T19:12:37  <sipa> leaf versions are just a "we have 5 unused bits, might as well turn them into an extension mechanism as well"
239 2019-11-20T19:26:44  *** jonatack has quit IRC
240 2019-11-20T19:32:54  *** HighOnBtc has joined ##taproot-bip-review
241 2019-11-20T20:11:27  *** pglazman has quit IRC
242 2019-11-20T20:15:42  *** michaelfolkson has joined ##taproot-bip-review
243 2019-11-20T20:29:09  *** michaelfolkson has quit IRC
244 2019-11-20T20:30:44  *** michaelfolkson has joined ##taproot-bip-review
245 2019-11-20T20:39:41  *** pglazman has joined ##taproot-bip-review
246 2019-11-20T21:05:48  *** pglazman has quit IRC
247 2019-11-20T21:22:46  *** pglazman has joined ##taproot-bip-review
248 2019-11-20T21:56:00  *** jonatack has joined ##taproot-bip-review
249 2019-11-20T21:56:27  *** jonatack has quit IRC
250 2019-11-20T22:02:20  *** jonatack has joined ##taproot-bip-review
251 2019-11-20T22:05:39  *** afk11 has quit IRC
252 2019-11-20T22:05:39  *** mryandao has quit IRC
253 2019-11-20T22:05:48  *** andrewtoth has quit IRC
254 2019-11-20T22:06:52  *** afk11 has joined ##taproot-bip-review
255 2019-11-20T22:06:55  *** mryandao has joined ##taproot-bip-review
256 2019-11-20T22:10:54  *** michaelfolkson has quit IRC
257 2019-11-20T22:25:38  *** Chris_Stewart_5 has quit IRC
258 2019-11-20T22:41:08  *** pinheadmz has quit IRC
259 2019-11-20T23:57:09  *** pinheadmz has joined ##taproot-bip-review