--- Day changed Tue Nov 12 2019 00:51 -!- b10c [~Thunderbi@2001:16b8:2e76:a500:2e47:30a4:c94e:dd99] has joined ##taproot-bip-review 01:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 245 seconds] 01:17 -!- orfeas [0547c4f0@0547c4f0.skybroadband.com] has joined ##taproot-bip-review 01:38 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 01:38 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 01:38 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 01:38 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 01:40 -!- marcinja [~marcinja@204.48.26.93] has quit [Ping timeout: 240 seconds] 01:43 -!- marcinja [~marcinja@2604:a880:400:d1::89a:e001] has joined ##taproot-bip-review 01:45 -!- jonatack [~jon@134.19.179.203] has joined ##taproot-bip-review 02:10 -!- xoyi- [~xoyi-@185.6.78.108] has joined ##taproot-bip-review 02:11 < 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? 02:34 <@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 02:36 < xoyi-> ah right. Thanks for clarifying @aj 02:52 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 03:10 < 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? 03:10 < waxwing> feel like i must have missed something. 03:11 <@aj> waxwing: bip-taproot "Signature validation rules" says when hash_type = 00 03:13 < 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? 03:13 <@aj> waxwing: it is the same as sighash_all, except it's 64 bytes instead of 65 bytes 03:13 < waxwing> aj, ok. is that stated anywhere? 03:13 < waxwing> under 'hash_type' it says the legacy are still retained, including SIGHASH_ALL 03:14 < 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 :) 03:14 <@aj> waxwing: i think you just have to read through the logic and see it behaves the same way? 03:15 <@aj> waxwing: if you do SIGHASH_ALL | SIGHASH_ANYONECANPAY you get 0x81 but 0x80 isn't valid, which is another difference 03:15 < waxwing> aj, but where in 'Signature validation rules' does it tell you that it's ALL sighashing with 0x00? 03:16 < waxwing> it just says valid signature according to bip-schnorr and message set to transaction digest, but doesn't say which transaction digest right. 03:16 <@aj> waxwing: i think rationale entry 11 is the most explicit comment. 03:17 <@aj> waxwing: i meant if you read through the rules, 0x00 and 0x01 will give you the same semantics 03:17 < 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? 03:18 <@aj> waxwing: yeah, i think it just assumes you know which one's the most common type 03:19 < 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 03:19 < waxwing> that made me tend to discount the possibility that 0x00 was the same. 03:19 < waxwing> (point taken though about 0x80, 0x81) 03:20 <@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? 03:21 < 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 :) 03:21 < waxwing> i think one of the rationales already kinda covers (b), the one you mentioned prob. 03:23 < 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. 03:23 <@aj> yeah, i was surprised it's not stated 03:23 <@aj> file a PR or issue? 03:23 < waxwing> so why do we still have 0x01 then? is it because of the ACP flag so you can get 0x81? 03:24 < waxwing> aj, sure i'll do it, thanks for your help 03:24 <@aj> well having 0x01 matches SIGHASH_ALL as it currently exists 03:25 < waxwing> yes. not sure why that matters? new sig scheme and new digest? (so code isn't going to be the same anyway) 03:25 <@aj> but you could have 64-bytes = hash_type=0x01, and not allow 0x01 in 65-byte sigs 03:25 < waxwing> yeah that's what would have felt a lot more natural 03:25 < waxwing> adding a new flag value with the same semantics as an old one, which is not removed seems weird 03:26 <@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 03:36 < 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. 03:36 < waxwing> But I'll still PR it because it's just one extra sentence and it'd avoid confusion. 03:43 <@aj> waxwing: yeah, i think it's well defined, but it's not clear 03:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 04:37 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 04:38 < sosthene> Thanks aj and waxwing, it's clear now 04:38 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-fcecgerlfuepmuvv] has quit [Remote host closed the connection] 04:39 < sosthene> I'm curious if there are still other reasons besides having 65 byte sig of any type 04:40 < sosthene> but that alone makes sense I guess 04:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 04:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 05:10 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-rilqfgqtxiftabxx] has joined ##taproot-bip-review 05:11 -!- udiWertheimer_ [sid190185@gateway/web/irccloud.com/x-rgyfvjbfxvlacmgl] has left ##taproot-bip-review [] 05:27 -!- orfeas [0547c4f0@0547c4f0.skybroadband.com] has quit [Remote host closed the connection] 05:43 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-migmaalyvyfsqvmq] has joined ##taproot-bip-review 06:02 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review 06:26 -!- jonatack [~jon@134.19.179.203] has quit [Quit: jonatack] 06:26 -!- jonatack [~jon@134.19.179.203] has joined ##taproot-bip-review 06:30 < instagibbs> is CastToBool defined in any BIP anywhere? 06:32 < instagibbs> I know where to find the code-based definition, just seemed like something that should be defined 06:35 < 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 06:42 < instagibbs> joke observation: if we ever get to gigameg blocks, we'll need to define what happens to `codeseparator_position` after 2^32 bytes. 06:47 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 06:51 -!- jonatack [~jon@134.19.179.203] has quit [Ping timeout: 276 seconds] 07:02 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 268 seconds] 07:10 < orfeas> compact_size() and CCompactSize are not defined in the 3 bips. Should there be a link to their definition? 07:23 -!- xoyi- [~xoyi-@185.6.78.108] has quit [Ping timeout: 240 seconds] 07:54 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection] 07:56 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review 08:00 < 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. 08:07 < elichai2> orfeas: well AFAIK they're not defined anywhere. it's an implementation detail 08:09 < orfeas> elichai2: isn't it consensus-critical though? 08:10 < orfeas> I guess they are defined as in the reference implementation then 08:10 < elichai2> orfeas: the consensus code is very far from being properly defined 08:10 < elichai2> (outside of Core itself obviously) 08:11 < orfeas> would a footnote with a link to the relevant Core function make sense? or this opens a whole new can of worms? 08:15 -!- jenseven [~jenseven@45.87.212.124] has joined ##taproot-bip-review 08:16 < elichai2> that would be inconsistent with other PRs. i.e. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 08:19 < 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? 08:21 < elichai2> because in bitoin core when you serialize a CScript you get Bytes((CCompactSize(script) || script)) 08:22 < elichai2> a rule of thumb, if you see CCompactSize asusme it's an implementation detail :) 08:22 < elichai2> (and when there are no private data fields assume length extension attacks aren't interesting :) ) 08:27 < elichai2> instagibbs: pretty sure `CastToBool` isn't defined outside of the codebase 08:29 < 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 08:30 < sipa> they also match the current semantics where both 0 and 1 are valid hashtypes that correspond to SIGHASH_ALL 08:31 < 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. 08:32 < waxwing> second sentence i didn't get, you're not saying 0x00 is a valid sighash byte currently? 08:32 < sipa> currently (in legacy and segwit v0) 0 is a valid sighash type 08:32 < sipa> with the same semantics as ALL 08:33 -!- arik_ [uid402902@gateway/web/irccloud.com/x-kntznpjkoynjriao] has quit [Quit: Connection closed for inactivity] 08:33 < waxwing> oh i had no idea. is that ever used? 08:35 < 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 08:35 < sipa> waxwing: i doubt it 08:36 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review 08:37 < 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.) 08:39 < sipa> agreed 08:43 < jonatack> instagibbs: was disconnected so this may be out of band, AFAIK CastToBool is only mentioned in bip-0141.mediawiki:107, and not defined 08:52 < sipa> it's implicitly defined by the source code, but i think it's worth spelling out exactly 09:16 < jonatack> src/script/interpreter.cpp:35:bool CastToBool(const valtype& vch) 09:24 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection] 09:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 09:46 -!- bjarnem [~bjarne@84.79.140.198] has joined ##taproot-bip-review 09:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 10:00 -!- pyskell [~meh@unaffiliated/pyskell] has quit [Quit: Leaving] 10:01 < jnewbery> Hi folks. Next Q&A starts in one hour 10:22 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review 10:23 < 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. 10:24 < jonatack> (grepping in the taproot branch of sipa/bitcoin) 10:24 < sipa> jonatack: all the "signing" code is in feature_taproot.py 10:24 < sipa> some of it can probably be abstracted out 10:29 < 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" 10:30 < jonatack> perhaps a link... I don't see most of that code (as named) 10:32 < sipa> jonatack: oh! that's referring to https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py 10:32 < sipa> not the bitcoin core branch 10:32 < sipa> i think? 10:33 -!- pyskell [~meh@194.36.111.51] has joined ##taproot-bip-review 10:33 -!- pyskell [~meh@194.36.111.51] has quit [Changing host] 10:33 -!- pyskell [~meh@unaffiliated/pyskell] has joined ##taproot-bip-review 10:35 < jonatack> hm! will pull down sipa/bips to grep it 10:40 < 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 10:41 < sipa> what specific function are you missing? 10:42 < sipa> or what reference is unexplained? 10:44 < jonatack> I was looking for where the code presented in bip-taproot lives, e.g. the functions taproot_tweak_*, taproot_sign_*, taproot_output_script 10:44 < sipa> they're in the bip? 10:44 < jonatack> Yes, only in the bip 10:44 < sipa> ah, you mean is there some python file you can use directly? no 10:45 < sipa> perhaps there should be 10:45 < jonatack> Thought it might be extracted from elsewhere as it was described as the Python3 "bip-schnorr reference code" 10:46 < jonatack> (in bip-taproot) 10:46 < sipa> the bip-schnorr reference code is https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py 10:46 < sipa> there is no similar thing for bip-taproot 10:47 < jonatack> ty for the clarification 10:47 < sipa> we probably want to have that when writing test vectors for taproot 10:49 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-bip-review 10:55 -!- Moller40 [~mr@82.103.130.178] has joined ##taproot-bip-review 10:57 < 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 10:57 < sipa> ok 11:00 <@moneyball> Q&A about to start... 11:00 < jnewbery> ... 11:00 <@aj> #startmeeting 11:00 < lightningbot> Meeting started Tue Nov 12 19:00:15 2019 UTC. The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00 < jnewbery> hi 11:00 < sipa> hi 11:00 < bjarnem> hi 11:00 < schmidty> Hi 11:00 <@moneyball> hi 11:00 < r251d> hi 11:00 < ariard> hi 11:00 < jonatack> hi 11:01 < devrandom> hi 11:01 < kabaum> hi 11:01 < hebasto> hi 11:01 <@aj> hi 11:02 < cdecker> Hi 11:02 < hebasto> Q from group 5 (1/2): 1. What happens when using other leaf versions now before they are defined? 11:02 < fjahr> hi 11:03 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 11:03 < sipa> hebasto: they're spendable by anyone (who can give the internal key and merkle path) 11:03 < bjarnem> I was having the same question and I don't think this is specified in the BIP. 11:04 < sipa> bjarnem: it is, i think, though not explicitly 11:04 < hebasto> yes, it is not obvious from bip... 11:04 < sipa> bip-taproot just states that any relevant scripts are executed 11:04 < jnewbery> would those spends be non-standard initially? 11:04 < sipa> jnewbery: of course 11:04 < kabaum> I think taproot rationale [10] is what we're looking for, 11:04 < pyskell> hi 11:05 -!- arik_ [uid402902@gateway/web/irccloud.com/x-ujwariqvzzsszgtr] has joined ##taproot-bip-review 11:05 < sipa> bip-tapscript defines one for one particular leaf version 11:05 -!- jenseven [~jenseven@45.87.212.124] has quit [] 11:05 <@aj> sipa: "of course" -- should it be written down somewhere which bits should be treated as non-standard? 11:05 < jnewbery> I think standardness falls outside the BIPs, which only deal with consensus, no? 11:05 < sipa> perhaps we can add that if no script semantics are defined for a particular leaf version, the spend is unconditionally valid 11:05 -!- KeithMukai [6bb5bd56@107.181.189.86] has joined ##taproot-bip-review 11:05 < sipa> jnewbery: yeah, that's my thinking 11:05 < Moller40> Hi 11:06 < cdecker> That'd be a nice addition 11:06 < 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 11:06 <@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? 11:07 < sipa> but i also see that it'd be nice to have it written up somewhere 11:07 <@aj> sipa: yeah, agree on both points :) 11:08 < hebasto> Q from group 5 (2/2). Disabled script opcodes."unexecuted branch" means unexecuted branch in the revealed script? 11:08 -!- sergei-t [~sergei@94.103.211.82] has joined ##taproot-bip-review 11:08 < sipa> hebasto: correct 11:08 < hebasto> sipa; ty 11:08 < sipa> i see how branch can be confusing here 11:08 < hebasto> a bit ;) 11:08 < sipa> it means execution branch of the script, not merkle branch 11:09 < cdecker> Related: aborting when decoding the script instead of executing is merely a performance improvement, or am I missing something? 11:09 < hebasto> maybe "execution branch" and "merkle branch" are good wording for bip? 11:10 < sipa> cdecker: it also implies that any later success isn't apllicable 11:10 < sipa> hebasto: sure 11:10 < bjarnem> Q: Regarding the tweak value `t` must be less than the SECP256K1_ORDER: What to do if the calculated value is greater/equal? 11:10 < sipa> bjarnem: it won't be 11:10 < jnewbery> bjarnem: buy a lottery ticket 11:10 < cdecker> Right, but it allows statically discarding things early on, without having to execute 11:11 < 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 11:12 < 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 11:12 < 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. 11:12 < cdecker> Yep, just felt strange to abort on a script branch that isn't even executed :-) 11:13 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 11:13 < sipa> cdecker: i see 11:13 < bjarnem> Q: Regarding the squareness of `Q`: (Disclaimer: I am not a cryptographer, so I hope this question is not naive) 11:13 < 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`). 11:13 < 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? 11:14 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 11:14 < 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 11:15 < cdecker> The formulation is clear, I was just wondering about the rationale. All good, don't want to hold up the QA ^^ 11:15 < 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). 11:15 < 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 11:15 < pyskell> Is it referring to the SHA256 opcode or something else? 11:15 < sipa> bjarnem: when signing using the script path, you have to actually know the squaredness of Y, otherwise the commitment equation won't hold 11:16 < 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. 11:16 < 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). 11:16 <@aj> sipa, bjarnem: and you can't just try both options if we want to batch verify to make it more efficient 11:17 < sipa> jnewbery: it's stronger than that! you can recognize an annex in an input without knowing which output is being spent 11:17 < 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 11:17 < sipa> jnewbery: which is by design 11:17 < 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 :) 11:18 < jnewbery> right. What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent? 11:18 < sipa> bjarnem: feel free to PR a clarification if you find text that would make it easier to understand for you 11:18 < sipa> jnewbery: did you get the idea of using an annex to artifically increase an input's weight? 11:19 < jnewbery> I understood the purpose, but wondered why you couldn't just do that in the tapscript 11:19 < sipa> ? 11:19 < sipa> oh you mean by putting a big push + OP_DROP in the script? 11:20 < 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 11:20 < jnewbery> yes, why not just add that weight to the script 11:20 < sipa> jnewbery: that seems.like highly inefficient use of the chain 11:21 < sipa> if you need to pad it with garbage 11:21 < jnewbery> isn't that what the annex is doing? 11:21 < 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)? 11:21 < ariard> can't it be used also for a per-input locktime IIRC ? 11:21 < sipa> jnewbery: no! 11:21 < jnewbery> oh, then I misunderstand! 11:22 < 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 11:22 < sipa> and the value of that two byte field is added to the weight of the tx 11:23 < sipa> while simultaneously equivalently increasing the budget for expensivw opcodes in tbe script 11:23 < sipa> ariard: for examlle 11:23 < sipa> ariard: or a block height hash requirement 11:23 < ariard> sipa: yes but the value of that two byte can be choosed by the spender how would you make it mandatory ? 11:24 < sipa> ariard: if they set it tol high, they'll pay extra fees 11:24 < jnewbery> after this imaginary future OP_VERIFYSNARK softfork, are unupgraded miners still able to mine? How do they account block weight? 11:24 < ariard> don't you need to combine with some sighash flags to force annex value being covered by transaction digest 11:24 < sipa> of they set it too low, the script will fail 11:24 <@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 11:24 < sipa> ariard: annexes are always covered by signatures 11:24 < hebasto> sipa: annex could increase weight without bloating chain, right? 11:25 < sipa> hebasto: right 11:25 < sipa> jnewbery: increasing the weight for a transaction is a softfork 11:25 < sipa> and using an unknown annex is nonstandard 11:25 < sipa> so i think this is perfectly possible to deploy 11:25 < sipa> (that doesn't mean we need to; there may never be a reason to) 11:26 < 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 ? 11:26 < jnewbery> unupgraded miners just don't include anything with an annex because it's non-standard? 11:26 < sipa> right 11:26 < sipa> ariard: the budget is the size of the input, which if amended by an annex, includes that amount 11:27 < waxwing> wait surely we expect miners to upgrade in SF scenarios to avoid mis-mining? 11:27 < nickler> sipa: with op_zkverify would the limit be something like #(OP_CHECKSIG)*50 + #(OP_ZKVERIFY)*X <= weight? 11:27 < sipa> nickler: exactly 11:27 < ariard> sipa: and you check the budget against which reference value ? that's where I choke 11:27 < sipa> ariard: the weight of the input 11:28 < sipa> right now that is literally the number of bytes of the witness 11:28 < sipa> if an annex is defined that increments the weight, that counts too 11:28 < elichai2> nickler: op_zkverify? 11:28 <@moneyball> elichai2: a hypothetical example 11:29 < jnewbery> What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent? 11:29 < sipa> jnewbery: for this annex weight increase example it's useful 11:30 < sipa> as otherwise you wouldn't be able to compute a tx's weight without access to the output being spent 11:30 < 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? 11:31 < sipa> devrandom: exactly 11:31 < elichai2> moneyball: :) I thought we're already planning tapscript V2 :P 11:31 < 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? 11:32 < sipa> devrandom: feel free 11:32 < devrandom> OK 11:32 < 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"? 11:32 < jnewbery> would there ever be a reason to need more than one annex? 11:33 < sipa> jnewbery: possibly 11:33 <@aj> jnewbery: if you need a per input timelock and are using OP_ZKVERIFY, you'd use two annex entries maybe 11:34 < cdecker> Couldn't they be serialized back to back then? 11:34 < jnewbery> so should we change the definition to be that any n trailing witness elements starting 0x50 are annexes? 11:34 < sipa> jnewbery: yes, that's possible, but concatenating them is more efficient i think 11:35 <@aj> 0x50 { } seems a fine encoding to only use a single witness element 11:35 < jnewbery> got it 11:35 <@aj> (makes lightning people twitch since they like tag/length/value though) 11:35 < sipa> it's also a tradeoff between taking a complexity hit now, and wondering whether we'll ever even need it 11:36 < cdecker> aj: just thought the same :-) 11:36 < nickler> devrandom: agree that this is confusing. Made more sense when the section was called Privacy. 11:36 < sipa> by saying some annex but not specifying any of its semantics we maximally defer the complexity to when it's needed 11:36 < jnewbery> sipa: makes sense. Thanks 11:39 < sipa> pyskell: the comment on the tagged hashes use refers to all sha256 anywhere in any protocol related to bitcoin 11:39 < sipa> not just inside script 11:39 < sipa> and the effect of being wrong about it is very likely nothing 11:40 < sipa> in most cases tagged hashing is not needed 11:40 < 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) 11:40 < sipa> jnewbery: good point 11:41 < 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? 11:41 < pyskell> sipa: Gotcha, thanks for clarifying 11:41 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 11:41 < waxwing> devrandom, i think i remember coming up with 1.5 vbytes heavier for p2tr vs p2wpkh when discussing it with aj last week 11:41 < sipa> devrandom: for starters, i don't think this matters, because the output cost is paid by the sender 11:41 < waxwing> i mean average of course, not exact 11:42 < sipa> and the sender is already willing to pay fot 32-byte witness programs, or he'd not have implemented bip173 11:43 < waxwing> that's an argument on segwit v1 vs v0 uptake, but not legacy to v1 uptake right 11:43 < sipa> right 11:43 < bjarnem> Q: Regarding wording for signature hash: 11:43 < bjarnem> Under "Constructing and spending Taproot outputs" -> "Spending using the key path": 11:43 < 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? 11:43 < nickler> waxwing: I came up with 1.25 :) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7 11:44 < waxwing> nickler, lol i'll take it. 11:44 < sipa> bjarnem: yep 11:45 < 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 ;) 11:45 <@moneyball> sipa: thoughts on adjusting the weight calculation to make spending PT2R slightly more favorable? advantage being increased adoption of it + improved privacy/fungibility 11:45 < sipa> moneyball: that would be a hard fork. good luck. 11:45 <@moneyball> oh... 11:46 < 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. 11:47 < waxwing> sipa, or maybe swipe a byte or two off the witness program? :) 11:47 < 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? 11:48 <@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) 11:48 < nickler> bjarnem: agreed 11:48 < bjarnem> (edit: I meant also in BIP-TapSCRIPT) 11:48 < devrandom> aj: got it 11:49 < 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 11:49 < waxwing> sipa, the motivation? sure yeah that makes sense. i'll copy in the notes i made about it earlier. 11:50 < 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) 11:50 < sipa> waxwing: yeah 11:50 <@aj> sipa: maybe "signature digest" for the stuff you feed into the hash function and "signature hash" for the result? 11:50 <@aj> sipa: it keeps annoying me there's no term to use for the stuff you feed into the hash 11:51 < sipa> aj: "message digest" is a historical name for cryptographic hash function, so i wouldn't use digest to refer to its preimage 11:51 < 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? 11:51 <@aj> sipa: fair 11:52 < waxwing> devrandom, yes i was wondering about that, is it related to the kinds of attacks instagibbs came up with wrt coinjoin and similar? 11:52 < 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 11:52 < sipa> the result is that a malicious online wallet can trick an offline wallet in spending more on fees than it intends to 11:54 < waxwing> right so not specifically coinjoin but that's one of the main ways it might come up 11:54 < sipa> right 11:54 < sipa> it's more general than that, but indeed 11:54 < bjarnem> I already asked but cannot find an answer, so in case it was overlooked in the discussion here it comes again :) 11: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)? 11:55 < devrandom> sipa: got it, I assumed that HW wallets signed all inputs at the same time 11:55 < sipa> bjarnem: OP_SUCCESSx is the most powerful upgrade mechanism there is 11:55 < sipa> bjarnem: if you'd have me pick one of leaf versions, upgradable pubkeys, or op_success, i'd pick the last one 11:56 < bjarnem> sipa: Doesn't leaf versioning have the same power, allowing to change the semantics of the script language like segwit versioning?? 11:56 < sipa> bjarnem: yes, but you need a new leaf version any time you introduce a new opcode for example 11:56 < sipa> with OP_SUCCESSx you just pick a number and define it; it can be done in parallel with other new opcodes even 11:57 < devrandom> group 3 Q 5/5: should the BIP have a Requires header referring to schnorr, etc.? 11:57 < bjarnem> sipa: ah, ok I see that 11:57 < 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 11:58 < sipa> and leaf versions essentially come at zero cost, because we have a few unused bits in the control block anyway 11:58 < sipa> devrandom: yeah 11:58 < nickler> devrandom: I think so. there's a PR for that already https://github.com/sipa/bips/pull/135 11:58 < bjarnem> sipa: thanks for the clarifiaction of the reasoning! 11:59 < 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 12:00 <@aj> "feel free to help" ~= "please do help" :) 12:00 <@moneyball> shall we wrap? 12:00 < 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 12:00 < devrandom> will PR for the stuff I asked 12:00 < sipa> awesome, thanks 12:00 < sipa> i need to run, thanks everyone! 12:00 <@moneyball> #endmeeting 12:01 < jonatack> thanks! 12:01 -!- Moller40_ [~mr@82.103.130.178] has joined ##taproot-bip-review 12:01 < b10c> Thanks! 12:01 < kabaum> Thanks 12:01 < bjarnem> Thanks a lot!! 12:01 < cdecker> Thanks ^^ 12:01 <@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 12:01 <@aj> #endmeeting 12:01 < lightningbot> Meeting ended Tue Nov 12 20:01:28 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.html 12:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.txt 12:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html 12:01 < fjahr> thanks 12:01 < chm-diederichs> thanks 12:01 <@aj> so i guess that answers my question about whether someone else can end a meeting after it's started too... 12:02 < jnewbery> Thanks everyone! 12:04 -!- Moller40 [~mr@82.103.130.178] has quit [Ping timeout: 240 seconds] 12:05 < waxwing> yeah thanks 12:06 < waxwing> to play devil's avocado, 'signature hash' is unfortunate since it suggests hashing a signature, 'transaction digest' is obscure but descriptive. 12:06 < waxwing> ironically the whole point of segwit is to not do (some) 'signature hashing' :) 12:07 -!- daniel-k7 [5f5ae880@95.90.232.128] has joined ##taproot-bip-review 12:10 < bjarnem> waxwing: "transaction digest" for me is also more expressive and easier to understand immediately. 12:10 < sipa> we'd still need a term for the preimage of that transaction digest 12:10 < 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. 12:11 < sipa> r251d: fair point 12:15 <@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) 12:16 < sipa> different inputs (including different annexes in them), different codeseps, different sighash bytes, ... 12:24 < 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? :) 12:25 <@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 12:25 < r251d> "Transaction digest" is probably fine if the BIP clarifies that multiple such digests can be in one tx. 12:28 < 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 12:29 < bjarnem> Hopefully some good, descriptive term will show up in time in a heureka moment! 12:30 < bjarnem> Thanks all! 12:30 -!- bjarnem [~bjarne@84.79.140.198] has left ##taproot-bip-review ["Leaving"] 12:38 < instagibbs> waxwing, I think I told you about both, the coinjoin one is the lying about whose inputs are whose. 12:38 < instagibbs> which is related but not solved 12:46 < instagibbs> (by script enhancements) 12:51 < 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. 12:51 -!- KeithMukai [6bb5bd56@107.181.189.86] has quit [Ping timeout: 260 seconds] 12:55 < instagibbs> yep, the input amount can be as simple as fee dumping attacks on hww 12:58 -!- daniel-k7 [5f5ae880@95.90.232.128] has quit [Remote host closed the connection] 13:04 < devrandom> ("signature preimage" and "signature digest"?) 13:20 < sipa> seems reasonable to me 13:26 < 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. 13:33 < felixweis> devrandom: renaming to reduce confusion is very welcome 13:37 < sipa> felixweis: that breaks upgradable key types 13:39 < sipa> oh, you mean for the witness program? that seems pointless as it's a cost paid by someone else 13:41 < sipa> and a pretty big philosophical break from trying to make all outputs look indistinguishable 13:41 < felixweis> yes, i wasnt also too serious actually. but it came into mind when reading the QA session and the 1.25 value 13:42 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 13:46 -!- b10c [~Thunderbi@2001:16b8:2e76:a500:2e47:30a4:c94e:dd99] has quit [Ping timeout: 250 seconds] 13:56 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 14:03 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 14:04 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Client Quit] 14:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 14:27 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 14:33 -!- sergei-t [~sergei@94.103.211.82] has left ##taproot-bip-review [] 15:07 -!- hebasto [~hebasto@95.164.65.194] has quit [Ping timeout: 246 seconds] 15:08 -!- hebasto [~hebasto@95.164.65.194] has joined ##taproot-bip-review 15:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 16:00 -!- arik_ [uid402902@gateway/web/irccloud.com/x-ujwariqvzzsszgtr] has quit [Quit: Connection closed for inactivity] 16:10 -!- Moller40_ [~mr@82.103.130.178] has quit [Ping timeout: 276 seconds] 16:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 18:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 18:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 18:27 -!- Moller40 [~mr@82.103.130.178] has joined ##taproot-bip-review 22:53 -!- xoyi- [~xoyi-@185.6.78.108] has joined ##taproot-bip-review 23:30 -!- Moller40_ [~mr@82.103.130.178] has joined ##taproot-bip-review 23:30 -!- Moller40 [~mr@82.103.130.178] has quit [Ping timeout: 240 seconds] 23:53 -!- Moller40_ [~mr@82.103.130.178] has quit [Ping timeout: 268 seconds] 23:54 -!- Moller40 [~mr@82.103.128.151] has joined ##taproot-bip-review