12019-11-20T00:11:19  <elichai2> sipa: I just went over the meeting, awesome explanations :)
  22019-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
  32019-11-20T00:12:05  <elichai2> (I'm actually not sure I looked at the signing mult function in libsecp)
  42019-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)
  52019-11-20T00:16:35  <elichai2> At least that's my understanding (which I might be wrong :) )
  62019-11-20T00:18:46  <sipa> elichai2: i don't understand
  72019-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)
  82019-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)
  92019-11-20T00:22:22  <elichai2> Isn't that just because ecdsa is multiplied by the multiplicative inverse of the nonce?
 102019-11-20T00:22:49  <elichai2> Arghh I confused myself
 112019-11-20T00:23:07  <sipa> ECDSA effectively uses r=R.x as challenge
 122019-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)
 132019-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)
 142019-11-20T00:27:53  <elichai2> The fact that the nonce is by itself in schnorr helps a lot
 152019-11-20T00:29:24  <sipa> the equation is sR = mG + rP, where R is some point whose X coordinate is r
 162019-11-20T00:30:14  <sipa> treating ECDSA as "(R, s)": compute r=R.x, and verify the equation
 172019-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
 182019-11-20T00:30:55  <elichai2> Am I understanding correctly?
 192019-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
 202019-11-20T00:31:45  <sipa> i'm saying the opposite: ECDSA is actually already in (e, s) form (if you call e=R.x)
 212019-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
 222019-11-20T00:32:53  <elichai2> What will be the security if you split e up?
 232019-11-20T00:33:06  <sipa> what do you mean split e up?
 242019-11-20T00:33:21  <elichai2> I.e verify like this: e==R.x[:32]
 252019-11-20T00:33:25  <elichai2> Or something like that
 262019-11-20T00:33:37  <elichai2> Can you make "short ecdsa signatures"?
 272019-11-20T00:34:00  <sipa> that's a great question
 282019-11-20T00:34:09  <elichai2> * e==R.x[:16]
 292019-11-20T00:34:10  <sipa> but it's hard to answer without an accepted security proof
 302019-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
 312019-11-20T00:35:23  <elichai2> It's easier to think with hash functions, but shortening a point seems scary lol (in terms of uniformity)
 322019-11-20T00:35:42  <elichai2> Lol yeah
 332019-11-20T00:36:07  <sipa> ok, let's redefine ECDSA signatures as (e,s) for which H((mG + eP)/s) = e
 342019-11-20T00:36:19  <sipa> so replacing "x coordinate of" with a hash function
 352019-11-20T00:36:38  <elichai2> Hmm that sounds like you can just use a shorter hash
 362019-11-20T00:36:43  <sipa> which is *not* ECDSA, to be clear
 372019-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
 382019-11-20T00:37:31  <sipa> http://www.neven.org/papers/schnorr.pdf ?
 392019-11-20T00:37:36  <elichai2> Yes
 402019-11-20T00:37:45  <sipa> no Bone involved
 412019-11-20T00:37:47  <elichai2> Ops no Bone
 422019-11-20T00:37:55  <elichai2> Neven == Bone :P
 432019-11-20T00:37:59  <sipa> also, do you mean Boneh?
 442019-11-20T00:38:15  <elichai2> (for some reason in my mind lol)
 452019-11-20T00:38:31  <elichai2> Yes you'll need to excuse me, it's 3am here heh
 462019-11-20T00:39:27  <elichai2> That's why https://eprint.iacr.org/2018/483
 472019-11-20T00:39:43  <elichai2> Got me confused that this was also Neven+Boneh
 482019-11-20T00:51:33  *** pglazman has joined ##taproot-bip-review
 492019-11-20T01:02:05  *** andrewtoth has quit IRC
 502019-11-20T01:02:31  *** andrewtoth has joined ##taproot-bip-review
 512019-11-20T01:25:45  <luke-jr> this channel should be logged :/
 522019-11-20T01:25:54  <aj> it is logged?
 532019-11-20T01:26:03  <harding> http://www.erisian.com.au/taproot-bip-review/
 542019-11-20T01:26:46  *** ChanServ sets mode: +o harding
 552019-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"
 562019-11-20T01:27:24  *** harding sets mode: -o harding
 572019-11-20T02:07:14  *** pglazman has quit IRC
 582019-11-20T02:42:51  *** pglazman has joined ##taproot-bip-review
 592019-11-20T03:25:02  *** gmaxwell has joined ##taproot-bip-review
 602019-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.
 612019-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.
 622019-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.
 632019-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).
 642019-11-20T03:39:43  *** pglazman has quit IRC
 652019-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.
 662019-11-20T03:41:13  *** pglazman has joined ##taproot-bip-review
 672019-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.
 682019-11-20T03:44:13  <gmaxwell> waxwing
 692019-11-20T03:44:30  <gmaxwell> waxwing: RFC6979 is awful for complicated political reasons.
 702019-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.
 712019-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.
 722019-11-20T03:49:04  <gmaxwell> the bip-schnorr recommended nonce procedure is the same (IIRC) as the EdDSA one.
 732019-11-20T03:49:26  <gmaxwell> (except for the whole prehashing the secret part, which isn't compatible with ... well.. anything interesting)
 742019-11-20T03:49:35  *** pglazman has quit IRC
 752019-11-20T03:53:00  <nothingmuch> gmaxwell: yes, i later realized compact blocks completely moot my point ;-)
 762019-11-20T03:53:45  <nothingmuch> s/point/concern/;
 772019-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
 782019-11-20T03:58:26  <gmaxwell> well bandwith is certantly an issue too, orphaning aside.
 792019-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.
 802019-11-20T03:59:01  *** shesek has joined ##taproot-bip-review
 812019-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.
 822019-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.
 832019-11-20T04:00:24  <sipa> * 128 security level
 842019-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.
 852019-11-20T04:00:49  *** pglazman has joined ##taproot-bip-review
 862019-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.
 872019-11-20T04:06:38  *** HighOnBtc has quit IRC
 882019-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?
 892019-11-20T04:11:10  <sipa> nothingmuch: interchange what with what?
 902019-11-20T04:11:13  <sipa> schnorr with bls?
 912019-11-20T04:12:09  <nothingmuch> no, <e,s> and <r,s> forms (is r a typo fo R here? or a differently defined scalar?)
 922019-11-20T04:12:22  <sipa> nothingmuch: in schnorr?
 932019-11-20T04:12:35  <sipa> it's the first paragraph in the bip
 942019-11-20T04:12:59  <nothingmuch> sipa: see gmaxwell's remark on third design option, 14 min ago
 952019-11-20T04:13:11  <sipa> e = hash(R || P || m)
 962019-11-20T04:13:38  <sipa> so you can convert (R, s) into (e, s) by just computing the hash of R||P||m
 972019-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
 982019-11-20T04:14:11  <sipa> and convert (e, s) into (R, s) by computing R = sG - eP
 992019-11-20T04:14:52  <nothingmuch> oh, right! i think this is an indication i should have gone to sleep a while aog
