02:00:12 #startmeeting 02:00:12 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 02:00:53 hi round 2 folks! 02:00:57 hiya 02:00:59 hi 02:01:01 hi 02:01:01 hi 02:01:03 hi 02:01:04 hi 02:01:06 I was gonna ping everyone in the room but there are a lot of people here. 02:01:37 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 I move to approve the minutes of the last meeting. All in favor? 02:02:29 aye 02:02:43 Motion carries. 02:02:45 All 60 minutes? 02:02:51 We have a bunch of experts here on Taproot so please ask any questions you might have 02:04:24 Especialy all those questions which you were too embarassed to ask in front of the europeans. 02:04:50 I'll be here the whole hour, so if anything comes up, feel free to ask any time. 02:05:02 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 Tibo: that's a good question 02:05:53 there are many situations in which it's perfectly fine to just use a public key directly as an output point. 02:05:56 my feeling is that it's a "should" ... there are many cases where it's safe not to do this 02:06:11 in particular if there is only one party 02:06:22 or if all parties are using musig and checking the derivation 02:06:53 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 ok thanks for clarifying! 02:07:01 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 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 i think having the ability to prove this is useful ... i mean, it's harmless to -have- the ability 02:08:21 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 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 oh very good point aj 02:08:36 aj: right. 02:09:30 I see interesting. 02:09:32 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 gmaxwell: yep 02:10:26 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 vs if you thought you wouldn't need to prove it, but then later did, you won't be able to. 02:12:01 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 that just includes the attacker 02:12:36 But that still involves multiple parties. 02:13:46 oh thats a nice attack-- he could even prove knowledge of the discrete log. 02:16:31 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 Tibo: it certainly could be, but that doesn't matter 02:17:29 Ah yeah because you couldn't spend it anyway? 02:17:36 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 Tibo: that taproot construction itself isn't recursive, there can be exactly one top level tweak. 02:18:00 Yes I see thanks 02:18:35 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 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 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 gmaxwell thanks 02:21:16 @aj 02:21:27 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 aj thanks for the link will check that (heard about rgb but didn't look into it that much yet) 02:22:06 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 but I also agree it shouldn't really be anyone else's business 02:24:06 arik_: you can't prove it's not tweaked 02:24:19 unless it's generated in some other way that is in conflict with tweaking 02:24:28 and the best way to do that... is to tweak it :) 02:24:44 I could tweak it by an OP_RETURN and reveal that 02:25:20 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 yes, that's better 02:25:40 because I was gonna say that I can always tweak it twice, and choose which tweak to reveal 02:25:57 arik_: thats why the 'tweaking' process includes the pubkey in the hash. 02:26:18 oops 02:26:20 So you can't do something like pick two scripts, add them, and then choose which to reveal. 02:26:42 FWIW, the earliest descriptions of 'pay to contract' had that vulnerablity. 02:26:48 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 kind of, but let's not go into that 02:31:19 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 As I was ignorantly thinking the maximum stack element limit didn't apply anymore last night. 02:31:53 gmaxwell: that one is even explicitly spelled out in the bip, i just forgot about it :) 02:32:02 (and a lot of limits don't apply anymore) 02:32:18 The reason for that one is stuff like quadratic OP_ROLL cost? 02:33:44 yeah 02:34:09 Makes sense. 02:34:22 and there are certainly ways to avoid the quadratic cost, but they're nontrivial and can have high constant factors 02:36:47 (an OP_SUCCESS could lift that limit, btw) 02:38:05 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 i believe my paper is correct but there is disagreement on whether the security model makes sense 02:39:45 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 but real_or_random had some argument that this didn't cover something 02:40:16 that i didn't fully grok 02:41:26 the attacker gets to know the script, right? 02:41:53 oh, right, in my proof this is the case 02:41:59 i don't address privacy at all, in any form 02:42:12 which is one problem with it 02:42:21 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 oh right! i implicitly assume this is not the case 02:43:00 which isn't interesting, but by modelling the script as an abstract thing you can't consider cases like that 02:43:03 yep 02:43:42 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 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 i don't really like this, it fails to capture any nontrivial use of script 02:45:35 i agree - it's not complete 02:45:43 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 but it does capture things like: what if the internal key gets reused inside one of the scripts? 02:46:05 this seems way too application specific. 02:46:30 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 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 14m left; do feel free to interrupt with questions if you still have them 02:47:01 that would be worthwhile to capture formally 02:47:44 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 gmaxwell: andytoshi has that 02:48:02 for that, my proof is sufficient 02:48:12 though it's pretty noisy because it tries to do more 02:48:18 but i think that's a fairly low-level property 02:48:31 Andrew, would you mind sharing a link to your paper in the chat? 02:48:45 thanks! 02:48:59 arik_: https://github.com/apoelstra/taproot 02:49:01 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 thanks, aj! 02:50:06 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 another interesting property is showing that if the internal key is random, a taproot output is indistinguishable from any other 02:51:00 (i don't think anyone doubts that's the case, but a proof would still be nice) 02:51:46 that should be trivial to proof, almost a definition, of H() is a random oracle. 02:51:53 s/of/if/ 02:51:57 yes. 02:54:21 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 yeah, I imagine as long as the field and group orders are mentioned it's trivial 02:57:19 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 nope. 02:57:33 nor script. 02:58:08 i think with segwit the only property that needed proving was that everything was committed to 02:58:32 andytoshi: no, that there weren't 'hash emulation' would have been useful to prove. 02:58:59 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 ah. yes. 02:59:23 hm I guess thats what you meant. 02:59:28 technically yes 02:59:31 but morally no 02:59:35 i meant something dumber :P 03:00:05 along the lines of "moving data from one part of the tree to another doesn't remove it from the tree" 03:00:50 okay, that's the hour! 03:00:54 #endmeeting