02:00:12 <aj> #startmeeting
02:00:12 <lightningbot> Meeting started Thu Nov  7 02:00:12 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:00:13 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
02:00:53 <aj> hi round 2 folks!
02:00:57 <andytoshi> hiya
02:00:59 <moneyball> hi
02:01:01 <Tibo> hi
02:01:01 <fanquake> hi
02:01:03 <sipa> hi
02:01:04 <soju> hi
02:01:06 <gmaxwell> I was gonna ping everyone in the room but there are a lot of people here.
02:01:37 <sipa> Log from the previous Q&A session: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html
02:02:06 <gmaxwell> I move to approve the minutes of the last meeting. All in favor?
02:02:29 <moneyball> aye
02:02:43 <gmaxwell> Motion carries.
02:02:45 <sipa> All 60 minutes?
02:02:51 <moneyball> We have a bunch of experts here on Taproot so please ask any questions you might have
02:04:24 <gmaxwell> Especialy all those questions which you were too embarassed to ask in front of the europeans.
02:04:50 <sipa> I'll be here the whole hour, so if anything comes up, feel free to ask any time.
02:05:02 <Tibo> A small question on requiring to commit to an unspendable script path instead of having no script path. From the doc it is not clear to me if that is a "should" (like it's nice to do it especially in some specific key aggregation scheme) or a "must" (like really do it otherwise you're dead)
02:05:22 <sipa> Tibo: that's a good question
02:05:53 <sipa> there are many situations in which it's perfectly fine to just use a public key directly as an output point.
02:05:56 <andytoshi> my feeling is that it's a "should" ... there are many cases where it's safe not to do this
02:06:11 <andytoshi> in particular if there is only one party
02:06:22 <andytoshi> or if all parties are using musig and checking the derivation
02:06:53 <sipa> But at the same time, not doing it may be dangerous in situations where it isn't all that obvious, so it should be common practice to just do it.
02:06:53 <Tibo> ok thanks for clarifying!
02:07:01 <gmaxwell> If your key is truly random then it is impossible to prove to a third party that there isn't some other script.  Now, in many (most?) cases it's none of anyone elses business-- and especially not the business of a third party to the key creation-- if there is some other script...
02:07:41 <gmaxwell> It's not really that different from the fact that unless your key is in a HSM you cannot prove that you didn't give someone else a copy of the private key.
02:08:21 <andytoshi> i think having the ability to prove this is useful ... i mean, it's harmless to -have- the ability
02:08:21 <aj> if your key was generated by a HSM, you might want the HSM to prove to you there's no hidden script path in there though
02:08:31 <sipa> I think it's fair to say that it's always fine to use a pubkey directly when there is only one signer.
02:08:34 <andytoshi> oh very good point aj
02:08:36 <gmaxwell> aj: right.
02:09:30 <Tibo> I see interesting.
02:09:32 <gmaxwell> aj: my point was just that it's very rare that existing bitcoin users today bother proving to anyone that a key wasn't copied.  "There might be a hidden tapscript" is a similar risk.
02:10:24 <aj> gmaxwell: yep
02:10:26 <gmaxwell> Sipa's point is that its better to do it by default because its essentially free, and in the rare case you do want that proof you can generate it
02:10:49 <gmaxwell> vs if you thought you wouldn't need to prove it, but then later did, you won't be able to.
02:12:01 <sipa> One specific example where it is actually dangerous, and not just a "you can't prove" is when you're doing naive key aggregation (just summing up pubkeys), even together with certified keys (which without taproot would be secure), there is now a combined taproot+aggregation rogue key attack where one party offset his key by exactly as much as necessary to later steal the funds using a script
02:12:05 <sipa> that just includes the attacker
02:12:36 <sipa> But that still involves multiple parties.
02:13:46 <gmaxwell> oh thats a nice attack-- he could even prove knowledge of the discrete log.
02:16:31 <Tibo> So I think I'm a bit confused with this proof thing. If I understand (and I feel like I don't) the proof would be to show someone that you have P such that Q = P + hash(P) * G. But couldn't P itself be an already tweaked key?
02:16:52 <sipa> Tibo: it certainly could be, but that doesn't matter
02:17:29 <Tibo> Ah yeah because you couldn't spend it anyway?
02:17:36 <sipa> The taproot consensus spending rules do not let you take advantage of P being tweaked somehow (you can only do the "hey! look! Q is not actually a pubkey, but it commits to a script!" thing once)
02:17:38 <gmaxwell> Tibo: that taproot construction itself isn't recursive, there can be exactly one top level tweak.
02:18:00 <Tibo> Yes I see thanks
02:18:35 <gmaxwell> Tibo: also if you have some fancy key generation scheme you should be _always_ able to do that final tweak as essentially a post processing step.
02:19:02 <gmaxwell> Then either have one of your signers increment his private key by hash(P), or add an addition dummy signer with private key hash(P).
02:20:01 <aj> Tibo: the two-level tweaking thing might be something coloured coins end up using https://github.com/rgb-org/spec/issues/61
02:21:12 <Tibo> gmaxwell thanks
02:21:16 <Tibo> @aj
02:21:27 <gmaxwell> aj: for a number of years Blockstream's liquid has used a tweaked key to commit to the outputs that should get paid on the sidechain. So yeah there are other applications that might be tweaking P for other reasons.
02:21:53 <Tibo> aj thanks for the link will check that (heard about rgb but didn't look into it that much yet)
02:22:06 <arik_> even with a non-recursive construction though, I struggle to see how just for the top-level key it's possible to prove that it is _not_ tweaked. If it is tweaked, I know the resulting private key and can always only disclose that one.
02:22:54 <arik_> but I also agree it shouldn't really be anyone else's business
02:24:06 <sipa> arik_: you can't prove it's not tweaked
02:24:19 <sipa> unless it's generated in some other way that is in conflict with tweaking
02:24:28 <sipa> and the best way to do that... is to tweak it :)
02:24:44 <arik_> I could tweak it by an OP_RETURN and reveal that
02:25:20 <gmaxwell> arik_: Or tweak it with the key itself, then your forgery challenge turns into a loop, and forging it requires finding a collision to the hash function.
02:25:31 <arik_> yes, that's better
02:25:40 <arik_> because I was gonna say that I can always tweak it twice, and choose which tweak to reveal
02:25:57 <gmaxwell> arik_: thats why the 'tweaking' process includes the pubkey in the hash.
02:26:18 <arik_> oops
02:26:20 <gmaxwell> So you can't do something like pick two scripts, add them, and then choose which to reveal.
02:26:42 <gmaxwell> FWIW, the earliest descriptions of 'pay to contract' had that vulnerablity.
02:26:48 <aj> arik_: (tweaking it twice, and being able to reveal either the left or the right path is kind of what g'root does :)
02:29:26 <sipa> kind of, but let's not go into that
02:31:19 <gmaxwell> It would be useful someplace (probably not in the BIPs) to enumerate out all the effective limits on taproot/tapscript, including ones inherited from other parts of the protocol... and indicate which are standardness vs consensus.
02:31:37 <gmaxwell> As I was ignorantly thinking the maximum stack element limit didn't apply anymore last night.
02:31:53 <sipa> gmaxwell: that one is even explicitly spelled out in the bip, i just forgot about it :)
02:32:02 <gmaxwell> (and a lot of limits don't apply anymore)
02:32:18 <gmaxwell> The reason for that one is stuff like quadratic OP_ROLL cost?
02:33:44 <sipa> yeah
02:34:09 <gmaxwell> Makes sense.
02:34:22 <sipa> and there are certainly ways to avoid the quadratic cost, but they're nontrivial and can have high constant factors
02:36:47 <sipa> (an OP_SUCCESS could lift that limit, btw)
02:38:05 <aj> one thing that was briefly discussed on slack was security proofs for taproot; do we know of flaws in apoelstra's paper, or what other properties might be worth proving?
02:38:57 <andytoshi> i believe my paper is correct but there is disagreement on whether the security model makes sense
02:39:45 <andytoshi> specifically i claim that you can't spend a taproot output without signing with the key, or revealing the originally-embedded script and signing with that
02:40:03 <andytoshi> but real_or_random had some argument that this didn't cover something
02:40:16 <andytoshi> that i didn't fully grok
02:41:26 <sipa> the attacker gets to know the script, right?
02:41:53 <andytoshi> oh, right, in my proof this is the case
02:41:59 <andytoshi> i don't address privacy at all, in any form
02:42:12 <andytoshi> which is one problem with it
02:42:21 <sipa> i think one thing real_or_random pointed out is for example: what if the private key of the internal key is embedded in cleartext in the script?
02:42:59 <andytoshi> oh right! i implicitly assume this is not the case
02:43:00 <sipa> which isn't interesting, but by modelling the script as an abstract thing you can't consider cases like that
02:43:03 <andytoshi> yep
02:43:42 <sipa> a more concrete abstraction that's probably much closer to what we want is something where you model script as a set of conjunctions of public keys
02:44:45 <sipa> and give the attacker an oracle that can sign for whatever (key path, or any of the "scripts" involved), and he wins if he can produce a signature for a key/script he didn't ask the oracle for
02:45:16 <andytoshi> i don't really like this, it fails to capture any nontrivial use of script
02:45:35 <sipa> i agree - it's not complete
02:45:43 <andytoshi> you could extend it to cover hash preimages and timelocks, a la miniscript, then as soon as you use OP_ROLL the security proof doesn't apply
02:46:02 <sipa> but it does capture things like: what if the internal key gets reused inside one of the scripts?
02:46:05 <gmaxwell> this seems way too application specific.
02:46:30 <gmaxwell> It's not like we expect to have a security proof for the hashtree that says it's kosher with timelocks. :P
02:46:57 <andytoshi> well, there's an intuition that you can't reveal the wrong script, or spend without satisfying the script or producing a signature
02:47:00 <aj> 14m left; do feel free to interrupt with questions if you still have them
02:47:01 <andytoshi> that would be worthwhile to capture formally
02:47:44 <gmaxwell> I think a proof should just attack taproot as a computationally sound commitment scheme, like you might prove the security of a pedersen commitment.
02:47:59 <sipa> gmaxwell: andytoshi has that
02:48:02 <andytoshi> for that, my proof is sufficient
02:48:12 <andytoshi> though it's pretty noisy because it tries to do more
02:48:18 <sipa> but i think that's a fairly low-level property
02:48:31 <arik_> Andrew, would you mind sharing a link to your paper in the chat?
02:48:45 <arik_> thanks!
02:48:59 <aj> arik_: https://github.com/apoelstra/taproot
02:49:01 <gmaxwell> it's unclear to me that you can achieve a higher level without rapidly running into absurdity like "op_roll invalidates the proof".
02:49:08 <arik_> thanks, aj!
02:50:06 <aj> sanket shared a pdf he'd written up of some security properties to prove on slack; but it was a raw pdf not a link
02:50:46 <sipa> another interesting property is showing that if the internal key is random, a taproot output is indistinguishable from any other
02:51:00 <sipa> (i don't think anyone doubts that's the case, but a proof would still be nice)
02:51:46 <gmaxwell> that should be trivial to proof, almost a definition, of H() is a random oracle.
02:51:53 <gmaxwell> s/of/if/
02:51:57 <sipa> yes.
02:54:21 <gmaxwell> like P is a uniform point from group of size N. t=H(P||whatever) is a uniform scalar of size N (by defintion of random oracle). tG is a uniform point (bijection).  Q+tG is a uniform point (addition is complete). or something along those lines.
02:56:08 <arik_> yeah, I imagine as long as the field and group orders are mentioned it's trivial
02:57:19 <arik_> pardon my ignorance, but have we had previous proofs of security for proposals of a similar scope, like for p2sh or segwit?
02:57:26 <sipa> nope.
02:57:33 <sipa> nor script.
02:58:08 <andytoshi> i think with segwit the only property that needed proving was that everything was committed to
02:58:32 <gmaxwell> andytoshi: no, that there weren't 'hash emulation' would have been useful to prove.
02:58:59 <gmaxwell> e.g. that post stripping that two different messages couldnt have the same inputs to the hash, unless the messages differed only in the intended ways.
02:59:20 <andytoshi> ah. yes.
02:59:23 <gmaxwell> hm I guess thats what you meant.
02:59:28 <andytoshi> technically yes
02:59:31 <andytoshi> but morally no
02:59:35 <andytoshi> i meant something dumber :P
03:00:05 <andytoshi> along the lines of "moving data from one part of the tree to another doesn't remove it from the tree"
03:00:50 <aj> okay, that's the hour!
03:00:54 <aj> #endmeeting