12019-11-12T00:51:23  *** Chris_Stewart_5 has quit IRC
  22019-11-12T01:20:57  *** HighOnBtc has quit IRC
  32019-11-12T01:25:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
  42019-11-12T02:38:03  *** Chris_Stewart_5 has quit IRC
  52019-11-12T07:42:47  *** jeremyrubin has joined ##taproot-bip-review
  62019-11-12T08:51:58  *** b10c has joined ##taproot-bip-review
  72019-11-12T09:04:53  *** jonatack has quit IRC
  82019-11-12T09:17:14  *** orfeas has joined ##taproot-bip-review
  92019-11-12T09:38:00  *** afk11 has quit IRC
 102019-11-12T09:38:00  *** mryandao has quit IRC
 112019-11-12T09:38:49  *** mryandao has joined ##taproot-bip-review
 122019-11-12T09:38:50  *** afk11 has joined ##taproot-bip-review
 132019-11-12T09:40:27  *** marcinja has quit IRC
 142019-11-12T09:43:13  *** marcinja has joined ##taproot-bip-review
 152019-11-12T09:45:53  *** jonatack has joined ##taproot-bip-review
 162019-11-12T10:10:26  *** xoyi- has joined ##taproot-bip-review
 172019-11-12T10:11:26  <xoyi-> sipa: would it make sense to reference BIP173 instead of BIP141 in "A Taproot output is a native SegWit output (see BIP141)", since BIP173 is more specific to that sentence?
 182019-11-12T10:34:57  <aj> xoyi-: 173 describes the address format (presented to users in wallets) rather than the scriptPubKey format which is what actually appears on chain, so 141 seems like a better fit
 192019-11-12T10:36:40  <xoyi-> ah right. Thanks for clarifying @aj
 202019-11-12T10:52:02  *** jeremyrubin has quit IRC
 212019-11-12T11:10:19  <waxwing> we (group 6) were confused about hash_type 0x00 - the taproot bip says the new tx digest has all the old sighash flags (1,2,3, +0x80) but this 0x00 seems to be a default, but it isn't explained what sighashing it refers to/defines?
 222019-11-12T11:10:28  <waxwing> feel like i must have missed something.
 232019-11-12T11:11:48  <aj> waxwing: bip-taproot "Signature validation rules" says when hash_type = 00
 242019-11-12T11:13:08  <waxwing> aj, yes that's what i/we read. i don't get it. what is this default value, what does it mean about sighashing? it's not the same as sighash_all (0x01), right?
 252019-11-12T11:13:34  <aj> waxwing: it is the same as sighash_all, except it's 64 bytes instead of 65 bytes
 262019-11-12T11:13:43  <waxwing> aj, ok. is that stated anywhere?
 272019-11-12T11:13:58  <waxwing> under 'hash_type' it says the legacy are still retained, including SIGHASH_ALL
 282019-11-12T11:14:34  <waxwing> so to me it was far from intuitive to infer that 0x00 had the same meaning (i felt i had to assume the opposite). again, i'm probably just being dumb :)
 292019-11-12T11:14:58  <aj> waxwing: i think you just have to read through the logic and see it behaves the same way?
 302019-11-12T11:15:40  <aj> waxwing: if you do SIGHASH_ALL | SIGHASH_ANYONECANPAY you get 0x81 but 0x80 isn't valid, which is another difference
 312019-11-12T11:15:59  <waxwing> aj, but where in 'Signature validation rules' does it tell you that it's ALL sighashing with 0x00?
 322019-11-12T11:16:24  <waxwing> it just says valid signature according to bip-schnorr and message set to transaction digest, but doesn't say which transaction digest right.
 332019-11-12T11:16:34  <aj> waxwing: i think rationale entry 11 is the most explicit comment.
 342019-11-12T11:17:08  <aj> waxwing: i meant if you read through the rules, 0x00 and 0x01 will give you the same semantics
 352019-11-12T11:17:34  <waxwing> well yes, it's the same thing: it was always absolutely clear that 0x00 is a default and that explains all the reasons. but i don't think that section tells you that 0x00 is a signature over the entire transaction (as sighash_all). does it?
 362019-11-12T11:18:45  <aj> waxwing: yeah, i think it just assumes you know which one's the most common type
 372019-11-12T11:19:07  <waxwing> aj, right. and that *might* be fine if it wasn't for the fact that it explicitly says 0x01 is retained as SIGHASH_ALL
 382019-11-12T11:19:21  <waxwing> that made me tend to discount the possibility that 0x00 was the same.
 392019-11-12T11:19:47  <waxwing> (point taken though about 0x80, 0x81)
 402019-11-12T11:20:19  <aj> waxwing: i think what you'd like to see is (a) an explicit "64-bytes sigs are SIGHASH_ALL" and (b) "why allow specifying SIGHASH_ALL as 65-bytes sig as well as 64-bytes sig?" in rationale?
 412019-11-12T11:21:08  <waxwing> i didn't think much about (b) tbh but perhaps. but yeah for sure (a), i am reasonably confident i am not the only reader who will be confused by that :)
 422019-11-12T11:21:27  <waxwing> i think one of the rationales already kinda covers (b), the one you mentioned prob.
 432019-11-12T11:23:05  <waxwing> on reflection i guess i was being a bit dumb .. i am sometimes too literal a reader. it would be pretty bizarre if it wasn't *ALL. but still, write it in I think.
 442019-11-12T11:23:23  <aj> yeah, i was surprised it's not stated
 452019-11-12T11:23:33  <aj> file a PR or issue?
 462019-11-12T11:23:59  <waxwing> so why do we still have 0x01 then? is it because of the ACP flag so you can get 0x81?
 472019-11-12T11:24:10  <waxwing> aj, sure i'll do it, thanks for your help
 482019-11-12T11:24:30  <aj> well having 0x01 matches SIGHASH_ALL as it currently exists
 492019-11-12T11:25:08  <waxwing> yes. not sure why that matters? new sig scheme and new digest? (so code isn't going to be the same anyway)
 502019-11-12T11:25:11  <aj> but you could have 64-bytes = hash_type=0x01, and not allow 0x01 in 65-byte sigs
 512019-11-12T11:25:27  <waxwing> yeah that's what would have felt a lot more natural
 522019-11-12T11:25:48  <waxwing> adding a new flag value with the same semantics as an old one, which is not removed seems weird
 532019-11-12T11:26:59  <aj> i think there might've been some discussion about being able to have 65-byte sig of any type so you didn't change fees, so /maybe/ there's a reason, but i certainly can't think of i tnow
 542019-11-12T11:36:06  <waxwing> Hmm now i read the "Transaction digest"/"Transaction data" section i see that it's been written without reference to *ALL, which makes sense - this means that you get default behaviour whether you have the 0x01 or the implicit 0x00. So technically you could argue the confusion isn't there.
 552019-11-12T11:36:20  <waxwing> But I'll still PR it because it's just one extra sentence and it'd avoid confusion.
 562019-11-12T11:43:58  <aj> waxwing: yeah, i think it's well defined, but it's not clear
 572019-11-12T11:47:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
 582019-11-12T12:37:25  *** HighOnBtc has joined ##taproot-bip-review
 592019-11-12T12:38:03  <sosthene> Thanks aj and waxwing, it's clear now
 602019-11-12T12:38:58  *** evoskuil[m] has quit IRC
 612019-11-12T12:39:58  <sosthene> I'm curious if there are still other reasons besides having 65 byte sig of any type
 622019-11-12T12:40:39  <sosthene> but that alone makes sense I guess
 632019-11-12T12:54:57  *** Chris_Stewart_5 has quit IRC
 642019-11-12T12:57:05  *** Chris_Stewart_5 has joined ##taproot-bip-review
 652019-11-12T13:10:47  *** udiWertheimer has joined ##taproot-bip-review
 662019-11-12T13:11:01  *** udiWertheimer_ has left ##taproot-bip-review
 672019-11-12T13:27:36  *** orfeas has quit IRC
 682019-11-12T13:43:56  *** evoskuil[m] has joined ##taproot-bip-review
 692019-11-12T14:02:06  *** orfeas has joined ##taproot-bip-review
 702019-11-12T14:26:04  *** jonatack has quit IRC
 712019-11-12T14:26:19  *** jonatack has joined ##taproot-bip-review
 722019-11-12T14:30:08  <instagibbs> is CastToBool defined in any BIP anywhere?
 732019-11-12T14:32:20  <instagibbs> I know where to find the code-based definition, just seemed like something that should be defined
 742019-11-12T14:35:06  <instagibbs> "called the tapscript and is decoded into opcodes, one by one" the context and footnotes make this more clear, but I think it should stress that this is not during script execution
 752019-11-12T14:42:26  <instagibbs> joke observation: if we ever get to gigameg blocks, we'll need to define what happens to `codeseparator_position` after 2^32 bytes.
 762019-11-12T14:47:57  *** pinheadmz has quit IRC
 772019-11-12T14:51:50  *** jonatack has quit IRC
 782019-11-12T15:02:22  *** HighOnBtc has quit IRC
 792019-11-12T15:10:31  <orfeas> compact_size() and CCompactSize are not defined in the 3 bips. Should there be a link to their definition?
 802019-11-12T15:23:14  *** xoyi- has quit IRC
 812019-11-12T15:54:51  *** orfeas has quit IRC
 822019-11-12T15:56:58  *** orfeas has joined ##taproot-bip-review
 832019-11-12T16:00:22  <waxwing> sosthene, oh i see, you mean like, you could always know the size is the same whatever type of signing you do. that seems pretty artificial to me. oh well, shrug, it's not a huge deal i guess.
 842019-11-12T16:07:06  <elichai2> orfeas: well AFAIK they're not defined anywhere. it's an implementation detail
 852019-11-12T16:09:02  <orfeas> elichai2: isn't it consensus-critical though?
 862019-11-12T16:10:05  <orfeas> I guess they are defined as in the reference implementation then
 872019-11-12T16:10:12  <elichai2> orfeas: the consensus code is very far from being properly defined
 882019-11-12T16:10:21  <elichai2> (outside of Core itself obviously)
 892019-11-12T16:11:50  <orfeas> would a footnote with a link to the relevant Core function make sense? or this opens a whole new can of worms?
 902019-11-12T16:15:03  *** jenseven has joined ##taproot-bip-review
 912019-11-12T16:16:46  <elichai2> that would be inconsistent with other PRs. i.e. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
 922019-11-12T16:19:47  <orfeas> thanks. one more question: why is "compact_size(size of s)" in "hashTapLeaf(l || compact_size(size of s) || s)"? To avoid length extension attacks?
 932019-11-12T16:21:35  <elichai2> because in bitoin core when you serialize a CScript you get Bytes((CCompactSize(script) || script))
 942019-11-12T16:22:26  <elichai2> a rule of thumb, if you see CCompactSize asusme it's an implementation detail :)
 952019-11-12T16:22:44  <elichai2> (and when there are no private data fields assume length extension attacks aren't interesting :) )
 962019-11-12T16:27:10  <elichai2> instagibbs: pretty sure `CastToBool` isn't defined outside of the codebase
 972019-11-12T16:29:37  <sipa> aj, waxwing hash type 0 is different from 1 simply to prevent malleating 64 byte sigs into 65 byte ones; they're otherwise identical in semantics
 982019-11-12T16:30:17  <sipa> they also match the current semantics where both 0 and 1 are valid hashtypes that correspond to SIGHASH_ALL
 992019-11-12T16:31:26  <waxwing> oh right you couldn't avoid that if you had 0x01 as hash_type in the default case, but now since it's covered by the digest algo you avoid having a 65 byte version valid where a 64 byte was created.
1002019-11-12T16:32:11  <waxwing> second sentence i didn't get, you're not saying 0x00 is a valid sighash byte currently?
1012019-11-12T16:32:51  <sipa> currently (in legacy and segwit v0) 0 is a valid sighash type
1022019-11-12T16:32:59  <sipa> with the same semantics as ALL
1032019-11-12T16:33:17  *** arik_ has quit IRC
1042019-11-12T16:33:29  <waxwing> oh i had no idea. is that ever used?
1052019-11-12T16:35:32  <sipa> maybe a better way of stating is that the only valid sighash types are 1-3 and 81-83, while 64 byte sigs implicitly behave the same as ALL, but use 0 as sighash value in the sighash algorithm to prevent malleability
1062019-11-12T16:35:42  <sipa> waxwing: i doubt it
1072019-11-12T16:36:55  *** jonatack has joined ##taproot-bip-review
1082019-11-12T16:37:02  <waxwing> weird. a big cause of my confusion was no doubt that i had never heard of that, nor seen it used. (but i'd still argue for adding some small note that clarifies.)
1092019-11-12T16:39:19  <sipa> agreed
1102019-11-12T16:43:17  <jonatack> instagibbs: was disconnected so this may be out of band, AFAIK CastToBool is only mentioned in bip-0141.mediawiki:107, and not defined
1112019-11-12T16:52:27  <sipa> it's implicitly defined by the source code, but i think it's worth spelling out exactly
1122019-11-12T17:16:48  <jonatack> src/script/interpreter.cpp:35:bool CastToBool(const valtype& vch)
1132019-11-12T17:24:54  *** orfeas has quit IRC
1142019-11-12T17:36:18  *** Chris_Stewart_5 has quit IRC
1152019-11-12T17:46:44  *** bjarnem has joined ##taproot-bip-review
1162019-11-12T17:54:48  *** Chris_Stewart_5 has joined ##taproot-bip-review
1172019-11-12T18:00:49  *** pyskell has quit IRC
1182019-11-12T18:01:57  <jnewbery> Hi folks. Next Q&A starts in one hour
1192019-11-12T18:22:56  *** jeremyrubin has joined ##taproot-bip-review
1202019-11-12T18:23:36  <jonatack> Q: where does the Python code in bip-taproot live? Aside from the function taproot_tree_helper, which I see a (different version of) in test/functional/test_framework/script.py, I'm not seeing the other code.
1212019-11-12T18:24:06  <jonatack> (grepping in the taproot branch of sipa/bitcoin)
1222019-11-12T18:24:29  <sipa> jonatack: all the "signing" code is in feature_taproot.py
1232019-11-12T18:24:36  <sipa> some of it can probably be abstracted out
1242019-11-12T18:29:43  <jonatack> sipa: ty. bip-taproot states "the output script can be computed using the following Python3 algorithms with helper functions from the bip-schnorr reference code"
1252019-11-12T18:30:16  <jonatack> perhaps a link... I don't see most of that code (as named)
1262019-11-12T18:32:34  <sipa> jonatack: oh! that's referring to https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
1272019-11-12T18:32:38  <sipa> not the bitcoin core branch
1282019-11-12T18:32:51  <sipa> i think?
1292019-11-12T18:33:32  *** pyskell has joined ##taproot-bip-review
1302019-11-12T18:33:32  *** pyskell has joined ##taproot-bip-review
1312019-11-12T18:35:16  <jonatack> hm! will pull down sipa/bips to grep it
1322019-11-12T18:40:54  <jonatack> no dice, for instance `git grep -ni taproot_tweak` only returns results in https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
1332019-11-12T18:41:53  <sipa> what specific function are you missing?
1342019-11-12T18:42:00  <sipa> or what reference is unexplained?
1352019-11-12T18:44:15  <jonatack> I was looking for where the code presented in bip-taproot lives, e.g. the functions taproot_tweak_*, taproot_sign_*, taproot_output_script
1362019-11-12T18:44:31  <sipa> they're in the bip?
1372019-11-12T18:44:42  <jonatack> Yes, only in the bip
1382019-11-12T18:44:59  <sipa> ah, you mean is there some python file you can use directly? no
1392019-11-12T18:45:02  <sipa> perhaps there should be
1402019-11-12T18:45:52  <jonatack> Thought it might be extracted from elsewhere as it was described as the Python3 "bip-schnorr reference code"
1412019-11-12T18:46:22  <jonatack> (in bip-taproot)
1422019-11-12T18:46:41  <sipa> the bip-schnorr reference code is https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
1432019-11-12T18:46:48  <sipa> there is no similar thing for bip-taproot
1442019-11-12T18:47:22  <jonatack> ty for the clarification
1452019-11-12T18:47:24  <sipa> we probably want to have that when writing test vectors for taproot
1462019-11-12T18:49:06  *** pinheadmz has joined ##taproot-bip-review
1472019-11-12T18:55:56  *** Moller40 has joined ##taproot-bip-review
1482019-11-12T18:57:37  <jonatack> ok. will pr to make the sentence clear that the helper functions, and not the example code, are from the bip-schnorr reference code with a link to reference.py
1492019-11-12T18:57:57  <sipa> ok
1502019-11-12T19:00:00  <moneyball> Q&A about to start...
1512019-11-12T19:00:06  <jnewbery> ...
1522019-11-12T19:00:15  <aj> #startmeeting
1532019-11-12T19:00:15  <lightningbot> Meeting started Tue Nov 12 19:00:15 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
1542019-11-12T19:00:15  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1552019-11-12T19:00:17  <jnewbery> hi
1562019-11-12T19:00:20  <sipa> hi
1572019-11-12T19:00:20  <bjarnem> hi
1582019-11-12T19:00:40  <schmidty> Hi
1592019-11-12T19:00:43  <moneyball> hi
1602019-11-12T19:00:44  <r251d> hi
1612019-11-12T19:00:49  <ariard> hi
1622019-11-12T19:00:54  <jonatack> hi
1632019-11-12T19:01:00  <devrandom> hi
1642019-11-12T19:01:31  <kabaum> hi
1652019-11-12T19:01:31  <aj> hi
1662019-11-12T19:01:31  <hebasto> hi
1672019-11-12T19:02:15  <cdecker> Hi
1682019-11-12T19:02:19  <hebasto> Q from group 5 (1/2): 1. What happens when using other leaf versions now before they are defined?
1692019-11-12T19:02:48  <fjahr> hi
1702019-11-12T19:03:11  *** michaelfolkson has joined ##taproot-bip-review
1712019-11-12T19:03:22  <sipa> hebasto: they're spendable by anyone (who can give the internal key and merkle path)
1722019-11-12T19:03:51  <bjarnem> I was having the same question and I don't think this is specified in the BIP.
1732019-11-12T19:04:05  <sipa> bjarnem: it is, i think, though not explicitly
1742019-11-12T19:04:19  <hebasto> yes, it is not obvious from bip...
1752019-11-12T19:04:27  <sipa> bip-taproot just states that any relevant scripts are executed
1762019-11-12T19:04:43  <jnewbery> would those spends be non-standard initially?
1772019-11-12T19:04:48  <sipa> jnewbery: of course
1782019-11-12T19:04:49  <kabaum> I think taproot rationale [10] is what we're looking for,
1792019-11-12T19:04:58  <pyskell> hi
1802019-11-12T19:05:03  *** arik_ has joined ##taproot-bip-review
1812019-11-12T19:05:07  <sipa> bip-tapscript defines one for one particular leaf version
1822019-11-12T19:05:10  *** jenseven has quit IRC
1832019-11-12T19:05:21  <aj> sipa: "of course" -- should it be written down somewhere which bits should be treated as non-standard?
1842019-11-12T19:05:42  <jnewbery> I think standardness falls outside the BIPs, which only deal with consensus, no?
1852019-11-12T19:05:42  <sipa> perhaps we can add that if no script semantics are defined for a particular leaf version, the spend is unconditionally valid
1862019-11-12T19:05:48  *** KeithMukai has joined ##taproot-bip-review
1872019-11-12T19:05:52  <sipa> jnewbery: yeah, that's my thinking
1882019-11-12T19:05:53  <Moller40> Hi
1892019-11-12T19:06:23  <cdecker> That'd be a nice addition
1902019-11-12T19:06:45  <sipa> aj: it feels strange to specify standardness rules in these bips, as they're far less "everyoneust agree on this" than the consensus parts
1912019-11-12T19:06:52  <aj> treating things as non-standard is important for future soft-forks to be safe (so that nodes that don't validate the new rules dont relay new tx's that might violate them) though?
1922019-11-12T19:07:04  <sipa> but i also see that it'd be nice to have it written up somewhere
1932019-11-12T19:07:18  <aj> sipa: yeah, agree on both points :)
1942019-11-12T19:08:04  <hebasto> Q from group 5 (2/2). Disabled script opcodes."unexecuted branch" means unexecuted branch in the revealed script?
1952019-11-12T19:08:05  *** sergei-t has joined ##taproot-bip-review
1962019-11-12T19:08:18  <sipa> hebasto: correct
1972019-11-12T19:08:26  <hebasto> sipa; ty
1982019-11-12T19:08:27  <sipa> i see how branch can be confusing here
1992019-11-12T19:08:45  <hebasto> a bit ;)
2002019-11-12T19:08:49  <sipa> it means execution branch of the script, not merkle branch
2012019-11-12T19:09:08  <cdecker> Related: aborting when decoding the script instead of executing is merely a performance improvement, or am I missing something?
2022019-11-12T19:09:33  <hebasto> maybe "execution branch" and "merkle branch" are good wording for bip?
2032019-11-12T19:10:09  <sipa> cdecker: it also implies that any later success isn't apllicable
2042019-11-12T19:10:17  <sipa> hebasto: sure
2052019-11-12T19:10:23  <bjarnem> Q: Regarding the tweak value `t` must be less than the SECP256K1_ORDER: What to do if the calculated value is greater/equal?
2062019-11-12T19:10:33  <sipa> bjarnem: it won't be
2072019-11-12T19:10:44  <jnewbery> bjarnem: buy a lottery ticket
2082019-11-12T19:10:47  <cdecker> Right, but it allows statically discarding things early on, without having to execute
2092019-11-12T19:11:25  <sipa> cdecker: if your question is whether you can write an alternative way to interpreting that does not actually return false immediately upon abort, of course
2102019-11-12T19:12:05  <sipa> but abort in this context is more than giving a suggested optimization for implementers; it's stating that if that condition is reached, the script must fail
2112019-11-12T19:12:44  <pyskell> The Taproot BIP says:  "To the best of the authors' knowledge, no existing use of SHA256 in Bitcoin feeds it a message that starts with two single SHA256 outputs, making collisions between hashtag with other hashes extremely unlikely." What is meant by it and what would happen if it's true? Mostly interested because it's stated in somewhat uncertain terms.
2122019-11-12T19:12:44  <cdecker> Yep, just felt strange to abort on a script branch that isn't even executed :-)
2132019-11-12T19:13:02  *** michaelfolkson has quit IRC
2142019-11-12T19:13:11  <sipa> cdecker: i see
2152019-11-12T19:13:28  <bjarnem> Q: Regarding the squareness of `Q`: (Disclaimer: I am not a cryptographer, so I hope this question is not naive)
2162019-11-12T19:13:28  <bjarnem> I am unsure regarding the necesity of using a bit to indicate the `has_square_y(Q)` in the control block (Ad7 and Ad6 explain that the squareness of y cannot be guaranteed for `Q`).
2172019-11-12T19:13:28  <bjarnem> The `Q` value (tweaked pubkey) is commited as scriptPubKey. It can hence also be spend using the key path with a Schnorr signature. But BIP-Schnorr then requires the (tweaked) pubkey `Q` to pass `has_square_y(Q)`. Shouldn't it therefore be guaranteed that for `Q` such a y-coord exists? Or am I misunderstanding something completely?
2182019-11-12T19:14:05  *** michaelfolkson has joined ##taproot-bip-review
2192019-11-12T19:14:17  <sipa> cdecker: not sure how to formulate more clearly... you can see it as a preprocessing step of executing the script (in which case it's just a failure rather than aborting during execution itself
2202019-11-12T19:15:16  <cdecker> The formulation is clear, I was just wondering about the rationale. All good, don't want to hold up the QA ^^
2212019-11-12T19:15:23  <nickler> bjarnem: for key spending Q doesn't have a y coordinate. So the verifier will choose the y coordinate that is square (there's only two options).
2222019-11-12T19:15:27  <sipa> bjarnem: when spending using the key path, you interpret Q as a has_square point, regardlesz of how it was constructed, and sign possibly with its negation
2232019-11-12T19:15:34  <pyskell> Is it referring to the SHA256 opcode or something else?
2242019-11-12T19:15:59  <sipa> bjarnem: when signing using the script path, you have to actually know the squaredness of Y, otherwise the commitment equation won't hold
2252019-11-12T19:16:20  <jnewbery> One thing that we spent a bit of time talking about in our group session was the annex. Both the format (ie starting with 0x50) and the purpose.
2262019-11-12T19:16:30  <jnewbery> For the format, I think we explicitly want a leading byte that can't be interpreted as a pubkey (so it can't be confused for P2WPKH) or a opcode (so it can't be confused for P2WSH). 0x50 fits the bill because it can't be a pubkey leading byte (which must be 0x02 or 0x03) and it's an invalid opcode (defined as OP_RESERVED internally, but with unconditional fail semantics).
2272019-11-12T19:16:45  <aj> sipa, bjarnem: and you can't just try both options if we want to batch verify to make it more efficient
2282019-11-12T19:17:26  <sipa> jnewbery: it's stronger than that! you can recognize an annex in an input without knowing which output is being spent
2292019-11-12T19:17:27  <jnewbery> citation 3: https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#cite_note-3 explains that briefly, but I think it could be expanded a bit (I had to dig around to find 0x50 in script/interpreter.cpp
2302019-11-12T19:17:39  <sipa> jnewbery: which is by design
2312019-11-12T19:17:40  <bjarnem> sipa: ok, I see, so for the script path it is important to show exactly which point, and the x-coord is not enough. I will try to read up on that to understand it a little better :)
2322019-11-12T19:18:13  <jnewbery> right. What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
2332019-11-12T19:18:14  <sipa> bjarnem: feel free to PR a clarification if you find text that would make it easier to understand for you
2342019-11-12T19:18:46  <sipa> jnewbery: did you get the idea of using an annex to artifically increase an input's weight?
2352019-11-12T19:19:10  <jnewbery> I understood the purpose, but wondered why you couldn't just do that in the tapscript
2362019-11-12T19:19:21  <sipa> ?
2372019-11-12T19:19:51  <sipa> oh you mean by putting a big push + OP_DROP in the script?
2382019-11-12T19:20:24  <jnewbery> I think the idea is that if we redefine an OP_SUCCESS to be something like OP_VERIFYSNARK, then we want to increase the weight becuase of the increased validation cost
2392019-11-12T19:20:42  <jnewbery> yes, why not just add that weight to the script
2402019-11-12T19:20:57  <sipa> jnewbery: that seems.like highly inefficient use of the chain
2412019-11-12T19:21:17  <sipa> if you need to pad it with garbage
2422019-11-12T19:21:28  <jnewbery> isn't that what the annex is doing?
2432019-11-12T19:21:31  <bjarnem> Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)?
2442019-11-12T19:21:32  <ariard> can't it be used also for a per-input locktime IIRC ?
2452019-11-12T19:21:35  <sipa> jnewbery: no!
2462019-11-12T19:21:46  <jnewbery> oh, then I misunderstand!
2472019-11-12T19:22:28  <sipa> jnewbery: the idea would be for example that an annex whose first byte (after the 0x50, using some encoding) is 0x37, a 2-byte field follows
2482019-11-12T19:22:47  <sipa> and the value of that two byte field is added to the weight of the tx
2492019-11-12T19:23:15  <sipa> while simultaneously equivalently increasing the budget for expensivw opcodes in tbe script
2502019-11-12T19:23:36  <sipa> ariard: for examlle
2512019-11-12T19:23:49  <sipa> ariard: or a block height hash requirement
2522019-11-12T19:23:55  <ariard> sipa: yes but the value of that two byte can be choosed by the spender how would you make it mandatory ?
2532019-11-12T19:24:21  <sipa> ariard: if they set it tol high, they'll pay extra fees
2542019-11-12T19:24:22  <jnewbery> after this imaginary future OP_VERIFYSNARK softfork, are unupgraded miners still able to mine? How do they account block weight?
2552019-11-12T19:24:29  <ariard> don't you need to combine with some sighash flags to force annex value being covered by transaction digest
2562019-11-12T19:24:35  <sipa> of they set it too low, the script will fail
2572019-11-12T19:24:37  <aj> ariard: if you spend more computation than the budget, your tx is invalid; so to increase the budget, you put the smallest value you can into the annex
2582019-11-12T19:24:54  <sipa> ariard: annexes are always covered by signatures
2592019-11-12T19:24:58  <hebasto> sipa: annex could increase weight without bloating chain, right?
2602019-11-12T19:25:04  <sipa> hebasto: right
2612019-11-12T19:25:17  <sipa> jnewbery: increasing the weight for a transaction is a softfork
2622019-11-12T19:25:32  <sipa> and using an unknown annex is nonstandard
2632019-11-12T19:25:41  <sipa> so i think this is perfectly possible to deploy
2642019-11-12T19:25:59  <sipa> (that doesn't mean we need to; there may never be a reason to)
2652019-11-12T19:26:11  <ariard> aj: okay so it means we track budget during script evaluation and if committed budget in annex doesn't match it's a failure ?
2662019-11-12T19:26:13  <jnewbery> unupgraded miners just don't include anything with an annex because it's non-standard?
2672019-11-12T19:26:18  <sipa> right
2682019-11-12T19:26:45  <sipa> ariard: the budget is the size of the input, which if amended by an annex, includes that amount
2692019-11-12T19:27:07  <waxwing> wait surely we expect miners to upgrade in SF scenarios to avoid mis-mining?
2702019-11-12T19:27:27  <nickler> sipa: with op_zkverify would the limit be something like #(OP_CHECKSIG)*50 + #(OP_ZKVERIFY)*X <= weight?
2712019-11-12T19:27:35  <sipa> nickler: exactly
2722019-11-12T19:27:36  <ariard> sipa: and you check the budget against which reference value ? that's where I choke
2732019-11-12T19:27:49  <sipa> ariard: the weight of the input
2742019-11-12T19:28:04  <sipa> right now that is literally the number of bytes of the witness
2752019-11-12T19:28:24  <sipa> if an annex is defined that increments the weight, that counts too
2762019-11-12T19:28:40  <elichai2> nickler: op_zkverify?
2772019-11-12T19:28:56  <moneyball> elichai2: a hypothetical example
2782019-11-12T19:29:34  <jnewbery> What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
2792019-11-12T19:29:57  <sipa> jnewbery: for this annex weight increase example it's useful
2802019-11-12T19:30:17  <sipa> as otherwise you wouldn't be able to compute a tx's weight without access to the output being spent
2812019-11-12T19:30:53  <devrandom> group 3 Q 1/?: "The total number of bytes hashed is at most 211" - this doesn't include the sub-hashes, like computing sha_prevouts, etc., right?  the reason sub-hashes are not included in the 211 bytes is because they can be cached across sigs for the same tx?
2822019-11-12T19:31:09  <sipa> devrandom: exactly
2832019-11-12T19:31:19  <elichai2> moneyball: :) I thought we're already planning tapscript V2 :P
2842019-11-12T19:31:44  <devrandom> maybe that sentence can be expanded to mention the sub-hashes?  I can PR?  or do you think it's clear enough as is?
2852019-11-12T19:32:20  <sipa> devrandom: feel free
2862019-11-12T19:32:28  <devrandom> OK
2872019-11-12T19:32:57  <devrandom> group 3 Q/?: "Just like other existing output types, taproot outputs should never reuse keys" - this is for the standard privacy reason, as in "don't reuse addresses"?
2882019-11-12T19:32:59  <jnewbery> would there ever be a reason to need more than one annex?
2892019-11-12T19:33:19  <sipa> jnewbery: possibly
2902019-11-12T19:33:50  <aj> jnewbery: if you need a per input timelock and are using OP_ZKVERIFY, you'd use two annex entries maybe
2912019-11-12T19:34:26  <cdecker> Couldn't they be serialized back to back then?
2922019-11-12T19:34:28  <jnewbery> so should we change the definition to be that any n trailing witness elements starting 0x50 are annexes?
2932019-11-12T19:34:58  <sipa> jnewbery: yes, that's possible, but concatenating them is more efficient i think
2942019-11-12T19:35:04  <aj> 0x50 { <len> <tag> <values> } seems a fine encoding to only use a single witness element
2952019-11-12T19:35:14  <jnewbery> got it
2962019-11-12T19:35:34  <aj> (makes lightning people twitch since they like tag/length/value though)
2972019-11-12T19:35:53  <sipa> it's also a tradeoff between taking a complexity hit now, and wondering whether we'll ever even need it
2982019-11-12T19:36:05  <cdecker> aj: just thought the same :-)
2992019-11-12T19:36:13  <nickler> devrandom: agree that this is confusing. Made more sense when the section was called Privacy.
3002019-11-12T19:36:24  <sipa> by saying some annex but not specifying any of its semantics we maximally defer the complexity to when it's needed
3012019-11-12T19:36:46  <jnewbery> sipa: makes sense. Thanks
3022019-11-12T19:39:00  <sipa> pyskell: the comment on the tagged hashes use refers to all sha256 anywhere in any protocol related to bitcoin
3032019-11-12T19:39:05  <sipa> not just inside script
3042019-11-12T19:39:20  <sipa> and the effect of being wrong about it is very likely nothing
3052019-11-12T19:40:08  <sipa> in most cases tagged hashing is not needed
3062019-11-12T19:40:19  <jnewbery> The control block can just be (one leading byte plus) the tapleaf hash in the case where only one script is committed. I thought it was slightly interesting that this is the only case where you can know for sure that no other spending conditions were committed to (with keypath spend you don't know whether there was a tweak and with a taptree spend you don't know the other branches)
3072019-11-12T19:40:52  <sipa> jnewbery: good point
3082019-11-12T19:41:07  <devrandom> group 3 Q 3/?: there was some group discussion about the fact that specifying the pubkey in the output saves bytes in the blockchain overall, but it's actually heavier in *vbytes*.  The discussion then got into whether the weight calculation should be different for taproot (I assume so as to encourage use by not penalizing with higher fees).  what do you think?
3092019-11-12T19:41:35  <pyskell> sipa: Gotcha, thanks for clarifying
3102019-11-12T19:41:42  *** michaelfolkson has quit IRC
3112019-11-12T19:41:54  <waxwing> devrandom, i think i remember coming up with 1.5 vbytes heavier for p2tr vs p2wpkh when discussing it with aj last week
3122019-11-12T19:41:55  <sipa> devrandom: for starters, i don't think this matters, because the output cost is paid by the sender
3132019-11-12T19:41:59  <waxwing> i mean average of course, not exact
3142019-11-12T19:42:28  <sipa> and the sender is already willing to pay fot 32-byte witness programs, or he'd not have implemented bip173
3152019-11-12T19:43:00  <waxwing> that's an argument on segwit v1 vs v0 uptake, but not legacy to v1 uptake right
3162019-11-12T19:43:06  <sipa> right
3172019-11-12T19:43:35  <bjarnem> Q: Regarding wording for signature hash:
3182019-11-12T19:43:35  <bjarnem> Under "Constructing and spending Taproot outputs" -> "Spending using the key path":
3192019-11-12T19:43:35  <bjarnem> "[...] To do so, a witness stack consists of a single element: a bip-schnorr signature on the signature hash as defined above, [...]" <- Is the "transaction digest" defined above the same as what is called "signature hash" here?
3202019-11-12T19:43:37  <nickler> waxwing: I came up with 1.25 :) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7
3212019-11-12T19:44:25  <waxwing> nickler, lol i'll take it.
3222019-11-12T19:44:33  <sipa> bjarnem: yep
3232019-11-12T19:45:10  <devrandom> the difference in vbytes for the sender is (32 - 20) * 4 = 48 if I'm not mistaken.  that said I don't have an opinion about this personally, if anybody from group 3 does they can say something ;)
3242019-11-12T19:45:26  <moneyball> sipa: thoughts on adjusting the weight calculation to make spending PT2R slightly more favorable? advantage being increased adoption of it + improved privacy/fungibility
3252019-11-12T19:45:45  <sipa> moneyball: that would be a hard fork. good luck.
3262019-11-12T19:45:52  <moneyball> oh...
3272019-11-12T19:46:09  <waxwing> a much less technical point, but our group (6) felt that the Motivation section of BIP-taproot does not actually address the motivation, at least to a reader who doesn't know all historical context. it seems like the motivation is in the "Design" section that immediately follows.
3282019-11-12T19:47:34  <waxwing> sipa, or maybe swipe a byte or two off the witness program? :)
3292019-11-12T19:47:51  <bjarnem> sipa: I feel that those terms could be defined as being the same under "Transaction digest", or maybe just use one term. Becuase it also happens in BIP-Taproot that sometimes it refers to the "transaction digest" and other times to the "signature hash". But if they are the same maybe just use one term?
3302019-11-12T19:48:13  <aj> devrandom: (32-20)*4 gives difference in weight units, vbytes is just (32-20) (and if you were counting witness data, you'd divide that part by 4)
3312019-11-12T19:48:14  <nickler> bjarnem: agreed
3322019-11-12T19:48:38  <bjarnem> (edit: I meant also in BIP-TapSCRIPT)
3332019-11-12T19:48:44  <devrandom> aj: got it
3342019-11-12T19:49:14  <sipa> waxwing: can you open an issue in my bips repo for that? i think that perhaps needs some more discussion than just a PR
3352019-11-12T19:49:48  <waxwing> sipa, the motivation? sure yeah that makes sense. i'll copy in the notes i made about it earlier.
3362019-11-12T19:50:04  <sipa> bjarnem: good point, let's use signature hash everywhere (transaction digest is confusing, as it contains some data that's not actually in the transaction)
3372019-11-12T19:50:07  <sipa> waxwing: yeah
3382019-11-12T19:50:35  <aj> sipa: maybe "signature digest" for the stuff you feed into the hash function and "signature hash" for the result?
3392019-11-12T19:50:55  <aj> sipa: it keeps annoying me there's no term to use for the stuff you feed into the hash
3402019-11-12T19:51:16  <sipa> aj: "message digest" is a historical name for cryptographic hash function, so i wouldn't use digest to refer to its preimage
3412019-11-12T19:51:35  <devrandom> group 3 Q 4/?: "The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the digest" - the difference is that segwit commits to input value, but taproot commits to *all* inputs, right?  is the difference mainly for transaction with inputs from different parties?
3422019-11-12T19:51:41  <aj> sipa: fair
3432019-11-12T19:52:11  <waxwing> devrandom, yes i was wondering about that, is it related to the kinds of attacks instagibbs came up with wrt coinjoin and similar?
3442019-11-12T19:52:24  <sipa> devrandom: no, there is an existing issue where you ask a device to sign a 2-input tx twice, and each time you lie about the other input's value
3452019-11-12T19:52:41  <sipa> the result is that a malicious online wallet can trick an offline wallet in spending more on fees than it intends to
3462019-11-12T19:54:25  <waxwing> right so not specifically coinjoin but that's one of the main ways it might come up
3472019-11-12T19:54:32  <sipa> right
3482019-11-12T19:54:40  <sipa> it's more general than that, but indeed
3492019-11-12T19:54:53  <bjarnem> I already asked but cannot find an answer, so in case it was overlooked in the discussion here it comes again :)
3502019-11-12T19:54:54  <bjarnem> Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)?
3512019-11-12T19:55:09  <devrandom> sipa: got it, I assumed that HW wallets signed all inputs at the same time
3522019-11-12T19:55:11  <sipa> bjarnem: OP_SUCCESSx is the most powerful upgrade mechanism there is
3532019-11-12T19:55:38  <sipa> bjarnem: if you'd have me pick one of leaf versions, upgradable pubkeys, or op_success, i'd pick the last one
3542019-11-12T19:56:07  <bjarnem> sipa: Doesn't leaf versioning have the same power, allowing to change the semantics of the script language like segwit versioning??
3552019-11-12T19:56:29  <sipa> bjarnem: yes, but you need a new leaf version any time you introduce a new opcode for example
3562019-11-12T19:56:48  <sipa> with OP_SUCCESSx you just pick a number and define it; it can be done in parallel with other new opcodes even
3572019-11-12T19:57:13  <devrandom> group 3 Q 5/5: should the BIP have a Requires header referring to schnorr, etc.?
3582019-11-12T19:57:27  <bjarnem> sipa: ah, ok I see that
3592019-11-12T19:57:46  <sipa> bjarnem: OP_SUCCESSx is the most natural choice for new opcodes, i think; leaf versions are the most natural choice for large redefinitions of the language
3602019-11-12T19:58:02  <sipa> and leaf versions essentially come at zero cost, because we have a few unused bits in the control block anyway
3612019-11-12T19:58:12  <sipa> devrandom: yeah
3622019-11-12T19:58:16  <nickler> devrandom: I think so. there's a PR for that already https://github.com/sipa/bips/pull/135
3632019-11-12T19:58:17  <bjarnem> sipa: thanks for the clarifiaction of the reasoning!
3642019-11-12T19:59:16  <sipa> as time is running out here... i feel there have been a lot of good questions here that got a response consisting of a rationale that isn't actually in the BIPs; i'll do an effort to go through the transcript and addressing the ones asked, but feel free to help with that
3652019-11-12T20:00:04  <aj> "feel free to help" ~= "please do help" :)
3662019-11-12T20:00:28  <moneyball> shall we wrap?
3672019-11-12T20:00:29  <sipa> if you got a satisfactory answer, you're probably in the best position to add to the bip exactly what insight would have made the text more clear to you
3682019-11-12T20:00:44  <devrandom> will PR for the stuff I asked
3692019-11-12T20:00:50  <sipa> awesome, thanks
3702019-11-12T20:00:56  <sipa> i need to run, thanks everyone!
3712019-11-12T20:00:59  <moneyball> #endmeeting
3722019-11-12T20:01:06  <jonatack> thanks!
3732019-11-12T20:01:07  *** Moller40_ has joined ##taproot-bip-review
3742019-11-12T20:01:11  <b10c> Thanks!
3752019-11-12T20:01:12  <kabaum> Thanks
3762019-11-12T20:01:15  <bjarnem> Thanks a lot!!
3772019-11-12T20:01:23  <cdecker> Thanks ^^
3782019-11-12T20:01:24  <aj> also, quick tip since a few people haven't had much luck getting groups together -- (a) if no one else has taken the initiative to choose a time, or talk about things, that might just be a cue for you to do it; (b) it might be that everyone else in your group really is too busy, so feel free to contact to join a different group
3792019-11-12T20:01:28  <aj> #endmeeting
3802019-11-12T20:01:28  <lightningbot> Meeting ended Tue Nov 12 20:01:28 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
3812019-11-12T20:01:28  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.html
3822019-11-12T20:01:28  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.txt
3832019-11-12T20:01:28  <lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
3842019-11-12T20:01:43  <fjahr> thanks
3852019-11-12T20:01:47  <chm-diederichs> thanks
3862019-11-12T20:01:47  <aj> so i guess that answers my question about whether someone else can end a meeting after it's started too...
3872019-11-12T20:02:16  <jnewbery> Thanks everyone!
3882019-11-12T20:04:02  *** Moller40 has quit IRC
3892019-11-12T20:05:43  <waxwing> yeah thanks
3902019-11-12T20:06:11  <waxwing> to play devil's avocado, 'signature hash' is unfortunate since it suggests hashing a signature, 'transaction digest' is obscure but descriptive.
3912019-11-12T20:06:25  <waxwing> ironically the whole point of segwit is to not do (some) 'signature hashing' :)
3922019-11-12T20:07:17  *** daniel-k7 has joined ##taproot-bip-review
3932019-11-12T20:10:14  <bjarnem> waxwing: "transaction digest" for me is also more expressive and easier to understand immediately.
3942019-11-12T20:10:43  <sipa> we'd still need a term for the preimage of that transaction digest
3952019-11-12T20:10:55  <r251d> For me, the BIPs didn't make it clear whether a single transaction would have one or more "transaction digest". If there would's one digest per input, then "signature digest" seems less confusing.
3962019-11-12T20:11:42  <sipa> r251d: fair point
3972019-11-12T20:15:47  <aj> r251d: there's potential a different digest per signature within an input if you have a tapscript that wants multiple signatures (eg if the sigs have different sighashes chosen, or if there are op_codeseparator's between them)
3982019-11-12T20:16:37  <sipa> different inputs (including different annexes in them), different codeseps, different sighash bytes, ...
3992019-11-12T20:24:37  <bjarnem> Would the names "transaction-digest" for the _preimage_ and "hashed-transaction-digest" for the hash-value the signature is calculated for be too crazy? :)
4002019-11-12T20:25:19  <aj> bjarnem: sipa mentioned above the academic crypto community uses "digest" for the hash not the preimage, so using it for the preimage would be confusing
4012019-11-12T20:25:49  <r251d> "Transaction digest" is probably fine if the BIP clarifies that multiple such digests can be in one tx.
4022019-11-12T20:28:23  <instagibbs> cdecker, fwiw I think the OP_SUCCESSX parsing part could be more explicit noting it's not the script execution step. The footnote makes it abundantly clear at least with rationale
4032019-11-12T20:29:56  <bjarnem> Hopefully some good, descriptive term will show up in time in a heureka moment!
4042019-11-12T20:30:00  <bjarnem> Thanks all!
4052019-11-12T20:30:04  *** bjarnem has left ##taproot-bip-review
4062019-11-12T20:38:15  <instagibbs> waxwing, I think I told you about both, the coinjoin one is the lying about whose inputs are whose.
4072019-11-12T20:38:24  <instagibbs> which is related but not solved
4082019-11-12T20:46:16  <instagibbs> (by script enhancements)
4092019-11-12T20:51:25  <waxwing> instagibbs, i see right the coinjoin one can't be solved by this because it's about who owns it, not the amount. duh.
4102019-11-12T20:51:47  *** KeithMukai has quit IRC
4112019-11-12T20:55:01  <instagibbs> yep, the input amount can be as simple as fee dumping attacks on hww
4122019-11-12T20:58:28  *** daniel-k7 has quit IRC
4132019-11-12T21:04:06  <devrandom> ("signature preimage" and "signature digest"?)
4142019-11-12T21:20:01  <sipa> seems reasonable to me
4152019-11-12T21:26:55  <felixweis> different sizes for Q are allowed. what if for shorter Qs presume 0 byte fillers? so people who really want lower output script weight than p2wpkh can use vanitygen to create such.
4162019-11-12T21:33:02  <felixweis> devrandom: renaming to reduce confusion is very welcome
4172019-11-12T21:37:11  <sipa> felixweis: that breaks upgradable key types
4182019-11-12T21:39:50  <sipa> oh, you mean for the witness program? that seems pointless as it's a cost paid by someone else
4192019-11-12T21:41:02  <sipa> and a pretty big philosophical break from trying to make all outputs look indistinguishable
4202019-11-12T21:41:43  <felixweis> yes, i wasnt also too serious actually. but it came into mind when reading the QA session and the 1.25 value
4212019-11-12T21:42:29  *** michaelfolkson has joined ##taproot-bip-review
4222019-11-12T21:46:19  *** b10c has quit IRC
4232019-11-12T21:56:54  *** michaelfolkson has quit IRC
4242019-11-12T22:03:16  *** michaelfolkson has joined ##taproot-bip-review
4252019-11-12T22:04:40  *** michaelfolkson has quit IRC
4262019-11-12T22:11:03  *** Chris_Stewart_5 has quit IRC
4272019-11-12T22:27:13  *** HighOnBtc has joined ##taproot-bip-review
4282019-11-12T22:33:44  *** sergei-t has left ##taproot-bip-review
4292019-11-12T23:07:24  *** hebasto has quit IRC
4302019-11-12T23:08:42  *** hebasto has joined ##taproot-bip-review
4312019-11-12T23:38:01  *** Chris_Stewart_5 has joined ##taproot-bip-review