--- 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?