--- Day changed Wed Nov 20 2019
00:30 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Quit: Bye]     
00:40 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 265 seconds]     
00:41 -!- davterra [~dulyNoded@195.242.213.120] has joined ##taproot-bip-review     
01:35 -!- kabaum [~kabaum@93.182.128.34] has joined ##taproot-bip-review     
02:03 -!- kabaum [~kabaum@93.182.128.34] has quit [Ping timeout: 276 seconds]     
02:04 -!- kabaum [~kabaum@ec2-52-212-246-229.eu-west-1.compute.amazonaws.com] has joined ##taproot-bip-review     
02:45 < 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?
03:11 -!- kabaum [~kabaum@ec2-52-212-246-229.eu-west-1.compute.amazonaws.com] has quit [Ping timeout: 240 seconds]     
03:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
04:11 -!- kabaum [~kabaum@ec2-52-212-246-229.eu-west-1.compute.amazonaws.com] has joined ##taproot-bip-review     
04:13 -!- andytoshi [~apoelstra@wpsoftware.net] has joined ##taproot-bip-review     
04:13 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]     
04:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review     
04:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
04:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
05:02 -!- kabaum [~kabaum@ec2-52-212-246-229.eu-west-1.compute.amazonaws.com] has quit [Ping timeout: 265 seconds]     
05:03 < 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...
05:06 < 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?
05:09 < 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
05:29 -!- jonatack [~jon@213.152.161.25] has joined ##taproot-bip-review     
05:37 < instagibbs_> nothingmuch, leaf version is defined at the "code block" or whatever it's called, so you cannot have different leaf versions per output
05:39 < nothingmuch> instagibbs_: oh! thank you that makes more sense
05:56 < instagibbs_> the annex, well, just think of any use where you'd want non-third-party malleable witness data.
06:17 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
06:19 < 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?
06:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]     
06:24 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
06:39 -!- daniel__ [~quassel@89.245.184.230] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]     
06:41 -!- kabaum [~kabaum@185.224.57.161] has joined ##taproot-bip-review     
06:50 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review     
07:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
07:08 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
07:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
07:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
07:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
07:26 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
07:34 -!- jonatack [~jon@213.152.161.25] has quit [Ping timeout: 240 seconds]     
07:38 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]     
07:39 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]     
07:39 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 260 seconds]     
07:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]     
07:40 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
07:43 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review     
07:43 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review     
07:46 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review     
07:50 < ZmnSCPxj_> nothingmuch: annexes are attested to by any signatures checked; other elements on the witness stack may have looser requirements
08:01 -!- ajonas [sid385278@gateway/web/irccloud.com/x-roxvryzffjhjkyws] has quit []     
08:05 -!- jonatack [~jon@89-93-131-92.hfc.dyn.abo.bbox.fr] has joined ##taproot-bip-review     
08:06 -!- kabaum [~kabaum@185.224.57.161] has quit [Ping timeout: 240 seconds]     
08:15 < sipa> nothingmuch: the difference is that the annex is independent of script
08:15 < sipa> as it does not become a stack element for script
08:16 < sipa> it's more a txin-level extension (like nSequence)
08:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
08:22 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
08:28 < sipa> as for what upgrade mechanism to use for what:
08:29 < sipa> * OP_SUCCESSx to introduce new opcodes in script, as it permots doing so without incrementing any version numbers or whatnot
08:30 < sipa> * Upgradable pubkey types to introduce new digital signature schemes. OP_SUCCESSx can also be used for those, but you'd need to add an equivalent to all 3 (CHECKSIG, CHECKSIGVERIFY, CHECKSIGADD) every time
08:31 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 246 seconds]     
08:33 < sipa> * Leaf versions are better for large structural changes to script that aren't just introducing new opcodes (this can also be done using OP_SUCCESSx, but there were a few unused bits in the control block, so better use it)
08:35 < sipa> * witness versions and witness prpgram length can be changed to replace the taproot structure with something else (e.g. something adding graftroot or cross-input aggregation)
08:59 < nothingmuch> ZmnSCPxj_, sipa: thanks that cleared up the differences
09:01 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has joined ##taproot-bip-review     
09:01 < nothingmuch> what's the advantage of introducing new opcodes without incrementing version numbers?
09:03 < nothingmuch> regarding new pubkey types, is the assumption that key_version != 0 data will never be 32 bytes in length? (ignoring the OP_SUCCESS possibility)
09:04 < instagibbs_> nothingmuch, more flexible deployment I think, and preserve's the leaf version byte for bigger upgrades
09:04 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has quit [Client Quit]     
09:05 < sipa> nothingmuch: version numbers are limited and require serialized deployment
09:05 < nothingmuch> also i realized my misunderstanding re key_version, it's only in the digest, right?
09:05 < sipa> "vX is these opcodes, v(X+1) is all those plus Y, v(X+2) adds these additional ones"
09:06 < sipa> nothingmuch: yes, key version is just in the sighash
09:06 < sipa> and yes, new key types will use a length different from 32
09:07 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has joined ##taproot-bip-review     
09:09 < sipa> nothingmuch: while with OP_SUCCESSx you just introduce a new opcode, potentially even in parallel with other ones already in the pipeline
09:10 < nothingmuch> is it fair to say different rule sets can be partially ordered by the ops that they used, and these incomparability classes are totally ordered by leaf version numbers?
09:10 < sipa> ... mostly
09:11 < sipa> of course, you could also say "this bit in the leaf version has this effect, and independently this bit has another effect"
09:11 < nothingmuch> because leaf version increments may not be monotone?
09:11 < sipa> right
09:11 < nothingmuch> ah, right
09:12 < sipa> but both op_successx and leaf versions can be used to effectively.completely replace the script language with something else, if desired
09:12 < sipa> it's just more natural to do it with leaf versions
09:15 < nothingmuch> yeah i was a bit surprised that OP_SUCCESSx was syntactically such a departure from NOPs, despite being superficially similar, but it seems like a more sensible design
09:15 < sipa> they're so much more powerful
09:19 < nothingmuch> so for a hypothetical future soft fork, the choice mainly comes down to whether or not new rules can be made to naturally compose with existing opcodes (in which case OP_SUCCESS), if not but it still fits in with the execution model & tx structure (handwavy), leaf version, falling back to witness version?
09:24 < sipa> right, but there is a huge difference beteeen using a new witness version and a leaf version
09:25 < sipa> the former is only revealed to the network when spending (and because different leaves can have a different leaf version, only when a script that actually uses it), while a new witness version is visible to the network at creation time
09:27 < nothingmuch> wait since leaf version is provided at spend time, doesn't that mean that non-monotone ruleset changes wrt to leaf version may be unsafe, since they can change intended spending conditions at output creation?
09:29 < sipa> nobody will create a script with an undefined leaf version
09:29 < nothingmuch> ah i see, the tree also commits to it
09:29 < sipa> the one creating the address knows all the leaf versions potentially involved in it
09:29 < sipa> yeah
09:30 < nothingmuch> sorry, i misinterpreted instagibbs_'s correction of my misunderstanding above
09:31 < nothingmuch> (as saying leaf version was in the codeblock *instead* of tree, and i thought i just invented the version in the tree)
09:31 < nothingmuch> ok i think that's finally everything i'm confused about sorted, but i'm sure there will be more =)
09:41 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]     
09:42 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review     
09:59 -!- sanoj [sid385278@gateway/web/irccloud.com/x-toqmhvdkwcptqtmz] has joined ##taproot-bip-review     
10:01 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review     
10:15 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
10:15 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review     
10:22 -!- davterra [~dulyNoded@195.242.213.120] has quit [Ping timeout: 276 seconds]     
10:22 -!- davterra [~dulyNoded@195.242.213.120] has joined ##taproot-bip-review     
10:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
10:41 < ZmnSCPxj_> re: but both op_successx and leaf versions can be used to effectively.completely replace the script language with something else, if desired
10:42 < ZmnSCPxj_> It is possible to define an op_successx such that the rest of the program after it will be written in a different language other than Bitcoin SCRIPT.
10:42 < ZmnSCPxj_> Thus it is possible to completely replace the script language using op_successx
10:43 < ZmnSCPxj_> This remains compatible with existing SCRIPT interpreters, as they will stop parsing with a success upon reading any OP_SUCCESSX.
10:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
10:43 < sipa> ZmnSCPxj_: yeah, that's what i was referring to
10:44 < sipa> the fact that op_successx is processed before actual execution starts means it can be used to redfine all of script (though in a slightly convoluted way)
10:55 < nothingmuch> ZmnSCPxj_: isn't it the entire program, not just the rest of the program after it?
10:56 < nothingmuch> that said, the motivation behind this mechanism is so that defining new opcodes that are largely compatible can be done with minimal changes to interpreters when appropriate, right?
10:57 < sipa> nothingmuch: no, any OP_SUCCESSx anywhere in the program (even in otherwise seemingly unexecuted branches) will cause instant success
10:57 < sipa> oh, sorry, you were correcting ZmnSCPxj_ on this
10:57 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has joined ##taproot-bip-review     
10:58 < nothingmuch> (iow remotivation, generally that should not be desired, since leaf version can be changed instead)
10:59 < sipa> nothingmuch: the idea is that e.g. it can be used so that a new opcode changes overall semantics (e.g. a new 64-bit OP_ADD64 could lift restrictions on the size of numeric values everywhere)
10:59 < sipa> i agree this is somewhat less necessary due to leaf versions
11:02 < nothingmuch> is it accurate that an interpreter that has an additional opcode that does not interact like that should be able to interpret old programs with no considerations apart from what block height the opcode comes into effect?
11:02 < nothingmuch> s/has/supports/
11:03 < sipa> i don't understand your question
11:04 < nothingmuch> suppose there is a soft fork that adds OP_FOO which asserts something about the annex for instance, and does not change semantics globally, after that definition has been added to the interperter's implementation are there additional considerations re compatibility apart from when that individual opcode was added?
11:06 < sipa> if it's redefining an OP_SUCCESSx, there should be no considerations - as the mere presence of an OP_SUCCESSx before meant it was an automatic success to spend
11:06 < nothingmuch> i'm trying to think whether that can interfere with validation of scripts before this OP_FOO soft fork is activated (seems not)
11:07 < nothingmuch> so then suppose there is both OP_FOO and OP_BAR, - the implementations should likewise be compatible regardless of the order they actually get activated, right?
11:07 < sipa> well of course the implementation must make sure that script semantics prior to the softfork are unaffected by the introduction of OP_FOO
11:08 < sipa> but that's relatively easy in many cases (e.g. change a "return true;" to "if (softfork) { ... } else { return true; }")
11:08 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has quit [Quit: Sleep mode]     
11:08 < nothingmuch> is it fair to say that OP_SUCCESS is specifically intended softforks that should not affect semantics in that way? (since otherwise might as well change leaf version?)
11:09 < sipa> the leaf version only has 5 bits
11:11 < nothingmuch> i guess this question is too vague, but basically "if desired" - apart from conserving leaf version bits is there any reason to do that?
11:12 < sipa> i think OP_SUCCESSx is designed for everything: it can be used for otherwise-non-interacting-opcodes or for large-redesigns-of-script
11:12 < instagibbs_> parallel softfork proposals for two op_success redefinitions(provide they don't conflict) vs conflicting leafe version
11:12 < sipa> leaf versions are just a "we have 5 unused bits, might as well turn them into an extension mechanism as well"
11:26 -!- jonatack [~jon@89-93-131-92.hfc.dyn.abo.bbox.fr] has quit [Ping timeout: 276 seconds]     
11:32 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review     
12:11 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
12:15 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has joined ##taproot-bip-review     
12:29 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has quit [Quit: Sleep mode]     
12:30 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has joined ##taproot-bip-review     
12:39 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review     
13:05 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:22 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review     
13:56 -!- jonatack [~jon@109.202.107.147] has joined ##taproot-bip-review     
13:56 -!- jonatack [~jon@109.202.107.147] has quit [Read error: Connection reset by peer]     
14:02 -!- jonatack [~jon@37.166.80.227] has joined ##taproot-bip-review     
14:05 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]     
14:05 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]     
14:05 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
14:06 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review     
14:06 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review     
14:10 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has quit [Quit: Sleep mode]     
14:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
14:41 -!- pinheadmz [~matthewzi@91.132.137.236] has quit [Quit: pinheadmz]     
15:57 -!- pinheadmz [~matthewzi@91.132.137.236] has joined ##taproot-bip-review     
16:04 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
17:04 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review     
17:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
17:26 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:52 <@aj> waxwing: grabbing an email address this time so if there's any substantive questions they can be followed up on; you should be able to use a throwaway address of some sort if you'd like; i don't think they're strongly validated
17:53 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has joined ##taproot-bip-review     
17:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
18:04 -!- soju [uid403160@gateway/web/irccloud.com/x-qqvgocvrdemjdsjf] has joined ##taproot-bip-review     
18:05 < michaelfolkson> Hey. Is there a Q&A happening now?
18:06 < soju> Yes.
18:06 < michaelfolkson> OK thanks
18:07 < moneyball> Week 3 email noted that there is not one
18:07 < moneyball> Demand for this time has been very low
18:08 < sipa> moneyball: you're too late; michaelfolkson asked a question and received an answer; that qualifies as a Q&A
18:08 < soju> Oh oops! Sorry Michael.
18:08 < moneyball> Haha
18:08 < sipa> in fact, you're participating by improving the discussion around the provided answer
18:08 < moneyball> Also sipa is in here 24/7 so...
18:09 < michaelfolkson> Haha well that was the only question I had
18:09 < michaelfolkson> Ok I will join next Tuesday then I guess.... Or can we do a Q&A with sipa now?
18:09 < gmaxwell> Is now the time to announce that taproot is being replaced by IOTA Trinary hash?
18:10 < gmaxwell> just to bother all the people who weren't here?
18:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
18:10 < sipa> michaelfolkson: you're always welcome to ask questions
18:10 < gmaxwell> You might recieve puns instead of answers...
18:11 <@aj> michaelfolkson: you've hacked the system man
18:11 < michaelfolkson> Puns will do just fine. I'm sure my study group would prefer puns anyway
18:12 < sipa> we can punt on actually answering
18:12 < michaelfolkson> Ok 1) Swapping in different elliptic curves
18:13 < michaelfolkson> "It would be interesting to understand what parts of the construction used in BIP Schnorr would fall apart when using a different underlying curve (such as Curve25519 which most people use). I completely understand the argument of re-using secp256k1 but it would be interesting if our choice of signature standard was still secure with other curves. The part that needs clarifying on that front is probably
18:13 < michaelfolkson>  footnotes 7 to 10 that may be specific to secp256k1"
18:13 < sipa> the only thing that would need to change is the nonce generation algorithm
18:14 < sipa> i believe
18:14 < sipa> as we can take advantage of the curve order being negligably close to 2^256
18:14 < michaelfolkson> Which sounds doable...?
18:15 < sipa> yes, but it would come at a performance and complexity cost for secp256k1
18:15 < sipa> for ed25519 you also have to deal with cofactor mess... secp256k1 is easy as it has cofactor 1; i haven't thought hard about how to make the whole construction deal correctly with non-1 cofactors, and i don't think it's worth spending time on
18:16 < michaelfolkson> This was asked under the broader discussion umbrella of whether existing (non-Bitcoin) industry implementations of Schnorr could have been leveraged in our Schnorr implementation
18:17 < sipa> michaelfolkson: if you want to use ed25519 somewhere, you should just use ed25519 - not bip-schnorr-adapted-to-the-ed25519-curve
18:17 < michaelfolkson> Or our Schnorr implementation could be used as a standard for industry and academia (non-Bitcoin, non-crypto) going forward
18:17 < sipa> sure
18:18 < sipa> that's one of the reasons why bip-schnorr is a separate bip... though i suspect most interest will come from bitcoin related projects (even if not on-chain), due to compatibility with existing key infrastructure
18:19 < michaelfolkson> It was briefly discussed in that LTB podcast you did that Apple are already using a Schnorr based scheme but you don't know much about it. That's because Apple don't open source it?
18:20 < sipa> i have no recollection of having made such a statement!
18:20 < michaelfolkson> Andreas: Which is the Apple one?
18:20 < michaelfolkson> Pieter: I have no idea but that wouldn't surprise me. That is essentially also a specialization of a Schnorr based scheme into a practical standard. We can't use ed25519 for several reasons. One of them is we like to maintain compatibility with the existing public key system we have so that things like BIP32 and everything built on it don't get invalidated. That wouldn't be a terrible thing to do but it is
18:20 < michaelfolkson>  simple enough to maintain compatibility so we define a Schnorr signature over the secp256k1 curve which is the same curve that Bitcoin's ECDSA scheme is currently defined over.
18:20 < michaelfolkson> Sure, sorry I'm not being accurate
18:21 < sipa> the most commonly used ec schnorr based signature scheme today is ed25519
18:21 < sipa> i don't actually know of any others
18:22 < gmaxwell> I don't think ed25519 would be particularly interesting in any case, even if we didn't care about compatiblity. The cofactor really is a big nussance. Existing implementations don't have non-malleable and consistent behavior, and or require stuff like the MSB of the private key be set (not compatible with BIP32 like derrivation), so you'd need to use a specialized implementation anyways.
18:22 < sipa> not sure what the "apple" does in that transcript, maybe the transcript is wrong, but i don't know anything relating apple and ed25519 or schnorr
18:23 <@aj> Pieter: There's a number of other signature schemes that are essentially Schnorr based but don't go by that name. One of them is ed25519.
18:23 <@aj> Andreas: Which is the Apple one?
18:23 <@aj> was the prior context
18:24 < michaelfolkson> http://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2019-06-09-ltb-pieter-wuille-jonas-nick/
18:24 < michaelfolkson> Yeah thanks aj
18:24 < michaelfolkson> If the transcript is wrong then that'd be my fault too lol
18:25 < sipa> also, secp256k1 has 1.41 bits more security :p
18:26 < michaelfolkson> Any open source non-Bitcoin/crypto industry Schnorr libraries you're aware of? Google generally open source their crypto libraries? I'm assuming no
18:26 < sipa> in order for there to be a library there must be scheme to implement
18:26 < michaelfolkson> Again the context being "The reason I'm interested in that is that if BIP Schnorr can be re-used securely and efficiently over other curves, other projects might implement it and that may bring more people to review its security (if Apple wanted to use it for example)"
18:27 <@aj> https://developer.apple.com/documentation/cryptokit -- does ed25519 presumably with their schnorr std, and p256 and p384 with ecdsa
18:27 < michaelfolkson> Future industry/academia collaboration
18:28 < sipa> michaelfolkson: i think all the relevant minor things in bip-schnorr are essentially specific to the curve... like leveraring that negating a public key changes the quadratic residuosity of y, that there is no cofactor, that the curve order is close to 2^256
18:29 < sipa> if you'd want to adapt bip-schnorr to work with the ed25519 curve, i think you'd pretty much exactly end up with just ed25519
18:29 < gmaxwell> sipa: to be fair the negation thing works for mot fields.
18:29 < sipa> mot fields?
18:29 < gmaxwell> sipa: unfortunately that isn't true, because ed25519 is underspecified, permits malleablity, etc.
18:29 < gmaxwell> sipa: most*
18:30 < sipa> gmaxwell: half of them, i believe?
18:30 < gmaxwell> sipa: E.g. ed25519 verfiers disagree on if 0 is a valid public key,  and there are several variations of range checks/modular reductions for S, some of which allow malleability.
18:30 < gmaxwell> In the original ed25519 paper they explicitly mention malleability and dismiss it as not interesting.
18:31 < sipa> gmaxwell: yeah, that's fair - but my point is that the extent to which bip-schnorr deviates from the most naive schnorr implementation you can come up with is very much dependent on the curve we have
18:31 < gmaxwell> "Malleability.We also see no relevance of “malleability” to the standard defini-tion of signature security."
18:31 < gmaxwell> Yes, thats a fair point.
18:32 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 240 seconds]     
18:33 < michaelfolkson> In non-blockchain use cases they're right not to be worried about malleability right?
18:33 < sipa> they might not, it depends on the use case
18:33 < michaelfolkson> Some of these problems seem cryptocurrency/blockchain specific which means we need different things
18:34 < gmaxwell> in any kind of consensus system malleability is a fatal problem, but it is also a problem in other systems.
18:34 < michaelfolkson> Ok, interesting
18:34 < gmaxwell> For example x509 certificate blacklisting uses the hash of the certificates, so malleability can let you bypass a blacklist.
18:34 -!- jonatack [~jon@37.166.80.227] has quit [Read error: Connection reset by peer]     
18:34 < gmaxwell> I think the sentence from the ed25519 paper is technically correct: malleability is irrelevant to the standard definition of signature security.
18:35 < sipa> i think one thing where do go further than existing standards is in having well-defined batch validation (we guarantee with extremely high probability that batch verification will always give the same result as non-batch validation, even in the presence of malicious signers)
18:35 < gmaxwell> But the standard defintion isn't sufficient. :)
18:35 < gmaxwell> (and ed25519 is not worse than the sea of random ECDSA stuff that was out before it)
18:36 < sipa> and in order for that to be the case, we actually had to make non-batch validation sightly more complex
18:37 < gmaxwell> sipa: I think that ed25519 is well defined batch verifyable (ignoring the parts of its validity which aren't well defined at all)
18:37 < sipa> possibly, i'm not sure
18:37 < gmaxwell> (they send explicit R signs, and weren't aware of the projective comparison trick we would otherwise use for non-batch)
18:38 < gmaxwell> but yeah you're right, I wouldn't be too surprised if scalar ed25519 verifiers actually fail to check R's sign.
18:38 < sipa> but i guess this is perhaps something to put formally: a signer (with access to private key) who can cause different verifiers to disagree is considered an attack
18:39 < sipa> for someone without a private key, that's trivial, as they shouldn't be able to cause verifiers to return success in the first place
18:39 < sipa> and for honest signers that's also not a problem, as soundness guarantess that their signatures will always validate
18:40 < gmaxwell> sipa: https://github.com/sipa/bips/issues/110
18:40 < sipa> gmaxwell: i know
18:41 < sipa> i was trying to word in a more formal way
18:41 < gmaxwell> 'I think the objective of this specification is that every input string is consistently rejected or accepted by all conforming implementations, regardless of how the input string was constructed. This is not an objective that normally shows up for other signature systems, instead they just want the weaker property of "signatures constructed with the specified procedure will be accepted and
18:41 < gmaxwell> someone who doesn't know the private key can not construct an accepted string".'
18:43 < michaelfolkson> Let me know when ready for new question, don't want to interrupt trail of thought :)
18:45 < gmaxwell> shoot
18:46 < sipa> *bang*
18:47 < michaelfolkson> Ok. So again in the broader context of this BIP review process there were a couple in my study group who were unsure how they could best add value. Working on use cases of Taproot or trying to get engaged in security proof discussion, attempting to make Musig secure etc
18:47 < moneyball> I’m very happy with the quality of this canceled Q&A session 🙃
18:48 < michaelfolkson> This blog post from Jonas was great, educational but a couple of people were wondering whether to just read it for education or to go down this rabbit hole https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da
18:48 <@aj> (should cancel more of them?)
18:48 < michaelfolkson> If they were to go down this rabbit hole how best would they engage, find out more about the attempts to make Musig secure for example?
18:49 < michaelfolkson> Lol     
18:49 < sipa> michaelfolkson: making things secure is hard, as you never really get a positive answer
18:51 < sipa> it of course depends on people background, but i suspect that for many of them probably a more useful contribution is trying to work out use cases
18:51 < sipa> and seeing what roadblocks you run into
18:53 < michaelfolkson> But going through commit history of say the Blockstream secp256k1 library to understand what was there before and what was changed would be good idea if they wanted to go this route (identifying potentially more weaknesses/attack vectors)
18:53 < waxwing> gmaxwell, "malleability is irrelevant to the standard definition of signature security." <-- well it seems to be pretty relevant to SUF-CMA :)
18:53 < michaelfolkson> Obviously not for everyone. But I've a got a couple of smart cookies in my study group
18:54 < waxwing> michaelfolkson, the best way to go down the musig rabbit hole is probably to read the paper.
18:54 < waxwing> i mean not all of it necessarily :)
18:55 < sipa> michaelfolkson: well musig has a security proof - it's based on certain assumptions, and obviously reality does not necessarily match the model used to prove its security
18:56 < sipa> michaelfolkson: but i believe that shifts the question not from "is this scheme - in abstract - secure or not", but whether implementations actually match the abstract scheme
18:56 < sipa> i think reading about failed predecessors and insecure modifications is helpful in teaching you what kind of things to pay attention to
18:57 < sipa> but not in analysing the scheme itself, only in making sure you're not deviating from it in relevant ways
18:57 < sipa> e.g. if you hadn't read https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da, maybe you'd never have considered that precomputing nonces would be a meaningful deviation from the abstract scheme presented in the paper
18:58 < waxwing> for example, what jonas talks about in that excellent blog is a good example of one potential problem, but you can see a simpler example of wagner's attack described in the paper, which gives a nice insight into why musig is the way it is.
18:58 < waxwing> i mean for certain values of 'simpler' :)
18:59 < michaelfolkson> But what to recommend reading/reviewing after the blog post and after the Musig paper?
19:00 < waxwing> i almost feel like you want to read other stuff *before* that, not after :) the musig paper is an end point of a lot of prior research.
19:00 < waxwing> but maybe you mean like code or something?
19:01 < michaelfolkson> Yeah
19:01 < sipa> fwiw, the proofs in the musig paper are unreadable to me, and don't convey any understanding about what is secure and insecure to me
19:01 < sipa> for example, gregory neven once told me that he was talking to someone implementing his bn06 scheme, and told them that it was absolutely required that the non precommitment round was really required
19:02 < sipa> and then the person he was talking to said they'd just send the hash of the nonce and nonce in the same message
19:02 < waxwing> heh     
19:02 < sipa> clearly they had no clue what a round in a protocol, and the necessity for it, was
19:02 < waxwing> as long as you serialize them in the right order, it's secure :)
19:02 < sipa> but that's not an unreasonable mistake to make for someone who isn't familiar with these sort of protocols
19:03 < sipa> so i think that learning about near-misses of this kind can teach you to better distinguish between what implementation variations are reasonable to make and which ones aren't
19:04 < michaelfolkson> Ok that's been an hour. I was going to ask about use cases as well but that can wait for another Q&A
19:05 < michaelfolkson> Thanks a lot all (especially as it wasn't supposed to happen....)
19:05 < waxwing> i could play devil's advocate though: as systems get more complex, it's arguably of less and less value to take that incremental approach. for example learning what an extractor is in a sigma protocol means you actually have a sense of what defends against forgery, learning about 'attack 1', 'attack 2' is less helpful. since there's always an attack 3.
19:05 <@aj> michaelfolkson: well, "ask questions any time" is okay too, doesn't have to be in a Q&A slot
19:06 < michaelfolkson> Ok cool
19:06 < sipa> waxwing: my point isn't that learning about these failures will teach you how to build a secure protocol on itself
19:07 < sipa> but that because there are always deviations between theory and practice, and failures often teach you what kind of deviations are red flags
19:09 < gmaxwell> It's tricky of course because learning a lit of mistakes and avoiding every one doesn't make it secure.  Really the purpose of learning is to get a feel for how brittle the constructions are.
19:09 <@aj> implementing variants of this with weaker cryptographic primitives so that these attacks are practical might be worthwhile -- "here's how you can break a weaker version with this procedure, so it's fair to expect the NSA/mafia/google can break real variants if implemented poorly in the near future"
19:09 < gmaxwell> aj: for a lot of this stuff, at least for fancy uses, minor errors mean anyone can break it. :(
19:10 < waxwing> my 'less helpful' is unhelpful :) but, i think there's a point there about growing complexity and fundamental principles.
19:10 < waxwing> right gmaxwell nonce fragility in these sig systems is arguably kinda unacceptable. for example.
19:11 < gmaxwell> for example, reading jonas' post on round reduction being insecure made me realize another protocol I'd suggested to someone a few years ago was insecure.  (One where you publish a bunch of nonces for single show signatures, and can get a signer to sign one signature for each nonce)
19:13 < gmaxwell> (it's insecure because you can accept the nonces, then grind a lot of messages to setup a wagner attack to solve for an additional signature -- just like the problem with naieve blind signatures found in the lit)
19:14 < gmaxwell> instead if you use a single show signature, you really need to construct it using a hash commitment instead of exposing the nonce itself.
19:15 < gmaxwell> if you search around you'll see a number of times people have suggested some OP_SUBSTR sort of single show signature ... bad idea.
19:24 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
19:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:9518:d7d3:7541:1eae] has quit [Quit: Sleep mode]     
20:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
20:26 -!- pglazman [~pglazman@c-67-174-198-20.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
20:34 -!- pglazman [~pglazman@c-67-174-198-20.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
20:34 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Quit: Bye]     
20:52 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review     
20:53 < ZmnSCPxj> Given the many traps that implementation of multisignatures has, would a bip-musig describing the "one true way" make sense?
20:53 < ZmnSCPxj> Although of course a good design for libsecp256k1 MuSig support would be better, but perhaps the rationale for that design can point to the bip-musig
20:54 < ZmnSCPxj> And at least discourage roll-your-own
20:55 -!- ZmnSCPxj [9258463b@146.88.70.59] has quit [Remote host closed the connection]     
21:05 < gmaxwell> the bip would probably just end up being a transliteration of the code.
21:05 < gmaxwell> like getting it right is a billion and one tiny detals.
21:11 < gmaxwell> I fully expect we're going to see people mess this up. In particular since _most_ of the attacks require malicious signers and malicious signers are .. I'm not sure of the word for it. Clearly malicious signers are considered possible or we wouldn't bother with multisig, but I think most multisig users act as if the other signers will not be malicious.
21:11 < gmaxwell> consider how copay was letting the transaction author set the sighash flag however they wanted, including in ways that would let them trigger the sighash single weird behavior.
21:12 < gmaxwell> or the existance of hardware wallets without screens.
23:35 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]     
23:37 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review     
23:38 < ZmnSCPxj> gmaxwell: thank you. So we simply say "do not roll your own MuSig, use libsecp256k1" and hope that somebody ports it correctly to e.g. JavaScript (ha, ha)?
23:39 < ZmnSCPxj> which brings me to the problem of MuSig-in-MuSig, which seems not possible with the current exchange hash-commit-to-R, exchange R, exchange s
23:40 < ZmnSCPxj> Though I suppose the point of MuSig-in-MuSig is not that useful, other than nodelets (which suck anyway) and the general principle that a MuSig participant should not have to prove it is a singleton or aggregate
23:41 < gmaxwell> ZmnSCPxj: web assembly + that clang compiler? :P
23:42 < ZmnSCPxj> Does that work on-server in NodeJS?
23:43 < gmaxwell> Apparently. (though server nodejs can call C)
23:43 < ZmnSCPxj> yes, looks like it
23:44 < gmaxwell> I think someone writing a spec document would be useful, but less useful than implementing it.
23:48 < ZmnSCPxj> Anyway, given https://eprint.iacr.org/2018/417.pdf , can someone explaine to a non-mathist what it shows about 2-round MuSig?