Sosthene00 · November 20, 2019 16:12
diff --git a/taproot_review_week2 + Q&A week 3 b/taproot_review_week2 + Q&A week 3
 11:34 ##taproot-bip-review: <@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
 11:36 ##taproot-bip-review: < xoyi-> ah right. Thanks for clarifying @aj
 12:10 ##taproot-bip-review: < 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?
 12:10 ##taproot-bip-review: < waxwing> feel like i must have missed something.
 12:11 ##taproot-bip-review: <@aj> waxwing: bip-taproot "Signature validation rules" says when hash_type = 00
 12:13 ##taproot-bip-review: < 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?
 12:13 ##taproot-bip-review: <@aj> waxwing: it is the same as sighash_all, except it's 64 bytes instead of 65 bytes
 12:13 ##taproot-bip-review: < waxwing> aj, ok. is that stated anywhere?
 12:13 ##taproot-bip-review: < waxwing> under 'hash_type' it says the legacy are still retained, including SIGHASH_ALL
 12:14 ##taproot-bip-review: < 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 :)
 12:14 ##taproot-bip-review: <@aj> waxwing: i think you just have to read through the logic and see it behaves the same way?
 12:15 ##taproot-bip-review: <@aj> waxwing: if you do SIGHASH_ALL | SIGHASH_ANYONECANPAY you get 0x81 but 0x80 isn't valid, which is another difference
 12:15 ##taproot-bip-review: < waxwing> aj, but where in 'Signature validation rules' does it tell you that it's ALL sighashing with 0x00?
 12:16 ##taproot-bip-review: < waxwing> it just says valid signature according to bip-schnorr and message set to transaction digest, but doesn't say which transaction digest right.
 12:16 ##taproot-bip-review: <@aj> waxwing: i think rationale entry 11 is the most explicit comment.
 12:17 ##taproot-bip-review: <@aj> waxwing: i meant if you read through the rules, 0x00 and 0x01 will give you the same semantics
 12:17 ##taproot-bip-review: < 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?
 12:18 ##taproot-bip-review: <@aj> waxwing: yeah, i think it just assumes you know which one's the most common type
 12:19 ##taproot-bip-review: < 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
 12:19 ##taproot-bip-review: < waxwing> that made me tend to discount the possibility that 0x00 was the same.
 12:19 ##taproot-bip-review: < waxwing> (point taken though about 0x80, 0x81)
 12:20 ##taproot-bip-review: <@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?
 12:21 ##taproot-bip-review: < 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 :)
 12:21 ##taproot-bip-review: < waxwing> i think one of the rationales already kinda covers (b), the one you mentioned prob.
 12:23 ##taproot-bip-review: < 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.
 12:23 ##taproot-bip-review: <@aj> yeah, i was surprised it's not stated
 12:23 ##taproot-bip-review: <@aj> file a PR or issue?
 12:23 ##taproot-bip-review: < waxwing> so why do we still have 0x01 then? is it because of the ACP flag so you can get 0x81?
 12:24 ##taproot-bip-review: < waxwing> aj, sure i'll do it, thanks for your help
 12:24 ##taproot-bip-review: <@aj> well having 0x01 matches SIGHASH_ALL as it currently exists
 12:25 ##taproot-bip-review: < waxwing> yes. not sure why that matters? new sig scheme and new digest? (so code isn't going to be the same anyway)
 12:25 ##taproot-bip-review: <@aj> but you could have 64-bytes = hash_type=0x01, and not allow 0x01 in 65-byte sigs
 12:25 ##taproot-bip-review: < waxwing> yeah that's what would have felt a lot more natural
 12:25 ##taproot-bip-review: < waxwing> adding a new flag value with the same semantics as an old one, which is not removed seems weird
 12:26 ##taproot-bip-review: <@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
 12:36 ##taproot-bip-review: < 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.
 12:36 ##taproot-bip-review: < waxwing> But I'll still PR it because it's just one extra sentence and it'd avoid confusion.
 12:43 ##taproot-bip-review: <@aj> waxwing: yeah, i think it's well defined, but it's not clear
 12:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:37 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 13:38 ##taproot-bip-review: < sosthene> Thanks aj and waxwing, it's clear now
 13:39 ##taproot-bip-review: < sosthene> I'm curious if there are still other reasons besides having 65 byte sig of any type
 13:40 ##taproot-bip-review: < sosthene> but that alone makes sense I guess
 13:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 14:10 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-rilqfgqtxiftabxx] has joined ##taproot-bip-review
 14:11 -!- udiWertheimer_ [sid190185@gateway/web/irccloud.com/x-rgyfvjbfxvlacmgl] has left ##taproot-bip-review []
 14:43 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-migmaalyvyfsqvmq] has joined ##taproot-bip-review
 15:02 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 15:26 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 15:30 ##taproot-bip-review: < instagibbs> is CastToBool defined in any BIP anywhere?
 15:32 ##taproot-bip-review: < instagibbs> I know where to find the code-based definition, just seemed like something that should be defined
 15:35 ##taproot-bip-review: < 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
 15:42 ##taproot-bip-review: < instagibbs> joke observation: if we ever get to gigameg blocks, we'll need to define what happens to `codeseparator_position` after 2^32 bytes.
 16:10 ##taproot-bip-review: < orfeas> compact_size() and CCompactSize are not defined in the 3 bips. Should there be a link to their definition?
 16:56 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 17:00 ##taproot-bip-review: < 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.
 17:07 ##taproot-bip-review: < elichai2> orfeas: well AFAIK they're not defined anywhere. it's an implementation detail
 17:09 ##taproot-bip-review: < orfeas> elichai2: isn't it consensus-critical though?
 17:10 ##taproot-bip-review: < orfeas> I guess they are defined as in the reference implementation then
 17:10 ##taproot-bip-review: < elichai2> orfeas: the consensus code is very far from being properly defined
 17:10 ##taproot-bip-review: < elichai2> (outside of Core itself obviously)
 17:11 ##taproot-bip-review: < orfeas> would a footnote with a link to the relevant Core function make sense? or this opens a whole new can of worms?
 17:15 -!- jenseven [[email protected]] has joined ##taproot-bip-review
 17:16 ##taproot-bip-review: < elichai2> that would be inconsistent with other PRs. i.e. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
 17:19 ##taproot-bip-review: < 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?
 17:21 ##taproot-bip-review: < elichai2> because in bitoin core when you serialize a CScript you get Bytes((CCompactSize(script) || script))
 17:22 ##taproot-bip-review: < elichai2> a rule of thumb, if you see CCompactSize asusme it's an implementation detail :)
 17:22 ##taproot-bip-review: < elichai2> (and when there are no private data fields assume length extension attacks aren't interesting :) )
 17:27 ##taproot-bip-review: < elichai2> instagibbs: pretty sure `CastToBool` isn't defined outside of the codebase
 17:29 ##taproot-bip-review: < 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
 17:30 ##taproot-bip-review: < sipa> they also match the current semantics where both 0 and 1 are valid hashtypes that correspond to SIGHASH_ALL
 17:31 ##taproot-bip-review: < 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.
 17:32 ##taproot-bip-review: < waxwing> second sentence i didn't get, you're not saying 0x00 is a valid sighash byte currently?
 17:32 ##taproot-bip-review: < sipa> currently (in legacy and segwit v0) 0 is a valid sighash type
 17:32 ##taproot-bip-review: < sipa> with the same semantics as ALL
 17:33 ##taproot-bip-review: < waxwing> oh i had no idea. is that ever used?
 17:35 ##taproot-bip-review: < 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
 17:35 ##taproot-bip-review: < sipa> waxwing: i doubt it
 17:36 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 17:37 ##taproot-bip-review: < 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.)
 17:39 ##taproot-bip-review: < sipa> agreed
 17:43 ##taproot-bip-review: < jonatack> instagibbs: was disconnected so this may be out of band, AFAIK CastToBool is only mentioned in bip-0141.mediawiki:107, and not defined
 17:52 ##taproot-bip-review: < sipa> it's implicitly defined by the source code, but i think it's worth spelling out exactly
 18:16 ##taproot-bip-review: < jonatack> src/script/interpreter.cpp:35:bool CastToBool(const valtype& vch)
 18:46 -!- bjarnem [[email protected]] has joined ##taproot-bip-review
 18:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 19:01 ##taproot-bip-review: < jnewbery> Hi folks. Next Q&A starts in one hour
 19:22 -!- jeremyrubin [[email protected]] has joined ##taproot-bip-review
 19:23 ##taproot-bip-review: < 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.
 19:24 ##taproot-bip-review: < jonatack> (grepping in the taproot branch of sipa/bitcoin)
 19:24 ##taproot-bip-review: < sipa> jonatack: all the "signing" code is in feature_taproot.py
 19:24 ##taproot-bip-review: < sipa> some of it can probably be abstracted out
 19:29 ##taproot-bip-review: < 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"
 19:30 ##taproot-bip-review: < jonatack> perhaps a link... I don't see most of that code (as named)
 19:32 ##taproot-bip-review: < sipa> jonatack: oh! that's referring to https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
 19:32 ##taproot-bip-review: < sipa> not the bitcoin core branch
 19:32 ##taproot-bip-review: < sipa> i think?
 19:33 -!- pyskell [[email protected]] has joined ##taproot-bip-review
 19:33 -!- pyskell [~meh@unaffiliated/pyskell] has joined ##taproot-bip-review
 19:35 ##taproot-bip-review: < jonatack> hm! will pull down sipa/bips to grep it
 19:40 ##taproot-bip-review: < 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
 19:41 ##taproot-bip-review: < sipa> what specific function are you missing?
 19:42 ##taproot-bip-review: < sipa> or what reference is unexplained?
 19:44 ##taproot-bip-review: < jonatack> I was looking for where the code presented in bip-taproot lives, e.g. the functions taproot_tweak_*, taproot_sign_*, taproot_output_script
 19:44 ##taproot-bip-review: < sipa> they're in the bip?
 19:44 ##taproot-bip-review: < jonatack> Yes, only in the bip
 19:44 ##taproot-bip-review: < sipa> ah, you mean is there some python file you can use directly? no
 19:45 ##taproot-bip-review: < sipa> perhaps there should be
 19:45 ##taproot-bip-review: < jonatack> Thought it might be extracted from elsewhere as it was described as the Python3 "bip-schnorr reference code"
 19:46 ##taproot-bip-review: < jonatack> (in bip-taproot)
 19:46 ##taproot-bip-review: < sipa> the bip-schnorr reference code is https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
 19:46 ##taproot-bip-review: < sipa> there is no similar thing for bip-taproot
 19:47 ##taproot-bip-review: < jonatack> ty for the clarification
 19:47 ##taproot-bip-review: < sipa> we probably want to have that when writing test vectors for taproot
 19:49 -!- pinheadmz [[email protected]] has joined ##taproot-bip-review
 19:55 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 19:57 ##taproot-bip-review: < 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
 19:57 ##taproot-bip-review: < sipa> ok
 20:00 ##taproot-bip-review: <@moneyball> Q&A about to start...
 20:00 ##taproot-bip-review: < jnewbery> ...
 20:00 ##taproot-bip-review: <@aj> #startmeeting
 20:00 ##taproot-bip-review: < lightningbot> Meeting started Tue Nov 12 19:00:15 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
 20:00 ##taproot-bip-review: < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 20:00 ##taproot-bip-review: < jnewbery> hi
 20:00 ##taproot-bip-review: < sipa> hi
 20:00 ##taproot-bip-review: < bjarnem> hi
 20:00 ##taproot-bip-review: < schmidty> Hi
 20:00 ##taproot-bip-review: < r251d> hi
 20:00 ##taproot-bip-review: <@moneyball> hi
 20:00 ##taproot-bip-review: < ariard> hi
 20:00 ##taproot-bip-review: < jonatack> hi
 20:01 ##taproot-bip-review: < devrandom> hi
 20:01 ##taproot-bip-review: < kabaum> hi
 20:01 ##taproot-bip-review: <@aj> hi
 20:01 ##taproot-bip-review: < hebasto> hi
 20:02 ##taproot-bip-review: < cdecker> Hi
 20:02 ##taproot-bip-review: < hebasto> Q from group 5 (1/2): 1. What happens when using other leaf versions now before they are defined?
 20:02 ##taproot-bip-review: < fjahr> hi
 20:03 -!- michaelfolkson [[email protected]] has joined ##taproot-bip-review
 20:03 ##taproot-bip-review: < sipa> hebasto: they're spendable by anyone (who can give the internal key and merkle path)
 20:03 ##taproot-bip-review: < bjarnem> I was having the same question and I don't think this is specified in the BIP.
 20:04 ##taproot-bip-review: < sipa> bjarnem: it is, i think, though not explicitly
 20:04 ##taproot-bip-review: < hebasto> yes, it is not obvious from bip...
 20:04 ##taproot-bip-review: < sipa> bip-taproot just states that any relevant scripts are executed
 20:04 ##taproot-bip-review: < jnewbery> would those spends be non-standard initially?
 20:04 ##taproot-bip-review: < sipa> jnewbery: of course
 20:04 ##taproot-bip-review: < kabaum> I think taproot rationale [10] is what we're looking for,
 20:04 ##taproot-bip-review: < pyskell> hi
 20:05 -!- arik_ [uid402902@gateway/web/irccloud.com/x-ujwariqvzzsszgtr] has joined ##taproot-bip-review
 20:05 ##taproot-bip-review: < sipa> bip-tapscript defines one for one particular leaf version
 20:05 ##taproot-bip-review: <@aj> sipa: "of course" -- should it be written down somewhere which bits should be treated as non-standard?
 20:05 ##taproot-bip-review: < jnewbery> I think standardness falls outside the BIPs, which only deal with consensus, no?
 20:05 ##taproot-bip-review: < sipa> perhaps we can add that if no script semantics are defined for a particular leaf version, the spend is unconditionally valid
 20:05 -!- KeithMukai [[email protected]] has joined ##taproot-bip-review
 20:05 ##taproot-bip-review: < sipa> jnewbery: yeah, that's my thinking
 20:05 ##taproot-bip-review: < Moller40> Hi
 20:06 ##taproot-bip-review: < cdecker> That'd be a nice addition
 20:06 ##taproot-bip-review: < 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
 20:06 ##taproot-bip-review: <@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?
 20:07 ##taproot-bip-review: < sipa> but i also see that it'd be nice to have it written up somewhere
 20:07 ##taproot-bip-review: <@aj> sipa: yeah, agree on both points :)
 20:08 ##taproot-bip-review: < hebasto> Q from group 5 (2/2). Disabled script opcodes."unexecuted branch" means unexecuted branch in the revealed script?
 20:08 -!- sergei-t [[email protected]] has joined ##taproot-bip-review
 20:08 ##taproot-bip-review: < sipa> hebasto: correct
 20:08 ##taproot-bip-review: < hebasto> sipa; ty
 20:08 ##taproot-bip-review: < sipa> i see how branch can be confusing here
 20:08 ##taproot-bip-review: < hebasto> a bit ;)
 20:08 ##taproot-bip-review: < sipa> it means execution branch of the script, not merkle branch
 20:09 ##taproot-bip-review: < cdecker> Related: aborting when decoding the script instead of executing is merely a performance improvement, or am I missing something?
 20:09 ##taproot-bip-review: < hebasto> maybe "execution branch" and "merkle branch" are good wording for bip?
 20:10 ##taproot-bip-review: < sipa> cdecker: it also implies that any later success isn't apllicable
 20:10 ##taproot-bip-review: < sipa> hebasto: sure
 20:10 ##taproot-bip-review: < bjarnem> Q: Regarding the tweak value `t` must be less than the SECP256K1_ORDER: What to do if the calculated value is greater/equal?
 20:10 ##taproot-bip-review: < sipa> bjarnem: it won't be
 20:10 ##taproot-bip-review: < jnewbery> bjarnem: buy a lottery ticket
 20:10 ##taproot-bip-review: < cdecker> Right, but it allows statically discarding things early on, without having to execute
 20:11 ##taproot-bip-review: < 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
 20:12 ##taproot-bip-review: < 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
 20:12 ##taproot-bip-review: < 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.
 20:12 ##taproot-bip-review: < cdecker> Yep, just felt strange to abort on a script branch that isn't even executed :-)
 20:13 ##taproot-bip-review: < sipa> cdecker: i see
 20:13 ##taproot-bip-review: < bjarnem> Q: Regarding the squareness of `Q`: (Disclaimer: I am not a cryptographer, so I hope this question is not naive)
 20:13 ##taproot-bip-review: < 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`).
 20:13 ##taproot-bip-review: < 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?
 20:14 -!- michaelfolkson [[email protected]] has joined ##taproot-bip-review
 20:14 ##taproot-bip-review: < 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
 20:15 ##taproot-bip-review: < cdecker> The formulation is clear, I was just wondering about the rationale. All good, don't want to hold up the QA ^^
 20:15 ##taproot-bip-review: < 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).
 20:15 ##taproot-bip-review: < 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
 20:15 ##taproot-bip-review: < pyskell> Is it referring to the SHA256 opcode or something else?
 20:15 ##taproot-bip-review: < sipa> bjarnem: when signing using the script path, you have to actually know the squaredness of Y, otherwise the commitment equation won't hold
 20:16 ##taproot-bip-review: < 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.
 20:16 ##taproot-bip-review: < 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).
 20:16 ##taproot-bip-review: <@aj> sipa, bjarnem: and you can't just try both options if we want to batch verify to make it more efficient
 20:17 ##taproot-bip-review: < sipa> jnewbery: it's stronger than that! you can recognize an annex in an input without knowing which output is being spent
 20:17 ##taproot-bip-review: < 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
 20:17 ##taproot-bip-review: < sipa> jnewbery: which is by design
 20:17 ##taproot-bip-review: < 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 :)
 20:18 ##taproot-bip-review: < jnewbery> right. What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
 20:18 ##taproot-bip-review: < sipa> bjarnem: feel free to PR a clarification if you find text that would make it easier to understand for you
 20:18 ##taproot-bip-review: < sipa> jnewbery: did you get the idea of using an annex to artifically increase an input's weight?
 20:19 ##taproot-bip-review: < jnewbery> I understood the purpose, but wondered why you couldn't just do that in the tapscript
 20:19 ##taproot-bip-review: < sipa> ?
 20:19 ##taproot-bip-review: < sipa> oh you mean by putting a big push + OP_DROP in the script?
 20:20 ##taproot-bip-review: < 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
 20:20 ##taproot-bip-review: < jnewbery> yes, why not just add that weight to the script
 20:20 ##taproot-bip-review: < sipa> jnewbery: that seems.like highly inefficient use of the chain
 20:21 ##taproot-bip-review: < sipa> if you need to pad it with garbage
 20:21 ##taproot-bip-review: < jnewbery> isn't that what the annex is doing?
 20:21 ##taproot-bip-review: < 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)?
 20:21 ##taproot-bip-review: < ariard> can't it be used also for a per-input locktime IIRC ?
 20:21 ##taproot-bip-review: < sipa> jnewbery: no!
 20:21 ##taproot-bip-review: < jnewbery> oh, then I misunderstand!
 20:22 ##taproot-bip-review: < 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
 20:22 ##taproot-bip-review: < sipa> and the value of that two byte field is added to the weight of the tx
 20:23 ##taproot-bip-review: < sipa> while simultaneously equivalently increasing the budget for expensivw opcodes in tbe script
 20:23 ##taproot-bip-review: < sipa> ariard: for examlle
 20:23 ##taproot-bip-review: < sipa> ariard: or a block height hash requirement
 20:23 ##taproot-bip-review: < ariard> sipa: yes but the value of that two byte can be choosed by the spender how would you make it mandatory ?
 20:24 ##taproot-bip-review: < sipa> ariard: if they set it tol high, they'll pay extra fees
 20:24 ##taproot-bip-review: < jnewbery> after this imaginary future OP_VERIFYSNARK softfork, are unupgraded miners still able to mine? How do they account block weight?
 20:24 ##taproot-bip-review: < ariard> don't you need to combine with some sighash flags to force annex value being covered by transaction digest
 20:24 ##taproot-bip-review: < sipa> of they set it too low, the script will fail
 20:24 ##taproot-bip-review: <@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
 20:24 ##taproot-bip-review: < sipa> ariard: annexes are always covered by signatures
 20:24 ##taproot-bip-review: < hebasto> sipa: annex could increase weight without bloating chain, right?
 20:25 ##taproot-bip-review: < sipa> hebasto: right
 20:25 ##taproot-bip-review: < sipa> jnewbery: increasing the weight for a transaction is a softfork
 20:25 ##taproot-bip-review: < sipa> and using an unknown annex is nonstandard
 20:25 ##taproot-bip-review: < sipa> so i think this is perfectly possible to deploy
 20:25 ##taproot-bip-review: < sipa> (that doesn't mean we need to; there may never be a reason to)
 20:26 ##taproot-bip-review: < 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 ?
 20:26 ##taproot-bip-review: < jnewbery> unupgraded miners just don't include anything with an annex because it's non-standard?
 20:26 ##taproot-bip-review: < sipa> right
 20:26 ##taproot-bip-review: < sipa> ariard: the budget is the size of the input, which if amended by an annex, includes that amount
 20:27 ##taproot-bip-review: < waxwing> wait surely we expect miners to upgrade in SF scenarios to avoid mis-mining?
 20:27 ##taproot-bip-review: < nickler> sipa: with op_zkverify would the limit be something like #(OP_CHECKSIG)*50 + #(OP_ZKVERIFY)*X <= weight?
 20:27 ##taproot-bip-review: < sipa> nickler: exactly
 20:27 ##taproot-bip-review: < ariard> sipa: and you check the budget against which reference value ? that's where I choke
 20:27 ##taproot-bip-review: < sipa> ariard: the weight of the input
 20:28 ##taproot-bip-review: < sipa> right now that is literally the number of bytes of the witness
 20:28 ##taproot-bip-review: < sipa> if an annex is defined that increments the weight, that counts too
 20:28 ##taproot-bip-review: < elichai2> nickler: op_zkverify?
 20:28 ##taproot-bip-review: <@moneyball> elichai2: a hypothetical example
 20:29 ##taproot-bip-review: < jnewbery> What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
 20:29 ##taproot-bip-review: < sipa> jnewbery: for this annex weight increase example it's useful
 20:30 ##taproot-bip-review: < sipa> as otherwise you wouldn't be able to compute a tx's weight without access to the output being spent
 20:30 ##taproot-bip-review: < 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?
 20:31 ##taproot-bip-review: < sipa> devrandom: exactly
 20:31 ##taproot-bip-review: < elichai2> moneyball: :) I thought we're already planning tapscript V2 :P
 20:31 ##taproot-bip-review: < 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?
 20:32 ##taproot-bip-review: < sipa> devrandom: feel free
 20:32 ##taproot-bip-review: < devrandom> OK
 20:32 ##taproot-bip-review: < 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"?
 20:32 ##taproot-bip-review: < jnewbery> would there ever be a reason to need more than one annex?
 20:33 ##taproot-bip-review: < sipa> jnewbery: possibly
 20:33 ##taproot-bip-review: <@aj> jnewbery: if you need a per input timelock and are using OP_ZKVERIFY, you'd use two annex entries maybe
 20:34 ##taproot-bip-review: < cdecker> Couldn't they be serialized back to back then?
 20:34 ##taproot-bip-review: < jnewbery> so should we change the definition to be that any n trailing witness elements starting 0x50 are annexes?
 20:34 ##taproot-bip-review: < sipa> jnewbery: yes, that's possible, but concatenating them is more efficient i think
 20:35 ##taproot-bip-review: <@aj> 0x50 { <len> <tag> <values> } seems a fine encoding to only use a single witness element
 20:35 ##taproot-bip-review: < jnewbery> got it
 20:35 ##taproot-bip-review: <@aj> (makes lightning people twitch since they like tag/length/value though)
 20:35 ##taproot-bip-review: < sipa> it's also a tradeoff between taking a complexity hit now, and wondering whether we'll ever even need it
 20:36 ##taproot-bip-review: < cdecker> aj: just thought the same :-)
 20:36 ##taproot-bip-review: < nickler> devrandom: agree that this is confusing. Made more sense when the section was called Privacy.
 20:36 ##taproot-bip-review: < sipa> by saying some annex but not specifying any of its semantics we maximally defer the complexity to when it's needed
 20:36 ##taproot-bip-review: < jnewbery> sipa: makes sense. Thanks
 20:39 ##taproot-bip-review: < sipa> pyskell: the comment on the tagged hashes use refers to all sha256 anywhere in any protocol related to bitcoin
 20:39 ##taproot-bip-review: < sipa> not just inside script
 20:39 ##taproot-bip-review: < sipa> and the effect of being wrong about it is very likely nothing
 20:40 ##taproot-bip-review: < sipa> in most cases tagged hashing is not needed
 20:40 ##taproot-bip-review: < 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)
 20:40 ##taproot-bip-review: < sipa> jnewbery: good point
 20:41 ##taproot-bip-review: < 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?
 20:41 ##taproot-bip-review: < pyskell> sipa: Gotcha, thanks for clarifying
 20:41 ##taproot-bip-review: < waxwing> devrandom, i think i remember coming up with 1.5 vbytes heavier for p2tr vs p2wpkh when discussing it with aj last week
 20:41 ##taproot-bip-review: < sipa> devrandom: for starters, i don't think this matters, because the output cost is paid by the sender
 20:41 ##taproot-bip-review: < waxwing> i mean average of course, not exact
 20:42 ##taproot-bip-review: < sipa> and the sender is already willing to pay fot 32-byte witness programs, or he'd not have implemented bip173
 20:43 ##taproot-bip-review: < waxwing> that's an argument on segwit v1 vs v0 uptake, but not legacy to v1 uptake right
 20:43 ##taproot-bip-review: < sipa> right
 20:43 ##taproot-bip-review: < bjarnem> Q: Regarding wording for signature hash:
 20:43 ##taproot-bip-review: < bjarnem> Under "Constructing and spending Taproot outputs" -> "Spending using the key path":
 20:43 ##taproot-bip-review: < 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?
 20:43 ##taproot-bip-review: < nickler> waxwing: I came up with 1.25 :) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7
 20:44 ##taproot-bip-review: < waxwing> nickler, lol i'll take it.
 20:44 ##taproot-bip-review: < sipa> bjarnem: yep
 20:45 ##taproot-bip-review: < 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 ;)
 20:45 ##taproot-bip-review: <@moneyball> sipa: thoughts on adjusting the weight calculation to make spending PT2R slightly more favorable? advantage being increased adoption of it + improved privacy/fungibility
 20:45 ##taproot-bip-review: < sipa> moneyball: that would be a hard fork. good luck.
 20:45 ##taproot-bip-review: <@moneyball> oh...
 20:46 ##taproot-bip-review: < 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.
 20:47 ##taproot-bip-review: < waxwing> sipa, or maybe swipe a byte or two off the witness program? :)
 20:47 ##taproot-bip-review: < 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?
 20:48 ##taproot-bip-review: <@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)
 20:48 ##taproot-bip-review: < nickler> bjarnem: agreed
 20:48 ##taproot-bip-review: < bjarnem> (edit: I meant also in BIP-TapSCRIPT)
 20:48 ##taproot-bip-review: < devrandom> aj: got it
 20:49 ##taproot-bip-review: < 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
 20:49 ##taproot-bip-review: < waxwing> sipa, the motivation? sure yeah that makes sense. i'll copy in the notes i made about it earlier.
 20:50 ##taproot-bip-review: < 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)
 20:50 ##taproot-bip-review: < sipa> waxwing: yeah
 20:50 ##taproot-bip-review: <@aj> sipa: maybe "signature digest" for the stuff you feed into the hash function and "signature hash" for the result?
 20:50 ##taproot-bip-review: <@aj> sipa: it keeps annoying me there's no term to use for the stuff you feed into the hash
 20:51 ##taproot-bip-review: < sipa> aj: "message digest" is a historical name for cryptographic hash function, so i wouldn't use digest to refer to its preimage
 20:51 ##taproot-bip-review: < 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?
 20:51 ##taproot-bip-review: <@aj> sipa: fair
 20:52 ##taproot-bip-review: < waxwing> devrandom, yes i was wondering about that, is it related to the kinds of attacks instagibbs came up with wrt coinjoin and similar?
 20:52 ##taproot-bip-review: < 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
 20:52 ##taproot-bip-review: < sipa> the result is that a malicious online wallet can trick an offline wallet in spending more on fees than it intends to
 20:54 ##taproot-bip-review: < waxwing> right so not specifically coinjoin but that's one of the main ways it might come up
 20:54 ##taproot-bip-review: < sipa> right
 20:54 ##taproot-bip-review: < sipa> it's more general than that, but indeed
 20:54 ##taproot-bip-review: < bjarnem> I already asked but cannot find an answer, so in case it was overlooked in the discussion here it comes again :)
 20:54 ##taproot-bip-review: < 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)?
 20:55 ##taproot-bip-review: < devrandom> sipa: got it, I assumed that HW wallets signed all inputs at the same time
 20:55 ##taproot-bip-review: < sipa> bjarnem: OP_SUCCESSx is the most powerful upgrade mechanism there is
 20:55 ##taproot-bip-review: < sipa> bjarnem: if you'd have me pick one of leaf versions, upgradable pubkeys, or op_success, i'd pick the last one
 20:56 ##taproot-bip-review: < bjarnem> sipa: Doesn't leaf versioning have the same power, allowing to change the semantics of the script language like segwit versioning??
 20:56 ##taproot-bip-review: < sipa> bjarnem: yes, but you need a new leaf version any time you introduce a new opcode for example
 20:56 ##taproot-bip-review: < sipa> with OP_SUCCESSx you just pick a number and define it; it can be done in parallel with other new opcodes even
 20:57 ##taproot-bip-review: < devrandom> group 3 Q 5/5: should the BIP have a Requires header referring to schnorr, etc.?
 20:57 ##taproot-bip-review: < bjarnem> sipa: ah, ok I see that
 20:57 ##taproot-bip-review: < 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
 20:58 ##taproot-bip-review: < sipa> and leaf versions essentially come at zero cost, because we have a few unused bits in the control block anyway
 20:58 ##taproot-bip-review: < sipa> devrandom: yeah
 20:58 ##taproot-bip-review: < nickler> devrandom: I think so. there's a PR for that already https://github.com/sipa/bips/pull/135
 20:58 ##taproot-bip-review: < bjarnem> sipa: thanks for the clarifiaction of the reasoning!
 20:59 ##taproot-bip-review: < 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
 21:00 ##taproot-bip-review: <@aj> "feel free to help" ~= "please do help" :)
 21:00 ##taproot-bip-review: <@moneyball> shall we wrap?
 21:00 ##taproot-bip-review: < 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
 21:00 ##taproot-bip-review: < devrandom> will PR for the stuff I asked
 21:00 ##taproot-bip-review: < sipa> awesome, thanks
 21:00 ##taproot-bip-review: < sipa> i need to run, thanks everyone!
 21:00 ##taproot-bip-review: <@moneyball> #endmeeting
 21:01 ##taproot-bip-review: < jonatack> thanks!
 21:01 -!- Moller40_ [[email protected]] has joined ##taproot-bip-review
 21:01 ##taproot-bip-review: < b10c> Thanks!
 21:01 ##taproot-bip-review: < kabaum> Thanks
 21:01 ##taproot-bip-review: < bjarnem> Thanks a lot!!
 21:01 ##taproot-bip-review: < cdecker> Thanks ^^
 21:01 ##taproot-bip-review: <@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
 21:01 ##taproot-bip-review: <@aj> #endmeeting
 21:01 ##taproot-bip-review: < lightningbot> Meeting ended Tue Nov 12 20:01:28 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 21:01 ##taproot-bip-review: < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.html
 21:01 ##taproot-bip-review: < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.txt
 21:01 ##taproot-bip-review: < lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
 21:01 ##taproot-bip-review: < fjahr> thanks
 21:01 ##taproot-bip-review: < chm-diederichs> thanks
 21:01 ##taproot-bip-review: <@aj> so i guess that answers my question about whether someone else can end a meeting after it's started too...
 21:02 ##taproot-bip-review: < jnewbery> Thanks everyone!
 21:05 ##taproot-bip-review: < waxwing> yeah thanks
 21:06 ##taproot-bip-review: < waxwing> to play devil's avocado, 'signature hash' is unfortunate since it suggests hashing a signature, 'transaction digest' is obscure but descriptive.
 21:06 ##taproot-bip-review: < waxwing> ironically the whole point of segwit is to not do (some) 'signature hashing' :)
 21:07 -!- daniel-k7 [[email protected]] has joined ##taproot-bip-review
 21:10 ##taproot-bip-review: < bjarnem> waxwing: "transaction digest" for me is also more expressive and easier to understand immediately.
 21:10 ##taproot-bip-review: < sipa> we'd still need a term for the preimage of that transaction digest
 21:10 ##taproot-bip-review: < 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.
 21:11 ##taproot-bip-review: < sipa> r251d: fair point
 21:15 ##taproot-bip-review: <@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)
 21:16 ##taproot-bip-review: < sipa> different inputs (including different annexes in them), different codeseps, different sighash bytes, ...
 21:24 ##taproot-bip-review: < 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? :)
 21:25 ##taproot-bip-review: <@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
 21:25 ##taproot-bip-review: < r251d> "Transaction digest" is probably fine if the BIP clarifies that multiple such digests can be in one tx.
 21:28 ##taproot-bip-review: < 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
 21:29 ##taproot-bip-review: < bjarnem> Hopefully some good, descriptive term will show up in time in a heureka moment!
 21:30 ##taproot-bip-review: < bjarnem> Thanks all!
 21:30 -!- bjarnem [[email protected]] has left ##taproot-bip-review ["Leaving"]
 21:38 ##taproot-bip-review: < instagibbs> waxwing, I think I told you about both, the coinjoin one is the lying about whose inputs are whose.
 21:38 ##taproot-bip-review: < instagibbs> which is related but not solved
 21:46 ##taproot-bip-review: < instagibbs> (by script enhancements)
 21:51 ##taproot-bip-review: < 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.
 21:55 ##taproot-bip-review: < instagibbs> yep, the input amount can be as simple as fee dumping attacks on hww
 22:04 ##taproot-bip-review: < devrandom> ("signature preimage" and "signature digest"?)
 22:20 ##taproot-bip-review: < sipa> seems reasonable to me
 22:26 ##taproot-bip-review: < 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.
 22:33 ##taproot-bip-review: < felixweis> devrandom: renaming to reduce confusion is very welcome
 22:37 ##taproot-bip-review: < sipa> felixweis: that breaks upgradable key types
 22:39 ##taproot-bip-review: < sipa> oh, you mean for the witness program? that seems pointless as it's a cost paid by someone else
 22:41 ##taproot-bip-review: < sipa> and a pretty big philosophical break from trying to make all outputs look indistinguishable
 22:41 ##taproot-bip-review: < felixweis> yes, i wasnt also too serious actually. but it came into mind when reading the QA session and the 1.25 value
 22:42 -!- michaelfolkson [[email protected]] has joined ##taproot-bip-review
 23:03 -!- michaelfolkson [[email protected]] has joined ##taproot-bip-review
 23:27 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 23:33 -!- sergei-t [[email protected]] has left ##taproot-bip-review []
 00:08 -!- hebasto [[email protected]] has joined ##taproot-bip-review
 00:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 03:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 03:27 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 07:53 -!- xoyi- [[email protected]] has joined ##taproot-bip-review
 08:30 -!- Moller40_ [[email protected]] has joined ##taproot-bip-review
 08:54 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 09:18 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 09:59 -!- b10c [[email protected]] has joined ##taproot-bip-review
 10:24 -!- Moller40_ [[email protected]] has joined ##taproot-bip-review
 11:18 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 12:04 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 12:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:20 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 13:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 14:49 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 14:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 15:40 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 16:58 ##taproot-bip-review: < orfeas> is the name `taproot_sign_script()` a slight abuse of the term "sign"? The sigining algorithm isn't invoked in the function
 16:58 ##taproot-bip-review: < orfeas> an alternative could be `taproot_generate_script_sig()` or similar
 16:59 ##taproot-bip-review: < instagibbs> that would sound like scriptSig, which segwit v1 never touches
 16:59 ##taproot-bip-review: < orfeas> correct
 17:05 ##taproot-bip-review: < orfeas> `taproot_prove_script()` or `taproot_choose_script_path()` then?
 17:07 ##taproot-bip-review: < sipa> orfeas: i think signing is an acceptable term
 17:08 ##taproot-bip-review: < sipa> orfeas: in the sense that you see a scriptPubKey as the public key of the "script" digital signature system, and the scriptSig/witness is the signature for it
 17:12 ##taproot-bip-review: < orfeas> I feel this is a complete redefinition of the terms "public key" and "signature".
 17:13 ##taproot-bip-review: < orfeas> (note that I'm biased: I always found the terms script{PubKey,Sig} somewhat confusing)
 17:14 ##taproot-bip-review: < instagibbs> it was redefined 11 years ago, sorry :P
 17:14 ##taproot-bip-review: < instagibbs> err I guess 10 still
 17:15 ##taproot-bip-review: < orfeas> '=D
 17:16 ##taproot-bip-review: < orfeas> fair enough
 17:23 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 17:33 -!- andytoshi [[email protected]] has joined ##taproot-bip-review
 17:33 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review
 18:36 -!- so [~so@unaffiliated/so] has joined ##taproot-bip-review
 18:48 ##taproot-bip-review: < devrandom> trivial wording improvements from yesterday Q&A https://github.com/sipa/bips/pull/144
 19:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 19:36 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 21:12 -!- xoyi- [[email protected]] has joined ##taproot-bip-review
 21:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 21:45 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 22:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 23:00 ##taproot-bip-review: < pinheadmz> sipa: is a witness with an annex non-standard?
 23:00 ##taproot-bip-review: < pinheadmz> https://github.com/sipa/bitcoin/blob/taproot/test/functional/feature_taproot.py#L390
 23:18 -!- b10c [[email protected]] has joined ##taproot-bip-review
 23:34 ##taproot-bip-review: < instagibbs> pinheadmz, look at `IsWitnessStandard` definition in the taproot branch, doesn't appear to be non-standard
 23:35 ##taproot-bip-review: < instagibbs> could be reading it wrong of course, but it's covered by the sighash, so it's not malleable by third party
 23:56 ##taproot-bip-review: < andytoshi> pinheadmz: sipa tells me "yes absolutely. any annex at all is currently nonstandard"
 23:56 ##taproot-bip-review: < andytoshi> but he is driving rn and cannot respond himself
 23:58 ##taproot-bip-review: < pinheadmz> andytoshi: ha! thank you for relaying, and for driving safely!
 23:59 ##taproot-bip-review: < instagibbs> I'd appreciate a pointer in the reference code, I am apparently blind
 23:59 ##taproot-bip-review: < pinheadmz> instagibbs: link ^^
 23:59 ##taproot-bip-review: < pinheadmz> I was looking at the pyhton test
 00:00 ##taproot-bip-review: < instagibbs> reference implementation meaning the C++ logic which makes it non-standard
 00:00 ##taproot-bip-review: < pinheadmz> id have to look, just saw this line in the test
 00:00 ##taproot-bip-review: < pinheadmz> https://github.com/sipa/bitcoin/blob/taproot/test/functional/feature_taproot.py#L390
 00:00 ##taproot-bip-review: < pinheadmz> and didnt see anything calling annexes non-std in the bip
 00:01 ##taproot-bip-review: < instagibbs> standardness isn't generally BIP material
 00:01 ##taproot-bip-review: < andytoshi> heh i can take a look
 00:01 ##taproot-bip-review: < andytoshi> but i won't know better than ou
 00:01 ##taproot-bip-review: < pinheadmz> instagibbs: oh really? We wouldn't want to mention it?
 00:02 ##taproot-bip-review: < andytoshi> because it's a Core implementation detail, arguably
 00:02 ##taproot-bip-review: < andytoshi> (well, this is a very idealized view of standardness)
 00:02 ##taproot-bip-review: < pinheadmz> yeah and if I'm not mistaken, has no defined function (yet)
 00:04 ##taproot-bip-review: < pinheadmz> Does CLEANSTACK apply to the witness stack? Is that where the annex becomes non-std?
 00:06 ##taproot-bip-review: < andytoshi> pinheadmz: no, it's explicit :)
 00:06 ##taproot-bip-review: < andytoshi> pieter says there is a VERIFY flag for it
 00:06 ##taproot-bip-review: < andytoshi> that you should be able to grep for
 00:10 ##taproot-bip-review: < pinheadmz> Can he remember the line number without taking his eyes off the road? X-D
 00:12 ##taproot-bip-review: < pinheadmz> here we go
 00:12 ##taproot-bip-review: < pinheadmz> https://github.com/sipa/bitcoin/blob/taproot/src/policy/policy.h#L76
 00:12 ##taproot-bip-review: < pinheadmz> SCRIPT_VERIFY_DISCOURAGE_UNKNOWN_ANNEX
 00:12 ##taproot-bip-review: < andytoshi> lol that's the one
 01:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 01:41 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 01:42 -!- davterra [[email protected]] has joined ##taproot-bip-review
 02:40 ##taproot-bip-review: < sipa> q&a in 20 minutes?
 02:43 ##taproot-bip-review: <@aj> yep
 02:44 ##taproot-bip-review: <@aj> sipa: you able to be around for the full hour? i'll need to get on a plane part way through
 02:44 ##taproot-bip-review: < sipa> no, i probably won't be
 02:45 ##taproot-bip-review: < sipa> or rather, i'll be here the whole hour but only intermittently
 03:00 ##taproot-bip-review: <@aj> #startmeeting
 03:00 ##taproot-bip-review: < lightningbot> Meeting started Thu Nov 14 02:00:55 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
 03:00 ##taproot-bip-review: < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 03:01 -!- Tibo [[email protected]] has joined ##taproot-bip-review
 03:01 ##taproot-bip-review: <@aj> hey all, might be an abbreviated session this time
 03:02 -!- soju [uid403160@gateway/web/irccloud.com/x-ujnbswrsbuznqxph] has joined ##taproot-bip-review
 03:05 ##taproot-bip-review: < instagibbs> hi
 03:06 ##taproot-bip-review: < fanquake> hi
 03:09 ##taproot-bip-review: < instagibbs> did we run out of topics for this week or am i disconnected
 03:09 ##taproot-bip-review: <@aj> doesn't seem like anyone's got any questions
 03:10 ##taproot-bip-review: < fanquake> instagibbs I'm not seeing any chatter either
 03:11 ##taproot-bip-review: < instagibbs> were they any lingering disccusions from last QA? I missed t
 03:13 ##taproot-bip-review: <@aj> there was a fair bit of discussion about upgrade stuff -- OP_SUCCESS and annex things
 03:16 ##taproot-bip-review: <@aj> there's also a few suggestions/PRs along the lines of improving motivation/rationale
 03:17 ##taproot-bip-review: < instagibbs> i found the rationale helped a lot with disambiguating the meaning of the text, especially successx section
 03:17 ##taproot-bip-review: < instagibbs> might mean a slight cleanup warranted
 03:21 ##taproot-bip-review: <@aj> yeah, PRs welcome :)
 03:21 ##taproot-bip-review: < instagibbs> the only thing bothering me really is the definition of codeseparator_position, if we get 4GB+ blocks it is undefined what happens when the marked position is beyond 2^32 :P
 03:22 ##taproot-bip-review: < instagibbs> now that scripts are unbounded in size, only implicitly bounded by blockweight
 03:22 ##taproot-bip-review: <@aj> we already bumped that from 16 bits when the 10k script length limit got dropped
 03:28 ##taproot-bip-review: <@aj> anyway, big blocks would be a hard fork, so if we made it more of a hard fork we could add another spend_type bit to allow for encoding the codesep pos via compactsize (if 64bit numbers are enough for you) or similar
 03:28 ##taproot-bip-review: <@aj> or we could reintroduce a script size limit that's more than 4M but less than 4G
 03:31 ##taproot-bip-review: < instagibbs> yes was not a particularly pressing/serious concern
 03:32 ##taproot-bip-review: <@aj> any more progress with the multisig tree jupyter notebook?
 03:33 ##taproot-bip-review: < instagibbs> no sorry :) it works, dies a combinatoric death at 21-of-30
 03:34 ##taproot-bip-review: < instagibbs> vast majority of the computation is computing the musig pubkeys, someone noted that the tweak could just be the superset of all n signers, might bring down the computation
 03:38 ##taproot-bip-review: <@aj> any thoughts on whether it makes more sense to stay below ~30 signers, or go unaccountable with threshold-musig, or use checksigadd or similar script?
 03:39 ##taproot-bip-review: <@aj> ah, i see there's a magazine article where samson mow talks about having "hundreds" of functionaries
 03:41 ##taproot-bip-review: < instagibbs> there's a scheme for quasi-accountability, but I'd have to defer to andytoshi for that
 03:41 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 03:42 ##taproot-bip-review: <@aj> i guess if you have that many, one approach might be to group them into sets of 5 and allow unaccountable 4/5 musig between them, and do checksigadd to require 18/20 groups to sign or similar for between 72 and 92 of 100 multisig
 03:43 ##taproot-bip-review: <@aj> there's a scheme where the honest participants in the multisig can track who the other co-signers were, so long as you have some honest participants
 03:44 ##taproot-bip-review: < instagibbs> anyways, that's Future Work with threshold
 03:46 ##taproot-bip-review: <@aj> okay, about time for me to put the laptop away, so i guess we'll call it
 03:46 ##taproot-bip-review: <@aj> #endmeeting
 03:46 ##taproot-bip-review: < lightningbot> Meeting ended Thu Nov 14 02:46:29 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 03:46 ##taproot-bip-review: < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-14-02.00.html
 03:46 ##taproot-bip-review: < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-14-02.00.txt
 03:46 ##taproot-bip-review: < lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-14-02.00.log.html
 03:47 ##taproot-bip-review: <@aj> might send out a poll to see if there's some other time people would prefer for a second q&a
 03:55 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 09:55 -!- b10c [[email protected]] has joined ##taproot-bip-review
 10:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review
 11:51 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 12:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:19 ##taproot-bip-review: < elichai2> instagibbs: well in practice you won't use the python impl but libsecp so it should be ~10X faster I think
 13:37 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 13:49 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 14:51 -!- pinheadmz [[email protected]] has joined ##taproot-bip-review
 15:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 15:18 -!- davterra [[email protected]] has joined ##taproot-bip-review
 15:22 -!- pyskl [[email protected]] has joined ##taproot-bip-review
 15:23 -!- pyskl [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review
 15:27 ##taproot-bip-review: < pyskl> #bitcoin-taproot-sg3
 15:27 ##taproot-bip-review: < pyskl> #bitcoin-taproot-sg3
 15:27 ##taproot-bip-review: < pyskl> omg there's a return code in the text i copied, ignore me
 15:47 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 15:48 -!- davterra [[email protected]] has joined ##taproot-bip-review
 16:23 -!- davterra [[email protected]] has joined ##taproot-bip-review
 16:56 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 17:25 -!- pyskl [[email protected]] has joined ##taproot-bip-review
 17:25 -!- pyskl [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review
 19:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 20:32 -!- pinheadmz [[email protected]] has joined ##taproot-bip-review
 22:15 -!- davterra [[email protected]] has joined ##taproot-bip-review
 22:18 -!- pinheadmz [[email protected]] has joined ##taproot-bip-review
 23:22 -!- pinheadmz [[email protected]] has joined ##taproot-bip-review
 23:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 23:53 -!- davterra [[email protected]] has joined ##taproot-bip-review
 01:02 -!- theStack [[email protected]] has joined ##taproot-bip-review
 01:04 ##taproot-bip-review: < theStack> anyone here from review group 1? :)
 01:17 -!- andytoshi [[email protected]] has joined ##taproot-bip-review
 01:17 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review
 02:11 -!- Lexyon__ [sid402723@gateway/web/irccloud.com/x-gafxjabizbwcfxzx] has joined ##taproot-bip-review
 02:12 -!- amiti [sid373138@gateway/web/irccloud.com/x-azyydwequtolbpdd] has joined ##taproot-bip-review
 02:13 -!- takinbo [sid19838@gateway/web/irccloud.com/x-mbhxzojvhqxkcjvq] has joined ##taproot-bip-review
 02:13 -!- moneyball [sid299869@gateway/web/irccloud.com/x-sbeyployifnfgrvv] has joined ##taproot-bip-review
 02:13 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-yhvlkczjlzasdzfr] has joined ##taproot-bip-review
 02:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 04:25 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 05:38 -!- davterra [[email protected]] has joined ##taproot-bip-review
 06:07 -!- meshcollider [[email protected]] has joined ##taproot-bip-review
 07:32 -!- ariard_ [[email protected]] has joined ##taproot-bip-review
 07:34 -!- instagibbs_ [[email protected]] has joined ##taproot-bip-review
 07:48 -!- CubicEarth [[email protected]] has joined ##taproot-bip-review
 07:48 -!- willcl_ark [[email protected]] has joined ##taproot-bip-review
 07:48 -!- raj_149 [[email protected]] has joined ##taproot-bip-review
 07:48 -!- tecnovert [[email protected]] has joined ##taproot-bip-review
 08:27 -!- yaslama [[email protected]] has left ##taproot-bip-review []
 08:39 -!- CubicEarth [[email protected]] has joined ##taproot-bip-review
 09:01 -!- davterra [[email protected]] has joined ##taproot-bip-review
 09:13 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has joined ##taproot-bip-review
 09:28 -!- b10c [[email protected]] has joined ##taproot-bip-review
 10:05 -!- b10c1 [~Thunderbi@2001:16b8:2ea3:4100:cc19:12c4:e532:216f] has joined ##taproot-bip-review
 11:16 -!- yaslama [[email protected]] has joined ##taproot-bip-review
 12:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 12:58 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 13:07 -!- tecnovert [[email protected]] has joined ##taproot-bip-review
 13:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:51 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 14:42 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 15:59 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-jxjnizqxjvmgltht] has joined ##taproot-bip-review
 16:41 -!- jnewbery [[email protected]] has joined ##taproot-bip-review
 17:43 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 18:16 ##taproot-bip-review: < waxwing> In "using a k of k script for every combination" (*script BIP, rationale 6), i note that each k of k is implemented with CHECKSIG, CHECKSIGVERIFY and not CHECKSIGADD; i can see that you don't need the counting mechanism that CHECKSIGADD has (because these are always k of k) but, is it just a choice? could you use *ADD anyway? is it just a bit less economical?
 18:18 ##taproot-bip-review: < sipa> waxwing: yeah you'd need to push a 0 at the beginning
 18:19 ##taproot-bip-review: < waxwing> also i didn't get why e.g. 2 of n is only more economical that way if n>= 6; say if n=5, then there are 5 choose 2, or 10 branches of 2 of 2 each, but wouldn't each of those 2 of 2 branches be better than a big script with 5 keys? hmm not sure how to count this.
 18:19 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 18:20 ##taproot-bip-review: < waxwing> oh .. well you would need 5 keys in the script the other way.
 18:20 ##taproot-bip-review: < sipa> waxwing: i did the math :)
 18:21 ##taproot-bip-review: < waxwing> :)
 18:24 ##taproot-bip-review: < waxwing> i guess it's interesting for people to observe that k of n policies are feasible now with huge n, as long as k is small. not sure it'll be obvious to people that that design window has opened up.
 18:24 ##taproot-bip-review: < waxwing> well i mean as if anything here is obvious ...
 18:25 ##taproot-bip-review: < sipa> personally i think most interesting theshold policies are k-of-n with k>n/2
 19:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 19:23 ##taproot-bip-review: < instagibbs_> if k is almost n it's also possible
 19:23 ##taproot-bip-review: < instagibbs_> :)
 19:30 ##taproot-bip-review: < instagibbs_> point made in the review slack: "Let ej = c[33+32j:65+32j]" can be confusing if you don't know python slicing
 19:31 ##taproot-bip-review: < instagibbs_> could seem 33 bytes rather than 32
 19:31 ##taproot-bip-review: < sipa> it's not python slicing!
 19:31 ##taproot-bip-review: < sipa> the [:] is actually defined in bip-schnorr ;)
 19:32 ##taproot-bip-review: < instagibbs_> hah!
 19:32 ##taproot-bip-review: < sipa> it just coincidentally matches python notation
 19:33 ##taproot-bip-review: < instagibbs_> ok worth a link :) thanks
 19:35 -!- Guest61 [[email protected]] has joined ##taproot-bip-review
 20:11 ##taproot-bip-review: < waxwing> instagibbs_, yeah the combinatorial symmetry, but: with 99 out of 100 you need 99 sigs, not 1, even though the combs are the same.
 20:12 ##taproot-bip-review: < waxwing> oh but: musig?
 20:31 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 20:56 ##taproot-bip-review: <@aj> waxwing: yeah, just 100 leafs each with one 99-of-99 musig
 20:56 -!- davterra [[email protected]] has joined ##taproot-bip-review
 21:28 -!- Guest61 [~textual@2a02:1205:500f:2e90:41e7:337a:6b3f:bd41] has joined ##taproot-bip-review
 21:53 ##taproot-bip-review: < waxwing> gotcha so by symmetry we're ok at the high end, but only to the extent people are willing and able to do large musigs.
 21:54 ##taproot-bip-review: < waxwing> well i mean ignoring any 'native' threshold secret sharing shenanigans
 23:51 -!- tecnovert [[email protected]] has joined ##taproot-bip-review
 23:55 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review
 00:52 -!- Guest61 [~textual@2a02:1205:500f:2e90:41e7:337a:6b3f:bd41] has joined ##taproot-bip-review
 10:52 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 10:53 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 11:59 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review
 14:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 15:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 16:08 -!- 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 joined ##taproot-bip-review
 19:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 20:01 -!- yaslama [[email protected]] has joined ##taproot-bip-review
 20:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 21:15 -!- yaslama_ [[email protected]] has joined ##taproot-bip-review
 22:46 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 23:10 ##taproot-bip-review:  * pinheadmz https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#script-validation-rules
 23:10 ##taproot-bip-review: < pinheadmz> "If there are at least two witness elements left, script path spending is used:"
 23:11 ##taproot-bip-review: < pinheadmz> what if the first byte of the last witness item after annex is removed is NOT 0xc0 ?
 23:12 ##taproot-bip-review: < pinheadmz> I ask because in https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#specification the leaf version 0xc0 or 0xc1 is specified - so Im confused between the two BIPS
 23:13 ##taproot-bip-review: < pinheadmz> I guess my question is: does spend_type have bit 1 set if there are >=2 items on stack after annex is removed BUT ALSO, the last item does NOT start with 0xc0 or 0xc1 ?
 23:15 ##taproot-bip-review: < sipa> if the last item does not start with 0xc0/0xc1 it's a unknown leaf version
 23:16 ##taproot-bip-review: < sipa> and no further rules apply
 23:16 ##taproot-bip-review: < pinheadmz> ok makes sense i think i was confused by this test: "alwaysvalid/unknownversion#fe"
 23:16 ##taproot-bip-review: < pinheadmz> lemme see if i understan the comment "Annex is mandatory for control block with leaf version 0x50"
 23:17 ##taproot-bip-review: < pinheadmz> so leaf version 0x50 is a long way away from being deployed -- but if it ever IS, because that is the magic number for an annex, you ALSO must have an annex - so it is removed
 23:17 ##taproot-bip-review: < sipa> exactly
 23:19 ##taproot-bip-review: < pinheadmz> and if I see an unkown leaf version, I just mark the input as valid, dont even bother computing tx digest, etc
 23:19 ##taproot-bip-review: < sipa> yes, you don't even get the point of executing a script
 23:19 ##taproot-bip-review: < sipa> much less get to the point of encountering a signature to check
 23:19 ##taproot-bip-review: < pinheadmz> right ok
 23:20 ##taproot-bip-review: < pinheadmz> ok, lastly this line: "The leaf version is 0xc0 (i.e. the first byte of the last witness element after removing the optional annex is 0xc0 or 0xc1)" -- what is 0xc1 here?
 23:21 ##taproot-bip-review: < sipa> the leaf version is c[0] & 0xfe
 23:21 ##taproot-bip-review: < pinheadmz> ah ok i see, "The low bit is used to denote whether the has_square_y(Q) holds."
 23:21 ##taproot-bip-review: < pinheadmz> thanks! phew, complicated.
 23:21 ##taproot-bip-review: < sipa> right
 23:22 ##taproot-bip-review: < sipa> it's kind of the other way around: leaf versions only exist because there were a few unused bits in c[0]
 23:22 ##taproot-bip-review: < sipa> but it's necessitated by needing to convey has_square_y(Q)
 23:22 ##taproot-bip-review: < pinheadmz> heh, I see - you only needed one bit, but now you got 7 more you mine as well use :-)
 23:23 ##taproot-bip-review: < pinheadmz> and crypto wise - is this jsut an optimization? presumably if its 1 or 0 a verifier could just try both?
 23:26 ##taproot-bip-review: < sipa> that would break batch verifiability, which is a design goal
 23:27 ##taproot-bip-review: < pinheadmz> cool
 23:59 -!- b10c [[email protected]] has joined ##taproot-bip-review
 00:25 ##taproot-bip-review: < pinheadmz> the test feature_taproot.py has several scripts with OP_CHECKSIGADD -- but none of them are actually multisig-ing? I guess that keeps the tests simple, one sig per test?
 00:26 ##taproot-bip-review: < pinheadmz> but in practice, like with CMS, each sig could have a different sighash type and require a different sighash & TX digest
 00:28 ##taproot-bip-review: < sipa> more tests welcome
 00:32 ##taproot-bip-review: < pinheadmz> yeah ofc :-) Just making sure IM reading correctly
 06:42 -!- Aleru [sid403553@gateway/web/irccloud.com/x-uaunxkgpufrmzkyi] has joined ##taproot-bip-review
 09:50 -!- b10c [[email protected]] has joined ##taproot-bip-review
 10:04 -!- Guest61 [[email protected]] has joined ##taproot-bip-review
 11:42 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 14:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 18:18 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 19:31 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 20:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 21:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 21:33 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 00:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 01:25 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 02:14 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 02:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 02:36 -!- ZmnSCPxj_ [[email protected]] has joined ##taproot-bip-review
 09:21 -!- daniel__ [[email protected]] has joined ##taproot-bip-review
 10:01 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 10:49 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review
 11:15 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 11:33 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review
 12:15 -!- orfeas [[email protected]] has joined ##taproot-bip-review
 12:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:47 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review
 13:58 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 13:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 14:33 -!- Guest61 [[email protected]] has joined ##taproot-bip-review
 15:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 18:19 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 19:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 19:25 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 19:45 -!- jeremyrubin [[email protected]] has joined ##taproot-bip-review
 19:53 ##taproot-bip-review: < instagibbs_> "The function bytes(P), where P is a point, returns bytes(x(P))'." is the end ' a typo or meaningful?
 19:55 ##taproot-bip-review: < nickler> instagibbs_: a typo, orfeas opened a PR fixing this a few hours ago
 19:56 ##taproot-bip-review: < instagibbs_> ah
 21:31 ##taproot-bip-review: < pinheadmz> In case anyone is interested, I modified the sipa/taproot branch to export Taproot test vectors, for use in testing alternative implementations or wallet implementations: https://github.com/pinheadmz/bitcoin/blob/taproottest1/README.md
 21:31 ##taproot-bip-review: < pinheadmz> Basically modified the feature_taproot.py test to create a JSON file of all the UTXOs and transactions
 21:31 ##taproot-bip-review: < pinheadmz> Using this, I was able to begin implementing taproot in bcoin (so far, just up to the TX digest algo - what a beast!)
 21:55 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 22:18 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 00:39 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review
 00:40 -!- evoskuil [[email protected]] has joined ##taproot-bip-review
 00:48 -!- ZmnSCPxj_ [[email protected]] has joined ##taproot-bip-review
 00:58 ##taproot-bip-review: < evoskuil[m]> Thanks for this 👆.
 01:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 01:20 ##taproot-bip-review: < sipa> pinheadmz: nice, that'll be very useful to generate actual test vectors to include in the bip
 02:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 02:57 ##taproot-bip-review: < evoskuil> The Abstract of bip-143 states: "This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program" and the Specification goes on to remove FindAndDelete (for v0 scripts). bip-taproot is v1 and silent on FindAndDelete. I assume the expectation is that FindAndDelete should never rear its ugly head in a versioned script, but if so this should be made explicit, including whether
 03:02 ##taproot-bip-review: <@aj> evoskuil: cut off after "including whether"
 03:02 ##taproot-bip-review: < evoskuil> ...  this can be applied retroactively to reserved versions.
 03:03 ##taproot-bip-review: < evoskuil> @aj: thanks, not sure what happened, it echoed fine.
 03:05 ##taproot-bip-review: < sipa> bip-taproot specifies a new signature hashing scheme, the one from BIP143 isn't used anymore in taproot spends
 03:05 ##taproot-bip-review: < sipa> perhaps that can be made explicit
 03:11 ##taproot-bip-review: < sipa> evoskuil: ah, perhaps this clarifies things better: the bip-taproot/tapscript sighash scheme doesn't include a "scriptCode" anymore (where the FindAndDelete used to be applied to)
 03:12 ##taproot-bip-review: < evoskuil> Actually I think it's probably sufficient as is. It would be nice to explicitly exclude it from all versioned scripts in the older code, but not necessary.
 03:12 ##taproot-bip-review: < sipa> instead there is the actual scriptPubKey, and for tapscript, the hash of the leaf that is chosen leaf
 03:12 ##taproot-bip-review: < sipa> -leaf
 03:14 ##taproot-bip-review: < evoskuil> Yeah, this is just a consequence of working through the spec in stages. It would have become obvious later.
 03:14 ##taproot-bip-review: < sipa> Ah, you mean a clarification in BIP143 like "Note that this scheme is not used in v1 witnesses", if bip-taproot ends up being adopted?
 03:18 ##taproot-bip-review: < evoskuil> No, I don't think any further clarification is required. It's just that when working through the places where version is used I hit the FindAndDelete condition, and instead of explicitly checking for v0 I wanted to check for "versioned", but this code won't execute for taproot.
 03:18 ##taproot-bip-review: < sipa> Right.
 04:53 -!- ZmnSCPxj [[email protected]] has joined ##taproot-bip-review
 04:55 ##taproot-bip-review: < ZmnSCPxj> elichai2, instagibbs: regarding MuSig-in-MuSig, this is used in my Nodelets proposal: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002236.html
 04:55 ##taproot-bip-review: < ZmnSCPxj> Obviously, Schnorr-based channels will use MuSig between the channel participants
 04:55 ##taproot-bip-review: < ZmnSCPxj> Nodelets considers the possibility that one of the nodes in the Lightning network is actually composed of multiple participants that have to be online 100% of the time
 04:56 ##taproot-bip-review: < ZmnSCPxj> It seems MuSig-in-MuSig resolves down to a 2-phase MuSig, which has a security proof that was shown as flawed
 04:57 ##taproot-bip-review: < ZmnSCPxj> I am in communication with MuSig authors and Tim Ruffing regarding composable MuSig.
 04:58 ##taproot-bip-review: < ZmnSCPxj> It seems to me that there should not be any issue if a participant in any MuSig-using protocol is itself an aggregate.
 04:58 ##taproot-bip-review: < ZmnSCPxj> One may observe that typical sentiences are primarily composed of multiple nonsentient agents, for example.
 04:58 ##taproot-bip-review: < ZmnSCPxj> (unless access to your design is not available to humans?)
 05:00 ##taproot-bip-review: < ZmnSCPxj> Regarding composable MuSig, it seems possible to use ElGamal commitments in the first phase of 3-phase MuSig.
 05:01 ##taproot-bip-review: < ZmnSCPxj> But part of ElGamal commitment is showing a point q * G in the commitment, which leads me to wonder why it would not be subject to the same flaw as 2-phase MuSig
 05:03 ##taproot-bip-review: < ZmnSCPxj> In any case, I am now checking through the logs kept by aj on erisian.com.au, so please respond at your leisure
 06:07 -!- hebasto [[email protected]] has joined ##taproot-bip-review
 08:14 -!- tecnovert [[email protected]] has joined ##taproot-bip-review
 08:52 -!- daniel__ [[email protected]] has joined ##taproot-bip-review
 11:02 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 11:13 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 11:52 ##taproot-bip-review: < waxwing> i finished this over the weekend, about what wagner's algorithm/attack is, it occurs to me that the few people that may be interested are likely to be here :) https://joinmarket.me/blog/blog/avoiding-wagnerian-tragedies/
 11:56 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review
 12:15 -!- ZmnSCPxj_ [[email protected]] has joined ##taproot-bip-review
 12:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 12:28 ##taproot-bip-review: < jonatack> waxwing: ty :)
 12:39 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review
 14:01 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 15:15 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review
 15:19 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 16:59 -!- davterra [[email protected]] has joined ##taproot-bip-review
 17:22 -!- Guest61_ [[email protected]] has joined ##taproot-bip-review
 17:33 -!- Guest61 [[email protected]] has joined ##taproot-bip-review
 17:59 ##taproot-bip-review: < waxwing> " A product of two numbers is a square when either both or none of the factors are squares." i must be dumb i don't get it .. a product of two not square factors isn't always a square (i.e the "none" case), like 3x7 is not a square even though both factors are not squares.
 18:10 ##taproot-bip-review: < waxwing> i think it's a statement correct modulo p, isn't that it?
 18:11 ##taproot-bip-review: < waxwing> oh and distinguishes when p=3 mod 4 vs 1 mod 4 according to wiki, because of the difference of whether -1 is a square or not.
 18:14 ##taproot-bip-review: < sipa> waxwing: yeah, modulo a prime this is correct
 18:14 ##taproot-bip-review: < sipa> (it's even true when -1 is a square)
 18:16 ##taproot-bip-review: < waxwing> right that specific sentence, true
 18:20 ##taproot-bip-review: < sipa> put otherwise: this follows from the legendre symbol being a completely multiplicative function
 18:20 ##taproot-bip-review: < sipa> maybe we should add "modulo a prime" to that sentence?
 18:21 ##taproot-bip-review: < sipa> i think this became confused when we changed the "quadratic residue" terminology for "square"
 18:21 ##taproot-bip-review: < waxwing> i think so yes.
 18:22 ##taproot-bip-review: < waxwing> yes quadratic residue is particularly unfortunate, but hard to argue with Gauss :)
 18:22 ##taproot-bip-review: < sipa> it's all Square's fault
 18:23 ##taproot-bip-review: < waxwing> lol. reminds me i always say Gaussian not normal because let's face it the former is just cool sounding.
 18:24 ##taproot-bip-review: < sipa> "standard normal" is even worse
 18:24 ##taproot-bip-review: < sipa> how boring a name can you come up with
 18:25 ##taproot-bip-review: < waxwing> i note you correctly say this is a new standard but it might be worth adding a footnote about how it's also widely used in slightly different forms, like what is it EDDSA is basically a Schnorr variant.
 18:26 ##taproot-bip-review: < waxwing> probably there are others but meh it's only a suggestion no need to go overboard. i just have occasionally encountered people thinking this is a new untried piece of cryptography, which is pretty far from accurate really.
 18:26 ##taproot-bip-review: < sipa> yup, worth citing
 18:26 ##taproot-bip-review: < sipa> even the hash(R || P || m) argument order matches eddsa
 18:27 ##taproot-bip-review: < waxwing> oh, right, presumably we will now bikeshed that for the next hour or two :)
 18:27 ##taproot-bip-review: < sipa> i prebikeshedded it with real_or_random already
 18:28 ##taproot-bip-review: < waxwing> yeah i saw that. kinda interesting discussion, maybe i'll link it here
 18:29 ##taproot-bip-review: < waxwing> cancel that i have no idea where i read it, now.
 18:39 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review
 19:15 ##taproot-bip-review: <@aj> waxwing: https://github.com/sipa/bips/pull/62 ?
 19:18 ##taproot-bip-review: < sipa> that's it
 19:50 ##taproot-bip-review: < moneyball> 10 minutes until Q&A!
 19:50 ##taproot-bip-review: < sipa> i'll be 5-10 minutes late
 19:58 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 20:00 ##taproot-bip-review: <@aj> #startmeeting
 20:00 ##taproot-bip-review: < lightningbot> Meeting started Tue Nov 19 19:00:22 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
 20:00 ##taproot-bip-review: < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 20:00 ##taproot-bip-review: < kabaum> Hi
 20:00 ##taproot-bip-review: < amiti> hi
 20:00 ##taproot-bip-review: < moneyball> hi
 20:00 ##taproot-bip-review: < nickler> hi
 20:00 ##taproot-bip-review: < nothingmuch> hi
 20:00 ##taproot-bip-review: <@aj> hi
 20:01 ##taproot-bip-review: < kabaum> It's only me from group 5 here today, so my questions are not filtered through our pre-Q&A-meeting.
 20:01 ##taproot-bip-review: < fanquake> hi
 20:02 ##taproot-bip-review: < kabaum> Q 1/3: Why isn't implicit Y a reduction in security? I don't get the explanation given in last paragraph of "Implicit Y coordinates" or in footnote 6. Is it so that given a privkey q for a pubkey P with explicit Y, one can easily calculate the privkey p' for the pubkey -P?
 20:03 ##taproot-bip-review: < sipa> kanzure: https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7
 20:03 ##taproot-bip-review: < sipa> eh, kabaum ^
 20:03 ##taproot-bip-review: < fjahr> hi
 20:04 ##taproot-bip-review: < sipa> kabaum: also https://bitcoin.stackexchange.com/a/90120/208
 20:04 ##taproot-bip-review: < nickler> kabaum: but basically yes. Inverting the public key is just computing the negation of a 256 bit number (the y coordinate) so that's very easy.
 20:04 ##taproot-bip-review: < kanzure> hi
 20:05 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 20:05 ##taproot-bip-review: < sipa> nickler: you keep bringing that up as argument, but i don't think that's relevant
 20:05 ##taproot-bip-review: < sipa> even if it cost an EC multiplication to do so, x-only would still not be a reduction in security
 20:07 ##taproot-bip-review: < nickler> still I want to point out that a third party can easily do that, no access to the secret key is required
 20:07 ##taproot-bip-review: < sipa> right
 20:08 ##taproot-bip-review: < kabaum> sipa: Got it. The stackexchange answer helped.
 20:08 ##taproot-bip-review: < nothingmuch> Q: both e and R style signatures seem to be rationalizable appealing to orphan rates, network latency for the former, validation cpu cost for the latter, but it's not clear how to compare these. what is the argument for favoring R and batch verification, especially on a longer time horizon? is it empirical?
 20:09 ##taproot-bip-review: < sipa> kabaum: another way to look at it: the fact that you can negate a public key (which negates the corresponding private key) is indeed going to help an attacker... but it *always* does that, whether public keys are x-only or full x/y
 20:09 ##taproot-bip-review: < kabaum> sipa: thanks.
 20:10 ##taproot-bip-review: < sipa> kabaum: FWIW, secp256k1 has another "efficiently computable endomorphism" (which is what this negation gives you), namely multiplication with a specific constant lambda... which also always helps an attacker
 20:10 ##taproot-bip-review: < nickler> nothingmuch: the argument is that batch verification is a significant speedup. It's empirical in the sense that we've implemented and measured it (that's the graph in the bip)
 20:12 ##taproot-bip-review: < sipa> kabaum: the expected number of EC additions an attacker needs to do with a DLP breaking algorithm is proportional to sqrt(p/m) where p is the largest prime factor of the group order, and m is the number of efficiently computable endomorphism (m=6 for secp256k1, but the efficient negation is part of it)
 20:14 ##taproot-bip-review: < sipa> nothingmuch: the "be made as small as 16 bytes" should probably get a qualifier "in some security models"
 20:17 ##taproot-bip-review: < kabaum> nickler: My next Q is related to nickler's answer.
 20:17 ##taproot-bip-review: < kabaum> Q 2/3: Is the graph "Batch signature verification in libsecp256k1" made using the bip-schnorr scheme or using some other/generic Schnorr scheme?
 20:19 ##taproot-bip-review: < nickler> kabaum: it's the bip-schnorr implementation in libsecp
 20:19 -!- willcl_ark [[email protected]] has joined ##taproot-bip-review
 20:19 ##taproot-bip-review: < nickler> this one https://github.com/bitcoin-core/secp256k1/pull/558
 20:20 ##taproot-bip-review: <@aj> nickler: well, it's from a pre-x-only version of that PR, right?
 20:20 ##taproot-bip-review: < sipa> here is a graph that's based on more lowlevel benchmarking: http://bitcoin.sipa.be/speedup-batch.png
 20:20 ##taproot-bip-review: < sipa> which only takes the multi-exp into account and not the other overhead of verifying a signature
 20:20 ##taproot-bip-review: < nickler> aj: right, but it shouldn't make a visible difference
 20:21 ##taproot-bip-review: < nickler> but I should try to reproduce the numbers just to be sure :)
 20:22 ##taproot-bip-review: < nickler> perhaps s/I/someone to reduce systematic bias
 20:22 ##taproot-bip-review: < kabaum> nickler: that'd be interesting.
 20:22 ##taproot-bip-review: < kabaum> Q 3/3: Why is batch verification of u signatures more efficient than verifying them separately? I counted the number of point multiplications and additions. For individual verification I get 2u mult and u add. For batch I get 2u mult and 2u-1 add. Also the amount of hashing seems similar in batch and separate verification. What am I missing?
 20:22 ##taproot-bip-review: < sipa> kabaum: Strauss' algorithm
 20:23 ##taproot-bip-review: < sipa> (and for larger numbers, Pippenger's algorithm)
 20:23 ##taproot-bip-review: < sipa> it turns out that x*A + y*B can actually be computed more efficiently in one go than computing (x*A) and (y*B) separately and adding them up
 20:24 -!- Moller40_ [[email protected]] has joined ##taproot-bip-review
 20:25 ##taproot-bip-review: < sipa> kabaum: very broadly, the number of EC additions you need to do to implement n EC multiplications grows with n/log(n), rather than n
 20:25 ##taproot-bip-review: < sipa> (if you only care about their sum)
 20:27 ##taproot-bip-review: < nickler> kabaum: https://cdn.preterhuman.net/texts/cryptography/Hankerson,%20Menezes,%20Vanstone.%20Guide%20to%20elliptic%20curve%20cryptography%20(Springer,%202004)(ISBN%20038795273X)(332s)_CsCr_.pdf section 3.3.3
 20:27 ##taproot-bip-review: < sipa> i can try to give an intuition for that here too, if there are no other questions
 20:27 ##taproot-bip-review: < nickler> "Guide to Elliptic Curve Cryptography" by Hankersen, Menezes, Vanstone
 20:28 ##taproot-bip-review: < kabaum> sipe: I'd love that.
 20:29 ##taproot-bip-review: < kabaum> nickler: Strauss isn't mentioned in that document.
 20:29 ##taproot-bip-review: < nothingmuch> i jumped the gun with my question, but it's still outstanding, but an intuition for batch verification seems relevant to it anyway
 20:29 ##taproot-bip-review: < sipa> imagine you're trying to compute 19*P
 20:30 ##taproot-bip-review: < nickler> kabaum: section 3.3.3
 20:30 ##taproot-bip-review: < sipa> one way to do that is to compute 2P = P+P, 4P = 2P+2P, 8P = 4P+4P, 16=8P+8P, and then sum P+2P+16P
 20:30 ##taproot-bip-review: < nickler> they don't call it strauss but shamir's trick
 20:30 ##taproot-bip-review: < sipa> right?
 20:31 ##taproot-bip-review: < kabaum> yes!
 20:31 ##taproot-bip-review: < waxwing> key prefixing means we lose the pubkey recovery property, right?
 20:32 ##taproot-bip-review: < sipa> waxwing: correct
 20:32 ##taproot-bip-review: < waxwing> how do we feel about that.
 20:32 ##taproot-bip-review: < sipa> i think key aggregation is more important that pubkey recovery
 20:32 ##taproot-bip-review: < waxwing> oh i see it's in footnote 3
 20:33 ##taproot-bip-review: < sipa> kabaum: so you're doing 4 doublings (because the largest power of two is 16P), and then 1 addition for every 1-bit in the binary representation of 16
 20:34 ##taproot-bip-review: < sipa> but say you want to compute 19P + 23Q, you're just going to do twice the amount of work now (two times 4 doublings, and an addition for every 1 bit in 19 and 23)
 20:34 ##taproot-bip-review: < sipa> agree?
 20:34 ##taproot-bip-review: < kabaum> Agree!
 20:35 ##taproot-bip-review: < sipa> so that's not a good approach
 20:35 ##taproot-bip-review: <@aj> waxwing: you can do pubkey recovery with partial sigs with the same construction though; claim the complete key is P+-P+G, so you're going for sG=R+H(R,G,m)*G and calculate a partial signature s1,R1   s1*G = R + H(R,G,m)*P  and P is recoverable
 20:36 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 20:36 ##taproot-bip-review: < sipa> kabaum: an alternative is working backwards: write 19 as 11001 in binary, and compute it as dbl(dbl(dbl(dbl(P)))+P)+P)
 20:36 ##taproot-bip-review: < sipa> this is the exact same number of additions/doublings
 20:37 ##taproot-bip-review: < sipa> but instead of precomputing all power-of-two's times P first, and then adding them up, you use an "accumulator" that you add P into every time a "1" bit is encountered, and you double for every bit
 20:37 ##taproot-bip-review: < waxwing> aj, hmm interesting, that's confusing, so you're talking about like a multisig scenario? but would that work with musig?
 20:37 ##taproot-bip-review: < sipa> this is actually the same algorithm as https://en.wikipedia.org/wiki/Exponentiation_by_squaring, expect addition/doubling instead of multiply/square
 20:38 ##taproot-bip-review: < kabaum> sipa: did you write 19 backwards in binary?
 20:38 ##taproot-bip-review: < sipa> kabaum, nothingmuch: does this make sense?
 20:38 ##taproot-bip-review: < sipa> no
 20:38 ##taproot-bip-review: <@aj> waxwing: just abusing the api needed for partial sigs to allow for a protocol that wants pubkey recovery
 20:38 ##taproot-bip-review: < sipa> kabaum: maybe it's easier to see if i write it as dbl(dbl(dbl(dbl(0+P)))+P)+P)
 20:38 ##taproot-bip-review: < waxwing> aj, i guess it depends on what situation you want to do pubkey recovery .. the one i was made aware of was people working in a constrained environment wanting to transfer without being explicit about a key.
 20:38 ##taproot-bip-review: < waxwing> constrained as in something like mesh network.
 20:39 ##taproot-bip-review: < sipa> kabaum: oh, i'm confusing myself!
 20:40 ##taproot-bip-review: < sipa> it's dbl(dbl(dbl(dbl(0+P)+P)))+P
 20:40 ##taproot-bip-review: < sipa> the outer bits (11) become the inner part
 20:40 ##taproot-bip-review: < sipa> maybe IRC isn't the best medium for this
 20:40 ##taproot-bip-review: < nothingmuch> sipa: roughly makes sense to me but i doubt i will fully comprehend this here, i'm slow on the uptake and probably need to work it out on paper
 20:40 ##taproot-bip-review: < sipa> nothingmuch: i'm just giving background, i haven't explained it yet :)
 20:41 ##taproot-bip-review: < waxwing> there is a trailing ) on the last bullet point of "Default Signing"
 20:41 ##taproot-bip-review: < kabaum> Oh, it's 0x19, got that. Now I'm way behind you.... Catching up.
 20:41 ##taproot-bip-review: < sipa> kabaum: no, 19 = 16 + 8 + 1
 20:41 ##taproot-bip-review: < sipa> eh, 16 + 2 + 1
 20:41 ##taproot-bip-review: < sipa> i need a whiteboard :)
 20:42 ##taproot-bip-review: < waxwing> cancel that there is not a trailing )  . doh.
 20:44 ##taproot-bip-review: < sipa> kabaum: the number in binary is 10011 * P
 20:44 ##taproot-bip-review: < sipa> start with 0P = 0
 20:44 ##taproot-bip-review: < sipa> you see a 1 bit (the one in front), so you add P, and get 1P
 20:44 ##taproot-bip-review: < sipa> you double, and get 2P
 20:44 ##taproot-bip-review: < nickler> aj: fwiw the libsecp-zkp musig api wouldn't let you do that. Also, not committing to the pubkey allowsa an attacker to tweak the signature to be valid for another bip32 derived key
 20:44 ##taproot-bip-review: < sipa> you see a 0 bit, so don't do anything
 20:44 ##taproot-bip-review: < sipa> you double, and get 4P
 20:44 ##taproot-bip-review: < sipa> you see a 0 bit, so don't do anything
 20:44 ##taproot-bip-review: < sipa> you double, and get 8P
 20:45 ##taproot-bip-review: < sipa> you see a 1 bit, so you add P, and get 9P
 20:45 ##taproot-bip-review: < sipa> you double, and get 18P
 20:45 ##taproot-bip-review: < sipa> you see a 1 bit, so you add P, and get 19P
 20:45 ##taproot-bip-review: < sipa> done.
 20:45 ##taproot-bip-review: < sipa> does this make sense?
 20:46 ##taproot-bip-review: < waxwing> nickler, yeah i haven't figured it out, as you have, but makes sense that that is not compatible with musig, as it's kind of a related key attack thing.
 20:46 ##taproot-bip-review: <@aj> nickler: that means the api only does musig, not simple pubkey addition (with knowledge of discrete log) right?
 20:47 ##taproot-bip-review: < waxwing> aj, so you're basically arguing for people to still use base bip schnorr but have their own protocols (not in bitcoin itself, per se) that could do that kind of stuff?
 20:47 ##taproot-bip-review: < nothingmuch> sipa: so then to do both, it's just adding Q or P based on whether their respective bits are set into the same accumulator, and doubling once?
 20:47 ##taproot-bip-review: < nickler> well in our musig api you have the concept of a session which keeps your nonce, others nonces and your secret key. If you call partial sig it will use mostly session information
 20:47 ##taproot-bip-review: < sipa> nothingmuch: exactly!
 20:47 ##taproot-bip-review: < sipa> and what did you gain?
 20:47 ##taproot-bip-review: <@aj> waxwing: that it's conceivable yeah, not necessarily a good idea :)
 20:47 ##taproot-bip-review: < waxwing> :)
 20:50 ##taproot-bip-review: < kabaum> sipa: Didn't you just describe normal "adding and doubling" method?
 20:50 ##taproot-bip-review: < sipa> kabaum: yes indeed
 20:50 ##taproot-bip-review: < kabaum> ok, then I follow.
 20:51 ##taproot-bip-review: < sipa> so the next step is what nothingmuch said: if you want to compute say 19P + 25Q, where 19 is 10011 in binary, and 25 is 11001, you can merge the two computations
 20:51 ##taproot-bip-review: < sipa> you start with 0P+0Q = 0
 20:51 ##taproot-bip-review: < sipa> you see a 1 bit in both, so you add P and Q, and 1P+1Q
 20:52 ##taproot-bip-review: < sipa> you double, and get 2P+2Q
 20:52 ##taproot-bip-review: < sipa> you see a 1 bit in 25, so you add Q, and get 2P+3Q
 20:52 ##taproot-bip-review: < sipa> you double, and get 4P+6Q
 20:52 ##taproot-bip-review: < sipa> you see 0 bits in both and do nothing
 20:53 ##taproot-bip-review: < sipa> you double, and get 8P+12Q
 20:53 ##taproot-bip-review: < sipa> you see 1 bit in 19, so you add P, and 9P+12Q
 20:53 ##taproot-bip-review: < sipa> you double, and get 18P+24Q
 20:53 ##taproot-bip-review: < sipa> you see a 1 bit in both, you add P+Q, and get 18P+25Q
 20:53 ##taproot-bip-review: < sipa> *19P+25Q
 20:54 ##taproot-bip-review: < sipa> and in doing so, you've only doubled 4 times, not 8 times
 20:56 ##taproot-bip-review: < waxwing> i see you specify deterministic nonces but a very much simpler form than rfc6979 .. perhaps mention the latter in footnote 10?
 20:57 ##taproot-bip-review: < waxwing> debatable since it's not like rfc6979 was actually part of a bitcoin standard/bip before iirc
 20:57 ##taproot-bip-review: < sipa> we all like 289264 invocation of the SHA256 compression functions to compute a nonce
 20:57 -!- Moller40_ [[email protected]] has joined ##taproot-bip-review
 20:58 ##taproot-bip-review: < waxwing> also that bias being small is cool but maybe it would be nice to cite something. i remember 1 bit biases in nonces have been enough in theory before (lattice stuff)
 20:58 ##taproot-bip-review: < sipa> waxwing: they are
 20:58 ##taproot-bip-review: < waxwing> 6979 was kinda hard. but i mean ... Pornin is the man.
 20:59 ##taproot-bip-review: < sipa> it's a 0.0000000000000000000000000000000000000058 bit bias here
 20:59 ##taproot-bip-review: < waxwing> ah right yeah, thought i might have made that error :)
 20:59 ##taproot-bip-review: < sipa> i think we have a comment somewhere that the bias is unobservable
 20:59 ##taproot-bip-review: < waxwing> wait was it really 300K? lol
 21:00 ##taproot-bip-review: < kabaum> sipa: I got it! Thanks! You really made it simple.
 21:00 ##taproot-bip-review: < sipa> waxwing: no, more like 15
 21:00 ##taproot-bip-review: < sipa> waxwing: still, it's actually a nontrivial portion of the signing time
 21:00 ##taproot-bip-review: < waxwing> yeah you have that comment in 10 it's fine. and no need to comment rfc6979 i think.
 21:00 ##taproot-bip-review: < waxwing> i see. makes sense. i know there are some loops you can end up in but they're vanishingly unlikely.
 21:03 ##taproot-bip-review: < nothingmuch> sipa: i'd like to reiterate my question about e vs. R based signatures, and the rationale for preferring batch verification over compact signatures, and add to it
 21:03 ##taproot-bip-review: < waxwing> i think you could argue you don't need either the batch verification nor the optimisation sections in the BIP.
 21:03 ##taproot-bip-review: < waxwing> albeit it helps a lot to understand design decisions.
 21:03 ##taproot-bip-review: < nothingmuch> namely, is it fair to say that batch verification is necessarily serial?
 21:04 ##taproot-bip-review: < sipa> nothingmuch: what does that mean?
 21:05 ##taproot-bip-review: < nothingmuch> sipa: can't be computed in parallel
 21:05 ##taproot-bip-review: < sipa> i don't know what that means
 21:05 ##taproot-bip-review: < waxwing> i also don't understand, surely the whole point of batching is to do stuff in parallel
 21:05 ##taproot-bip-review: < nothingmuch> i mean given a batch, that the algorithm to do the whole batch is not concurrent
 21:06 ##taproot-bip-review: < nothingmuch> and can't benefit from multiple cores
 21:06 ##taproot-bip-review: < sipa> nothingmuch: ah, in theory it could, but we don't have an implementation for that
 21:06 ##taproot-bip-review: < sipa> however, you can split up the batch in 4 batches, and verify each on one core easily
 21:06 ##taproot-bip-review: < waxwing> that loses some of the scaling, but then if you had a parallelisable algo, it might too, i guess
 21:07 ##taproot-bip-review: < nothingmuch> i'm trying to better understand the compute vs. network latency tradeoff, the benefit from batching is obvious to me, but i'm not sure how it holds up against bandwidth cost, especially since witness data is discounted
 21:07 ##taproot-bip-review: < nothingmuch> or is the difference in security model the main rationale for preferring R over e, with batching being an extra benefit?
 21:08 ##taproot-bip-review: < nothingmuch> (without witness discount i can see that batch verification should be strictly better for orphan rates, but slightly reduced tx throughput)
 21:09 ##taproot-bip-review: < waxwing> pretty sure it's batching, the 'e' version is usually what's proved in security proofs isn't it.
 21:09 ##taproot-bip-review: < waxwing> oh but shortened .. ok.
 21:11 ##taproot-bip-review: < sipa> so using a 128-bit e value works in some security models for Schnorr, but not all
 21:12 ##taproot-bip-review: < sipa> (depending on which other assumptions on the group/hash are made)
 21:12 ##taproot-bip-review: < sipa> nothingmuch: as for bandwidth, i think the relevant metrics are (a) worst case bandwidth usage and (b) worst case CPU per byte usage
 21:13 ##taproot-bip-review: < sipa> and worst case bandwidth isn't affected by any of these proposals - it's close to 4M of data per block
 21:13 ##taproot-bip-review: < sipa> while batch validation significantly improves CPU per vbyte
 21:14 ##taproot-bip-review: < nothingmuch> that makes sense
 21:14 ##taproot-bip-review: < sipa> specifically, i believe the ROM/DL/forkinglemma proof for Schnorr indeed works with 128-bit hashes... but the generic group + collision resistant hash proof needs 256 bit hashes
 21:16 ##taproot-bip-review: < nothingmuch> we had another question in group 16 yesterday, which i attempted to answer but wanted to verify - is the reason for H(tag)||H(tag) being the prefix so that the compression function can already be applied given that the block size is double the image size?
 21:17 ##taproot-bip-review: < sipa> yes, that's the reason for having a 64-byte prefix
 21:17 ##taproot-bip-review: < sipa> though any other 64-byte prefix could be picked
 21:18 ##taproot-bip-review: < sipa> the reason for doubling the hash of the tag is given in bip-taproot i think
 21:20 ##taproot-bip-review: <@aj> second paragraph of Specification in bip-taproot
 21:20 ##taproot-bip-review: <@aj> any other questions or shall we call it?
 21:20 ##taproot-bip-review: < kabaum> Thank you all so much for your time today! My two suggestions for bip-schnorr are: 1) Specify the specific schnorr scheme used in the graph. 2) Add a footnote mentioning Strauss' algorithm or Shamir's trick as the reason for the efficiency gains of batch verification.
 21:21 ##taproot-bip-review: < waxwing> i think all of that including batch algo itself is kinda out of scope. but i'm conflicted because it's actually pretty cool to have it there :)
 21:21 ##taproot-bip-review: < waxwing> aj, don't let me stop you :)
 21:21 ##taproot-bip-review: < sipa> kabaum: i guess i should point out that Shamir's trick is only one of the ways in which multi-EC-multiplication is faster than single-EC-multiplication
 21:22 ##taproot-bip-review: < kabaum> Oh, shit. There's more. Maybe a followup on next Q&A.
 21:23 ##taproot-bip-review: <@aj> #endmeeting
 21:23 ##taproot-bip-review: < lightningbot> Meeting ended Tue Nov 19 20:23:10 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 21:23 ##taproot-bip-review: < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-19-19.00.html
 21:23 ##taproot-bip-review: < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-19-19.00.txt
 21:23 ##taproot-bip-review: < lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-19-19.00.log.html
 21:23 ##taproot-bip-review: < sipa> there is a much cooler algorithm called Pippenger's, which actually gives O(n/log(n)) speed (all Strauss does is get rid of the doubling cost for the 2nd and later multiplications, but never reduces additions)
 21:23 ##taproot-bip-review: < sipa> kabaum: i can explain yet another algorithm called Bos-Coster which is very simple to explain, but isn't faster in practice so we don't use it
 21:23 ##taproot-bip-review: <@aj> can't ask for a better last line than "Oh shit. There's more." ...
 21:24 ##taproot-bip-review: < kabaum> aj: hehe
 21:24 ##taproot-bip-review: < nothingmuch> thank you!
 21:24 ##taproot-bip-review: < sipa> kabaum: interested?
 21:25 ##taproot-bip-review: < kabaum> sipa: If you have the time, please.
 21:25 ##taproot-bip-review: < kabaum> But I'm a bit overloaded.
 21:25 ##taproot-bip-review: < waxwing> i remember it's cool and not too hard to understand.
 21:25 ##taproot-bip-review: < sipa> so you want to compute n1*P1 + n2*P2 + n3*P3 + ..., and assume there are hundreds of terms
 21:25 ##taproot-bip-review: < waxwing> unfortunately i don't actually remember the algorithm, so please :)
 21:26 ##taproot-bip-review: < sipa> you sort them by descending value of n_i
 21:26 ##taproot-bip-review: < sipa> so n1 and n2 are the largest two n values
 21:27 ##taproot-bip-review: < sipa> now observe that n1*P1 + n2*P2 is actually the same as (n1-n2)*P1 + n2*(P1+P2)
 21:27 ##taproot-bip-review: < sipa> (it's subtracting n2*P1 from the first term, and adding it to the second term)
 21:27 ##taproot-bip-review: < sipa> right?
 21:28 ##taproot-bip-review:  * waxwing is listening
 21:28 ##taproot-bip-review: < kabaum> You add and subtract n2P1
 21:28 ##taproot-bip-review: < sipa> so you can rewrite your list of EC multiplications to perform
 21:29 ##taproot-bip-review: < sipa> by doing 1 EC addition (the P1+P2)
 21:29 ##taproot-bip-review: < sipa> however, n1 and n2 are you two largest numbers... if they're approximately uniformly distributed, n1-n2 is going to be say 100 times smaller than n1, if you have 100 terms
 21:30 ##taproot-bip-review: < sipa> so you replace the P2 in the n2*P2 term with (P1+P2), delete the n1*P1 term, and re-insert (n1-n2)*P1 into your list... but probably not at the front anymore (as n1-n2 will very likely be a lot smaller than n1)
 21:30 ##taproot-bip-review: < sipa> right?
 21:33 ##taproot-bip-review: < kabaum> I vaguely follow.... now that n2 is probably the biggest value you can rearrange the terms again.
 21:34 ##taproot-bip-review: < sipa> indeed
 21:34 ##taproot-bip-review: < sipa> but the important thing is that we've reduced the multiplication factor of one of the terms by a factor 100, with just one EC multiplication
 21:34 ##taproot-bip-review: < sipa> *one EC addition
 21:34 ##taproot-bip-review: < sipa> and we can keep doing this
 21:34 ##taproot-bip-review: < sipa> with the new top two terms
 21:35 ##taproot-bip-review: < sipa> remember that in a naive EC multiplication algorithms (double and add), we're really only getting rid of 1 bit in the scalars for each EC addition
 21:35 ##taproot-bip-review: < sipa> here we're getting rid of 7 or 8 bits with high likelihood
 21:36 ##taproot-bip-review: < sipa> and the more terms there are, the more bits we get rid of in one go
 21:37 ##taproot-bip-review: < sipa> of course, at some point this must end-- we only have a finite number of bits in those scalars
 21:37 ##taproot-bip-review: < kabaum> That's fantastic. Like magic. When do you stop rearranging procedure?
 21:37 ##taproot-bip-review: < sipa> how does it end? sometimes n1 will equal n2
 21:38 ##taproot-bip-review: < sipa> in which case you just rewrite n*P1 + n*P2 into a single term n*(P1+P2)
 21:38 ##taproot-bip-review: < waxwing> interesting that the worst case would be when the differences between the coefficients were the same as the coefficients themselves.
 21:38 ##taproot-bip-review: < waxwing> iiuc.
 21:39 ##taproot-bip-review: < sipa> so actually the end point of this algorithm is just a single term, always
 21:39 ##taproot-bip-review: < sipa> of the form n*P
 21:39 ##taproot-bip-review: < sipa> where n is the gcd of all input scalars, which with extremely high probability is just 1
 21:39 ##taproot-bip-review: < sipa> in which case you're done and can just return P
 21:41 ##taproot-bip-review: < kabaum> So no multiplicatin at all.
 21:42 ##taproot-bip-review: < sipa> well, multiplication is always just a bunch of additions
 21:42 ##taproot-bip-review: < sipa> the question is how :)
 21:43 ##taproot-bip-review: < kabaum> yes, sure :=)
 21:44 ##taproot-bip-review: < sipa> the reason this algorithm isn't used is because it interacts badly with another optimization we have
 21:44 ##taproot-bip-review: < kabaum> Roughly how many iterations would this take? O(number of terms)?
 21:44 ##taproot-bip-review: < sipa> O(n/log(n))
 21:44 ##taproot-bip-review: < sipa> or rather, O(n_terms*(1+bits_per_term/log(n_terms)))
 21:45 ##taproot-bip-review: < sipa> so it can't ever beat O(n_terms), but it can reduce the number of additions per term if the number of terms goes up
 21:48 ##taproot-bip-review: < kabaum> sipa: Thank you so much for the lecture! Hope to see you next Q&A!
 21:48 ##taproot-bip-review: < kabaum> Buy all!
 21:49 ##taproot-bip-review: < sipa> https://cryptojedi.org/peter/data/eccss-20130911b.pdf
 21:49 ##taproot-bip-review: < sipa> this slide deck explains a lot of the ideas behind efficient multi-multiplication and more
 21:50 ##taproot-bip-review: < kabaum> Noted!
 21:53 ##taproot-bip-review: < instagibbs_> thick meeting notes :)
 21:53 ##taproot-bip-review: < instagibbs_> is there a name for the fixed sized signature encoding
 21:56 ##taproot-bip-review: < instagibbs_> bip-schnorr signature encoding I guess :P
 22:04 ##taproot-bip-review: < sipa> "64 byte sigs"
 22:04 ##taproot-bip-review: < sipa> "compact sigs"
 22:04 ##taproot-bip-review: < sipa> "non-braindead sigs"
 22:05 ##taproot-bip-review: < waxwing> was pretty disappointed you didn't use ASN.1 ngl
 22:07 ##taproot-bip-review: < instagibbs_> is secp's ECDSA compact serialization (e,s)?
 22:07 ##taproot-bip-review: < instagibbs_> looks like it's two scalars :)
 22:08 ##taproot-bip-review: < instagibbs_> in other words, it's not "entirely obvious" but the name is going to be BIPXXX
 22:09 ##taproot-bip-review: < sipa> no, it's (r,s) (where r = R.x)
 22:09 ##taproot-bip-review: < sipa> also, ECDSA doesn't have an equivalent for "e" (it has no hashes)
 22:09 ##taproot-bip-review: < instagibbs_> (r,s), right, :)
 22:17 -!- midnight [~midnightm@unaffiliated/midnightmagic] has joined ##taproot-bip-review
 22:18 ##taproot-bip-review: < midnight> ahh..  here it is.
 22:36 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 22:38 -!- davterra [[email protected]] has joined ##taproot-bip-review
 22:57 -!- Moller40 [[email protected]] has joined ##taproot-bip-review
 23:12 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 23:46 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 00:15 -!- davterra [[email protected]] has joined ##taproot-bip-review
 01:11 ##taproot-bip-review: < elichai2> sipa: I just went over the meeting, awesome explanations :)
 01:11 ##taproot-bip-review: < 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
 01:12 ##taproot-bip-review: < elichai2> (I'm actually not sure I looked at the signing mult function in libsecp)
 01:15 ##taproot-bip-review: < 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)
 01:16 ##taproot-bip-review: < elichai2> At least that's my understanding (which I might be wrong :) )
 01:18 ##taproot-bip-review: < sipa> elichai2: i don't understand
 01:19 ##taproot-bip-review: < 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)
 01:19 ##taproot-bip-review: < 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)
 01:22 ##taproot-bip-review: < elichai2> Isn't that just because ecdsa is multiplied by the multiplicative inverse of the nonce?
 01:22 ##taproot-bip-review: < elichai2> Arghh I confused myself
 01:23 ##taproot-bip-review: < sipa> ECDSA effectively uses r=R.x as challenge
 01:23 ##taproot-bip-review: < 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)
 01:27 ##taproot-bip-review: < elichai2> Looked again at the equations, and even if I remove the division by k I still can't make like (e, s)
 01:27 ##taproot-bip-review: < elichai2> The fact that the nonce is by itself in schnorr helps a lot
 01:29 ##taproot-bip-review: < sipa> the equation is sR = mG + rP, where R is some point whose X coordinate is r
 01:30 ##taproot-bip-review: < sipa> treating ECDSA as "(R, s)": compute r=R.x, and verify the equation
 01:30 ##taproot-bip-review: < 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
 01:30 ##taproot-bip-review: < elichai2> Am I understanding correctly?
 01:30 ##taproot-bip-review: < sipa> treating ECDSA as "(e, s)" (with e=r), compute R as (mG+rP)/s, then extract R.x and compare it with e
 01:31 ##taproot-bip-review: < sipa> i'm saying the opposite: ECDSA is actually already in (e, s) form (if you call e=R.x)
 01:32 ##taproot-bip-review: < sipa> it's just confused because e is just computed directly from the R point... so it looks like it's encoding R itself
 01:32 ##taproot-bip-review: < elichai2> What will be the security if you split e up?
 01:33 ##taproot-bip-review: < sipa> what do you mean split e up?
 01:33 ##taproot-bip-review: < elichai2> I.e verify like this: e==R.x[:32]
 01:33 ##taproot-bip-review: < elichai2> Or something like that
 01:33 ##taproot-bip-review: < elichai2> Can you make "short ecdsa signatures"?
 01:34 ##taproot-bip-review: < sipa> that's a great question
 01:34 ##taproot-bip-review: < elichai2> * e==R.x[:16]
 01:34 ##taproot-bip-review: < sipa> but it's hard to answer without an accepted security proof
 01:34 ##taproot-bip-review: < sipa> like... as far as provable security goes, under standard assumptions, ECDSA is insecure with either a short or a long 'e' :p
 01:35 ##taproot-bip-review: < elichai2> It's easier to think with hash functions, but shortening a point seems scary lol (in terms of uniformity)
 01:35 ##taproot-bip-review: < elichai2> Lol yeah
 01:36 ##taproot-bip-review: < sipa> ok, let's redefine ECDSA signatures as (e,s) for which H((mG + eP)/s) = e
 01:36 ##taproot-bip-review: < sipa> so replacing "x coordinate of" with a hash function
 01:36 ##taproot-bip-review: < elichai2> Hmm that sounds like you can just use a shorter hash
 01:36 ##taproot-bip-review: < sipa> which is *not* ECDSA, to be clear
 01:37 ##taproot-bip-review: < 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
 01:37 ##taproot-bip-review: < sipa> http://www.neven.org/papers/schnorr.pdf ?
 01:37 ##taproot-bip-review: < elichai2> Yes
 01:37 ##taproot-bip-review: < sipa> no Bone involved
 01:37 ##taproot-bip-review: < elichai2> Ops no Bone
 01:37 ##taproot-bip-review: < elichai2> Neven == Bone :P
 01:37 ##taproot-bip-review: < sipa> also, do you mean Boneh?
 01:38 ##taproot-bip-review: < elichai2> (for some reason in my mind lol)
 01:38 ##taproot-bip-review: < elichai2> Yes you'll need to excuse me, it's 3am here heh
 01:39 ##taproot-bip-review: < elichai2> That's why https://eprint.iacr.org/2018/483
 01:39 ##taproot-bip-review: < elichai2> Got me confused that this was also Neven+Boneh
 01:51 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 02:02 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review
 02:25 ##taproot-bip-review: < luke-jr> this channel should be logged :/
 02:25 ##taproot-bip-review: <@aj> it is logged?
 02:26 ##taproot-bip-review: < harding> http://www.erisian.com.au/taproot-bip-review/
 02:26 -!- mode/##taproot-bip-review [+o harding] by ChanServ
 02:27 -!- harding changed the topic of ##taproot-bip-review 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
 02:27 -!- mode/##taproot-bip-review [-o harding] by harding
 03:42 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 04:25 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined ##taproot-bip-review
 04:35 ##taproot-bip-review: < 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.
 04:35 ##taproot-bip-review: < 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.
 04:36 ##taproot-bip-review: < 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.
 04:38 ##taproot-bip-review: < 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).
 04:39 ##taproot-bip-review: < 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.
 04:41 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 04:41 ##taproot-bip-review: < 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.
 04:44 ##taproot-bip-review: < gmaxwell> waxwing
 04:44 ##taproot-bip-review: < gmaxwell> waxwing: RFC6979 is awful for complicated political reasons.
 04:46 ##taproot-bip-review: < 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.
 04:47 ##taproot-bip-review: < 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.
 04:49 ##taproot-bip-review: < gmaxwell> the bip-schnorr recommended nonce procedure is the same (IIRC) as the EdDSA one.
 04:49 ##taproot-bip-review: < gmaxwell> (except for the whole prehashing the secret part, which isn't compatible with ... well.. anything interesting)
 04:53 ##taproot-bip-review: < nothingmuch> gmaxwell: yes, i later realized compact blocks completely moot my point ;-)
 04:53 ##taproot-bip-review: < nothingmuch> s/point/concern/;
 04:56 ##taproot-bip-review: < nothingmuch> i suppose that flawed assumption being interpreted too charitably by nickler and sipa was why i felt i needed to follow up
 04:58 ##taproot-bip-review: < gmaxwell> well bandwith is certantly an issue too, orphaning aside.
 04:58 ##taproot-bip-review: < 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.
 04:59 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review
 04:59 ##taproot-bip-review: < 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.
 05:00 ##taproot-bip-review: < 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.
 05:00 ##taproot-bip-review: < sipa> * 128 security level
 05:00 ##taproot-bip-review: < gmaxwell> If we were talking about a 448 bit curve or something, then I think a shortned signature might be more interesting.
 05:00 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 05:02 ##taproot-bip-review: < 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.
 05:10 ##taproot-bip-review: < 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?
 05:11 ##taproot-bip-review: < sipa> nothingmuch: interchange what with what?
 05:11 ##taproot-bip-review: < sipa> schnorr with bls?
 05:12 ##taproot-bip-review: < nothingmuch> no, <e,s> and <r,s> forms (is r a typo fo R here? or a differently defined scalar?)
 05:12 ##taproot-bip-review: < sipa> nothingmuch: in schnorr?
 05:12 ##taproot-bip-review: < sipa> it's the first paragraph in the bip
 05:12 ##taproot-bip-review: < nothingmuch> sipa: see gmaxwell's remark on third design option, 14 min ago
 05:13 ##taproot-bip-review: < sipa> e = hash(R || P || m)
 05:13 ##taproot-bip-review: < sipa> so you can convert (R, s) into (e, s) by just computing the hash of R||P||m
 05:13 ##taproot-bip-review: < 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
 05:14 ##taproot-bip-review: < sipa> and convert (e, s) into (R, s) by computing R = sG - eP
 05:14 ##taproot-bip-review: < nothingmuch> oh, right! i think this is an indication i should have gone to sleep a while aog
 05:14 ##taproot-bip-review: < sipa> haha
 07:07 -!- pglazman [[email protected]] has joined ##taproot-bip-review
 09:41 -!- davterra [[email protected]] has joined ##taproot-bip-review
 10:35 -!- kabaum [[email protected]] has joined ##taproot-bip-review
 11:04 -!- kabaum [[email protected]] has joined ##taproot-bip-review
 11:45 ##taproot-bip-review: < 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?
 12:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 13:11 -!- kabaum [[email protected]] has joined ##taproot-bip-review
 13:13 -!- andytoshi [[email protected]] has joined ##taproot-bip-review
 13:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review
 13:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review
 14:03 ##taproot-bip-review: < 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...
 14:06 ##taproot-bip-review: < 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?
 14:09 ##taproot-bip-review: < 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
 14:29 -!- jonatack [[email protected]] has joined ##taproot-bip-review
 14:37 ##taproot-bip-review: < instagibbs_> nothingmuch, leaf version is defined at the "code block" or whatever it's called, so you cannot have different leaf versions per output
 14:39 ##taproot-bip-review: < nothingmuch> instagibbs_: oh! thank you that makes more sense
 14:56 ##taproot-bip-review: < instagibbs_> the annex, well, just think of any use where you'd want non-third-party malleable witness data.
 15:17 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review
 15:19 ##taproot-bip-review: < 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?
 15:24 -!- shesek [[email protected]] has joined ##taproot-bip-review
 15:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review
 15:41 -!- kabaum [[email protected]] has joined ##taproot-bip-review
 15:50 -!- HighOnBtc [[email protected]] has joined ##taproot-bip-review
 16:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review