1002019-11-20T04:14:57  <sipa> haha
1012019-11-20T04:30:32  *** pglazman has quit IRC
1022019-11-20T06:07:57  *** pglazman has joined ##taproot-bip-review
1032019-11-20T06:44:43  *** kabaum has quit IRC
1042019-11-20T07:00:56  *** Moller40 has quit IRC
1052019-11-20T07:08:52  *** pglazman has quit IRC
1062019-11-20T08:30:32  *** rottensox has quit IRC
1072019-11-20T08:40:45  *** davterra has quit IRC
1082019-11-20T08:41:56  *** davterra has joined ##taproot-bip-review
1092019-11-20T09:35:09  *** kabaum has joined ##taproot-bip-review
1102019-11-20T10:03:50  *** kabaum has quit IRC
1112019-11-20T10:04:18  *** kabaum has joined ##taproot-bip-review
1122019-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?
1132019-11-20T11:11:37  *** kabaum has quit IRC
1142019-11-20T11:19:50  *** Chris_Stewart_5 has joined ##taproot-bip-review
1152019-11-20T12:11:39  *** kabaum has joined ##taproot-bip-review
1162019-11-20T12:13:15  *** andytoshi has joined ##taproot-bip-review
1172019-11-20T12:13:15  *** andytoshi has joined ##taproot-bip-review
1182019-11-20T12:32:37  *** Chris_Stewart_5 has quit IRC
1192019-11-20T12:38:11  *** Chris_Stewart_5 has joined ##taproot-bip-review
1202019-11-20T13:02:43  *** kabaum has quit IRC
1212019-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...
1222019-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?
1232019-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
1242019-11-20T13:29:10  *** jonatack has joined ##taproot-bip-review
1252019-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
1262019-11-20T13:39:24  <nothingmuch> instagibbs_: oh! thank you that makes more sense
1272019-11-20T13:56:31  <instagibbs_> the annex, well, just think of any use where you'd want non-third-party malleable witness data.
1282019-11-20T14:17:49  *** rottensox has joined ##taproot-bip-review
1292019-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?
1302019-11-20T14:24:07  *** shesek has quit IRC
1312019-11-20T14:24:31  *** shesek has joined ##taproot-bip-review
1322019-11-20T14:39:27  *** daniel__ has quit IRC
1332019-11-20T14:41:54  *** kabaum has joined ##taproot-bip-review
1342019-11-20T14:50:59  *** HighOnBtc has joined ##taproot-bip-review
1352019-11-20T15:07:13  *** andrewtoth_ has joined ##taproot-bip-review
1362019-11-20T15:08:08  *** andrewtoth has quit IRC
1372019-11-20T15:10:10  *** andrewtoth_ has quit IRC
1382019-11-20T15:10:57  *** Chris_Stewart_5 has quit IRC
1392019-11-20T15:21:17  *** Chris_Stewart_5 has joined ##taproot-bip-review
1402019-11-20T15:26:53  *** andrewtoth has joined ##taproot-bip-review
1412019-11-20T15:34:26  *** jonatack has quit IRC
1422019-11-20T15:38:56  *** mryandao has quit IRC
1432019-11-20T15:39:24  *** afk11 has quit IRC
1442019-11-20T15:39:52  *** sipa has quit IRC
1452019-11-20T15:40:06  *** Chris_Stewart_5 has quit IRC
1462019-11-20T15:40:20  *** andrewtoth has quit IRC
1472019-11-20T15:43:10  *** mryandao has joined ##taproot-bip-review
1482019-11-20T15:43:33  *** afk11 has joined ##taproot-bip-review
1492019-11-20T15:46:45  *** sipa has joined ##taproot-bip-review
1502019-11-20T15:50:26  <ZmnSCPxj_> nothingmuch: annexes are attested to by any signatures checked; other elements on the witness stack may have looser requirements
1512019-11-20T16:01:15  *** ajonas has quit IRC
1522019-11-20T16:05:38  *** jonatack has joined ##taproot-bip-review
1532019-11-20T16:06:37  *** kabaum has quit IRC
1542019-11-20T16:15:18  <sipa> nothingmuch: the difference is that the annex is independent of script
1552019-11-20T16:15:40  <sipa> as it does not become a stack element for script
1562019-11-20T16:16:07  <sipa> it's more a txin-level extension (like nSequence)
1572019-11-20T16:17:31  *** Chris_Stewart_5 has joined ##taproot-bip-review
1582019-11-20T16:22:23  *** andrewtoth has joined ##taproot-bip-review
1592019-11-20T16:28:09  <sipa> as for what upgrade mechanism to use for what:
1602019-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
1612019-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
1622019-11-20T16:31:27  *** HighOnBtc has quit IRC
1632019-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)
1642019-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)
1652019-11-20T16:59:52  <nothingmuch> ZmnSCPxj_, sipa: thanks that cleared up the differences
1662019-11-20T17:01:12  *** michaelfolkson has joined ##taproot-bip-review
1672019-11-20T17:01:18  <nothingmuch> what's the advantage of introducing new opcodes without incrementing version numbers?
1682019-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)
1692019-11-20T17:04:32  <instagibbs_> nothingmuch, more flexible deployment I think, and preserve's the leaf version byte for bigger upgrades
1702019-11-20T17:04:37  *** michaelfolkson has quit IRC
1712019-11-20T17:05:23  <sipa> nothingmuch: version numbers are limited and require serialized deployment
1722019-11-20T17:05:26  <nothingmuch> also i realized my misunderstanding re key_version, it's only in the digest, right?
1732019-11-20T17:05:56  <sipa> "vX is these opcodes, v(X+1) is all those plus Y, v(X+2) adds these additional ones"
1742019-11-20T17:06:25  <sipa> nothingmuch: yes, key version is just in the sighash
1752019-11-20T17:06:42  <sipa> and yes, new key types will use a length different from 32
1762019-11-20T17:07:05  *** michaelfolkson has joined ##taproot-bip-review
1772019-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
1782019-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?
1792019-11-20T17:10:38  <sipa> ... mostly
1802019-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"
1812019-11-20T17:11:07  <nothingmuch> because leaf version increments may not be monotone?
1822019-11-20T17:11:12  <sipa> right
1832019-11-20T17:11:17  <nothingmuch> ah, right
1842019-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
1852019-11-20T17:12:31  <sipa> it's just more natural to do it with leaf versions
1862019-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
1872019-11-20T17:15:42  <sipa> they're so much more powerful
1882019-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?
1892019-11-20T17:24:24  <sipa> right, but there is a huge difference beteeen using a new witness version and a leaf version
1902019-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
1912019-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?
1922019-11-20T17:29:00  <sipa> nobody will create a script with an undefined leaf version
1932019-11-20T17:29:19  <nothingmuch> ah i see, the tree also commits to it
1942019-11-20T17:29:26  <sipa> the one creating the address knows all the leaf versions potentially involved in it
1952019-11-20T17:29:29  <sipa> yeah
1962019-11-20T17:30:05  <nothingmuch> sorry, i misinterpreted instagibbs_'s correction of my misunderstanding above
1972019-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)
1982019-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 =)
1992019-11-20T17:41:54  *** mryandao has quit IRC
2002019-11-20T17:42:12  *** mryandao has joined ##taproot-bip-review
2012019-11-20T17:59:57  *** sanoj has joined ##taproot-bip-review
2022019-11-20T18:01:51  *** pglazman has joined ##taproot-bip-review
2032019-11-20T18:15:03  *** afk11 has quit IRC
2042019-11-20T18:15:54  *** afk11 has joined ##taproot-bip-review
2052019-11-20T18:22:23  *** davterra has quit IRC
2062019-11-20T18:22:51  *** davterra has joined ##taproot-bip-review
2072019-11-20T18:40:35  *** Chris_Stewart_5 has quit IRC
2082019-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
2092019-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.
2102019-11-20T18:42:40  <ZmnSCPxj_> Thus it is possible to completely replace the script language using op_successx
2112019-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.
2122019-11-20T18:43:47  *** Chris_Stewart_5 has joined ##taproot-bip-review
2132019-11-20T18:43:52  <sipa> ZmnSCPxj_: yeah, that's what i was referring to
2142019-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)
2152019-11-20T18:55:53  <nothingmuch> ZmnSCPxj_: isn't it the entire program, not just the rest of the program after it?
2162019-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?
2172019-11-20T18:57:27  <sipa> nothingmuch: no, any OP_SUCCESSx anywhere in the program (even in otherwise seemingly unexecuted branches) will cause instant success
2182019-11-20T18:57:51  <sipa> oh, sorry, you were correcting ZmnSCPxj_ on this
2192019-11-20T18:57:56  *** kabaum has joined ##taproot-bip-review
2202019-11-20T18:58:21  <nothingmuch> (iow remotivation, generally that should not be desired, since leaf version can be changed instead)
2212019-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)
2222019-11-20T18:59:52  <sipa> i agree this is somewhat less necessary due to leaf versions
2232019-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?
2242019-11-20T19:02:37  <nothingmuch> s/has/supports/
2252019-11-20T19:03:02  <sipa> i don't understand your question
2262019-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?
2272019-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
2282019-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)
2292019-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?
2302019-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
2312019-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; }")
2322019-11-20T19:08:28  *** michaelfolkson has quit IRC
2332019-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?)
2342019-11-20T19:09:15  <sipa> the leaf version only has 5 bits
2352019-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?
2362019-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
2372019-11-20T19:12:23  <instagibbs_> parallel softfork proposals for two op_success redefinitions(provide they don't conflict) vs conflicting leafe version
2382019-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"
2392019-11-20T19:26:44  *** jonatack has quit IRC
2402019-11-20T19:32:54  *** HighOnBtc has joined ##taproot-bip-review
2412019-11-20T20:11:27  *** pglazman has quit IRC
2422019-11-20T20:15:42  *** michaelfolkson has joined ##taproot-bip-review
2432019-11-20T20:29:09  *** michaelfolkson has quit IRC
2442019-11-20T20:30:44  *** michaelfolkson has joined ##taproot-bip-review
2452019-11-20T20:39:41  *** pglazman has joined ##taproot-bip-review
2462019-11-20T21:05:48  *** pglazman has quit IRC
2472019-11-20T21:22:46  *** pglazman has joined ##taproot-bip-review
2482019-11-20T21:56:00  *** jonatack has joined ##taproot-bip-review
2492019-11-20T21:56:27  *** jonatack has quit IRC
2502019-11-20T22:02:20  *** jonatack has joined ##taproot-bip-review
2512019-11-20T22:05:39  *** afk11 has quit IRC
2522019-11-20T22:05:39  *** mryandao has quit IRC
2532019-11-20T22:05:48  *** andrewtoth has quit IRC
2542019-11-20T22:06:52  *** afk11 has joined ##taproot-bip-review
2552019-11-20T22:06:55  *** mryandao has joined ##taproot-bip-review
2562019-11-20T22:10:54  *** michaelfolkson has quit IRC
2572019-11-20T22:25:38  *** Chris_Stewart_5 has quit IRC
2582019-11-20T22:41:08  *** pinheadmz has quit IRC
2592019-11-20T23:57:09  *** pinheadmz has joined ##taproot-bip-review