--- Day changed Wed Nov 06 2019 00:00 -!- eltneg [uid401571@gateway/web/irccloud.com/x-mdajomqhnnnnwsbk] has quit [Quit: Connection closed for inactivity] 00:29 -!- xoyi- [~xoyi-@185.6.78.109] has quit [Quit: leaving] 00:31 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has quit [Remote host closed the connection] 00:36 <@aj> sipa: what's with the swap/if/endif for 4-of-10k ? just use CSA directly for that? 00:45 < digi_james> Hmm. Wondering what the witness stack size limit is? Straight-up CSA would require 10k-4 wit stack elements for all the 0's? 00:48 < digi_james> If I understand correctly, in sipa's example the 0's are in the tapscript, which is one wit element. 00:49 < gmaxwell> aj: Probably because I needlessly primed him with mention of IF-gating. 00:52 < digi_james> gmaxwell: There are no witness stack length limits, right? 00:52 < digi_james> I mean, nr of elements in wit stack. 00:59 -!- b10c [~Thunderbi@i577BC684.versanet.de] has joined ##taproot-bip-review 01:00 < gmaxwell> Just that implied by the maximum transaction size. 01:02 < digi_james> Thank you 01:02 < gmaxwell> One of the ideas behind taproot is that it makes vastly more expensive scripts reasonable to use-- because mostly you use a cooperative resolution, and the complex script just exists as a threat. 01:02 < gmaxwell> So thats a good reason to be pretty permissive with limits. Limits also greatly complicate automated script generation, composition, etc. 01:05 <@aj> digi_james, gmaxwell: the witness stack has a 1000 element limit including during execution 01:05 <@aj> (see script/script.h MAX_STACK_SIZE) 01:10 < digi_james> aj: Oh thx, whereas witness element can be <= 10k I recall. So it seems one would have push the null's required for csa to the tapscript. 01:10 < digi_james> Sorry, 10kB 01:23 <@aj> digi_james: for segwit v0 the script can be 10k in length; the witness data then fulfils that. taproot drops that limit 01:24 <@aj> digi_james: there's limits on how big each element on the stack can be, see MAX_SCRIPT_ELEMENT_SIZE eg 01:28 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 264 seconds] 01:39 < digi_james> aj: I am thinking through our (4-of-largeN) CSA example again: So our (CSA) tapscript occupies just one witness element, right? If its satisfaction requires 10k witness elements (mostly nulls), we hit MAX_STACK_SIZE upon execution, because these are pushed on the script stack at once before tapscript evaluation. If we use the (if gated) modified CSA tapscript, only 4 satisfying witness elements are 01:39 < digi_james> pushed to the stack before modified CSA is run, and no limits are hit, is this correct? 01:44 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined ##taproot-bip-review 01:57 <@aj> digi_james: see https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki "Stack + altstack element count limit" -- you'd be limited to 996 empty signatures and 4 valid signatures on the stack 02:01 < digi_james> aj: Thanks. So we have a workaround for that limit now :) 02:01 <@aj> digi_james: i think something like DEPTH {2k+1} EQUALVERIFY { IFDUP NOTIF

CHECKSIGVERIFY ENDIF 1SUB }*n DEPTH 0 EQUAL 02:02 <@aj> digi_james: would let you have a witness stack of {number of keys to skip, valid signature}*k + {nuber of keys to get to the end} to get to a k-of-{very large n} multisig 02:12 < digi_james> aj: Oh you mean without CSA? Nice! 02:16 <@aj> oh, maybe there needs to be a OP_DROP before the DEPTH in the above? probably some other tweaks needed to make it actually work too 02:19 < digi_james> I had to look up op_depth :) 02:31 -!- jonatack [~jon@213.152.162.5] has joined ##taproot-bip-review 02:49 < gmaxwell> sounds like a good script for someone to flesh out and test. 02:49 < gmaxwell> (and potentially somewhat useful) 03:05 -!- k7 [~AdminUser@89.245.184.230] has joined ##taproot-bip-review 03:07 -!- k7 [~AdminUser@89.245.184.230] has left ##taproot-bip-review [] 03:07 -!- k7 [~AdminUser@89.245.184.230] has joined ##taproot-bip-review 03:07 -!- k7 [~AdminUser@89.245.184.230] has left ##taproot-bip-review [] 03:21 -!- daniel_____ [~quassel@89.245.184.230] has joined ##taproot-bip-review 03:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 03:53 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in] 03:55 -!- real_or_random [~real_or_r@173.249.7.254] has joined ##taproot-bip-review 04:20 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has joined ##taproot-bip-review 04:20 -!- pyskell [~meh@unaffiliated/pyskell] has quit [Quit: Leaving] 04:45 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined ##taproot-bip-review 04:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 04:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 05:07 -!- jonatack [~jon@213.152.162.5] has quit [Ping timeout: 240 seconds] 05:19 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:c02e:159f:60aa:956c] has joined ##taproot-bip-review 05:33 -!- HighOnBtc [~Admin@193.226.30.216] has joined ##taproot-bip-review 05:51 -!- lightlike [~lightlike@2001:16b8:577c:d900:11d3:b4a1:4c35:e2b8] has joined ##taproot-bip-review 05:56 -!- HighOnBtc [~Admin@193.226.30.216] has quit [Ping timeout: 250 seconds] 06:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 06:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 06:27 < instagibbs> warning, OP_DEPTH isn't in miniscript :P 06:27 < instagibbs> IIRC 06:29 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review 06:36 -!- pinheadmz [~matthewzi@185.217.69.139] has joined ##taproot-bip-review 06:49 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review 07:15 <@aj> OP_DEPTH doesn't compose so isn't miniscript friendly 07:38 -!- HighOnBtc [~Admin@46.97.169.99] has joined ##taproot-bip-review 07:49 -!- soju [~soju@2601:640:8780:6d90:eca0:7eb0:4e45:8ac7] has joined ##taproot-bip-review 07:53 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review 07:54 -!- HighOnBtc [~Admin@46.97.169.99] has quit [Read error: Connection reset by peer] 08:10 -!- pinheadmz [~matthewzi@185.217.69.139] has quit [Quit: pinheadmz] 08:39 -!- michaelfolkson [~textual@62.60.63.228] has joined ##taproot-bip-review 09:06 -!- soju [~soju@2601:640:8780:6d90:eca0:7eb0:4e45:8ac7] has quit [Remote host closed the connection] 09:20 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-bip-review 09:30 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: My computer has gone to sleep.] 09:37 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined ##taproot-bip-review 10:02 < gmaxwell> miniscript has a lot of limitations, so that isn't a surprise. 10:03 < gmaxwell> though I think this example has the largest spending weight difference I've seen yet for an optimized script vs what miniscript could make. (for thing which miniscript could model) 10:06 -!- orfeas [81d75b21@dhcp-91-033.inf.ed.ac.uk] has quit [Remote host closed the connection] 10:11 -!- michaelfolkson [~textual@62.60.63.228] has quit [Quit: Sleep mode] 10:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-bip-review 10:30 -!- michaelfolkson [~textual@85.255.235.91] has joined ##taproot-bip-review 10:34 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: My computer has gone to sleep.] 10:39 -!- pinheadmz [~matthewzi@239-196.icannmeeting.org] has joined ##taproot-bip-review 10:48 -!- pyskell [~pyskell@unaffiliated/pyskell] has quit [Quit: Leaving] 11:20 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined ##taproot-bip-review 11:21 -!- b10c [~Thunderbi@i577BC684.versanet.de] has quit [Ping timeout: 240 seconds] 11:28 < sipa> aj: a more composable/depthless version would be: 11:30 < sipa> 0 (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE CHECKSIGADD ENDIF)* 4 EQUAL 11:31 < sipa> aj: i think you need 0NOTEQUAL somewhere as well due to minimalif rule 11:35 < sipa> the (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE CHECKSIGADD ENDIF) sequence turns a stack ending with [sig,c>0,n] into [sig,c,n], and a stack ending in [sig,0,n] into [n+(sig valid)] 11:39 < sipa> actually, this does not work, as it doesn't guarantee exactly 8 elements were popped off the stack 11:41 < sipa> you'd need something (SWAP IFDUP 0NOTEQUAL IF SUB1 SWAP ELSE SWAP CHECKSIGVERIFY ADD1 ENDIF)* 4 EQUALVERIFY 11:42 < sipa> there must be a way to avoid 3 SWAPs 11:48 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: My computer has gone to sleep.] 11:53 < gmaxwell> stuff like that makes me wish every opcode had two bits for 'swap' and 'dup' embedded in them, and great sympathy for CISC cpu designers. 11:54 < sipa> and a conditional execution bit, and control register? :) 11:55 < sipa> having a separate explicit input stack and temporary variables stack would also do wonders 12:58 -!- michaelfolkson [~textual@85.255.235.91] has quit [Quit: Sleep mode] 13:18 < Chris_Stewart_5> Has anyone committed to updating the hard coded test vectors found here? https://github.com/sipa/bitcoin/tree/taproot/src/test/data 13:19 < Chris_Stewart_5> It's useful for library developers 13:19 < Chris_Stewart_5> sighash.json 6 years :$ 13:20 < pinheadmz> sipa: https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki#transaction-digest says key_value is 0x00 but in the code I see 0x02 13:20 < pinheadmz> https://github.com/sipa/bitcoin/blob/527ed7d4b230a694ee223a000cd5fd7495a00fcb/src/script/interpreter.cpp#L1447 13:20 < pinheadmz> s/key_value/key_version 13:20 < sipa> pinheadmz: fix it! 13:21 < pinheadmz> :+1: 13:22 < pinheadmz> any rationale for 2 instead of 0? 13:23 < sipa> yes, because it used to be equal to the first byte of the pubkey (ignoring the sign bit) 13:23 < pinheadmz> ah 13:23 < sipa> 0 makes most sense now 13:24 < pinheadmz> oh wait haha, "fix it!" -- the BIP or the code? 13:24 < pinheadmz> sounds like change the code to 0 in both those places i linked? 13:26 < sipa> yes, the bip was updated from 2 to 0 when xonly was introduced 13:26 < sipa> but the code wasn't 13:26 < pinheadmz> ok 13:26 < sipa> i'll do it in my next rebase 13:26 < pinheadmz> ok! cheers 14:14 -!- HighOnBtc [~Admin@86.121.55.235] has joined ##taproot-bip-review 14:24 -!- pinheadmz [~matthewzi@239-196.icannmeeting.org] has quit [Quit: pinheadmz] 14:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 14:50 < maaku> gmaxwell: have you seen the J1 forth CPU? it has those sorts of bits embedded in its opcode decoding 14:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 15:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 15:19 -!- soju [~soju@2601:640:8780:6d90:eca0:7eb0:4e45:8ac7] has joined ##taproot-bip-review 15:53 -!- michaelfolkson [~textual@85.255.235.32] has joined ##taproot-bip-review 15:56 -!- michaelfolkson [~textual@85.255.235.32] has quit [Client Quit] 16:34 -!- pyskell [~meh@unaffiliated/pyskell] has joined ##taproot-bip-review 16:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 16:45 -!- soju [~soju@2601:640:8780:6d90:eca0:7eb0:4e45:8ac7] has quit [Remote host closed the connection] 16:50 -!- michaelfolkson [~textual@85.255.235.32] has joined ##taproot-bip-review 16:59 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-fcecgerlfuepmuvv] has joined ##taproot-bip-review 16:59 -!- evoskuil [~evoskuil@c-67-161-88-73.hsd1.wa.comcast.net] has joined ##taproot-bip-review 17:01 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 17:05 -!- pinheadmz [~matthewzi@5.181.233.92] has joined ##taproot-bip-review 17:33 <@moneyball> Reminder of upcoming Q&A session in 30 minutes 17:51 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has joined ##taproot-bip-review 17:57 -!- soju [uid403160@gateway/web/irccloud.com/x-xbxryqnnquoemlev] has joined ##taproot-bip-review 17:59 <@aj> dammit, missed the 30 second reminder 17:59 < sipa> by 19 seconds 18:00 <@moneyball> whoops 18:00 <@aj> #startmeeting 18:00 < lightningbot> Meeting started Thu Nov 7 02:00:12 2019 UTC. The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has left ##taproot-bip-review [] 18:00 -!- fanquake [sid369002@gateway/web/irccloud.com/x-wldabmtwklcqgksi] has joined ##taproot-bip-review 18:00 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined ##taproot-bip-review 18:00 <@aj> hi round 2 folks! 18:00 < andytoshi> hiya 18:00 <@moneyball> hi 18:01 < Tibo> hi 18:01 < fanquake> hi 18:01 < sipa> hi 18:01 < soju> hi 18:01 < gmaxwell> I was gonna ping everyone in the room but there are a lot of people here. 18:01 < 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 18:02 < gmaxwell> I move to approve the minutes of the last meeting. All in favor? 18:02 <@moneyball> aye 18:02 < gmaxwell> Motion carries. 18:02 < sipa> All 60 minutes? 18:02 <@moneyball> We have a bunch of experts here on Taproot so please ask any questions you might have 18:04 < gmaxwell> Especialy all those questions which you were too embarassed to ask in front of the europeans. 18:04 < sipa> I'll be here the whole hour, so if anything comes up, feel free to ask any time. 18:05 < 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) 18:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 18:05 < sipa> Tibo: that's a good question 18:05 < sipa> there are many situations in which it's perfectly fine to just use a public key directly as an output point. 18:05 < andytoshi> my feeling is that it's a "should" ... there are many cases where it's safe not to do this 18:06 < andytoshi> in particular if there is only one party 18:06 < andytoshi> or if all parties are using musig and checking the derivation 18:06 < 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. 18:06 < Tibo> ok thanks for clarifying! 18:07 < 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... 18:07 < 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. 18:08 < andytoshi> i think having the ability to prove this is useful ... i mean, it's harmless to -have- the ability 18:08 <@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 18:08 < sipa> I think it's fair to say that it's always fine to use a pubkey directly when there is only one signer. 18:08 < andytoshi> oh very good point aj 18:08 < gmaxwell> aj: right. 18:09 < Tibo> I see interesting. 18:09 < 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. 18:10 <@aj> gmaxwell: yep 18:10 < 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 18:10 < gmaxwell> vs if you thought you wouldn't need to prove it, but then later did, you won't be able to. 18:12 < 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 18:12 < sipa> that just includes the attacker 18:12 < sipa> But that still involves multiple parties. 18:13 < gmaxwell> oh thats a nice attack-- he could even prove knowledge of the discrete log. 18:16 < 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? 18:16 < sipa> Tibo: it certainly could be, but that doesn't matter 18:17 < Tibo> Ah yeah because you couldn't spend it anyway? 18:17 < 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) 18:17 < gmaxwell> Tibo: that taproot construction itself isn't recursive, there can be exactly one top level tweak. 18:18 < Tibo> Yes I see thanks 18:18 < 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. 18:19 < 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). 18:20 <@aj> Tibo: the two-level tweaking thing might be something coloured coins end up using https://github.com/rgb-org/spec/issues/61 18:21 < Tibo> gmaxwell thanks 18:21 < Tibo> @aj 18:21 < 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. 18:21 < Tibo> aj thanks for the link will check that (heard about rgb but didn't look into it that much yet) 18:22 < 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. 18:22 < arik_> but I also agree it shouldn't really be anyone else's business 18:24 < sipa> arik_: you can't prove it's not tweaked 18:24 < sipa> unless it's generated in some other way that is in conflict with tweaking 18:24 < sipa> and the best way to do that... is to tweak it :) 18:24 < arik_> I could tweak it by an OP_RETURN and reveal that 18:24 -!- ZmnSCPxj [~ZmnSCPxj@180.190.33.157] has joined ##taproot-bip-review 18:25 < 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. 18:25 < arik_> yes, that's better 18:25 < arik_> because I was gonna say that I can always tweak it twice, and choose which tweak to reveal 18:25 -!- michaelfolkson [~textual@85.255.235.32] has quit [Quit: Sleep mode] 18:25 < gmaxwell> arik_: thats why the 'tweaking' process includes the pubkey in the hash. 18:26 < arik_> oops 18:26 < gmaxwell> So you can't do something like pick two scripts, add them, and then choose which to reveal. 18:26 < gmaxwell> FWIW, the earliest descriptions of 'pay to contract' had that vulnerablity. 18:26 <@aj> arik_: (tweaking it twice, and being able to reveal either the left or the right path is kind of what g'root does :) 18:29 -!- lightlike [~lightlike@2001:16b8:577c:d900:11d3:b4a1:4c35:e2b8] has quit [Quit: Leaving] 18:29 < sipa> kind of, but let's not go into that 18:31 < 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. 18:31 < gmaxwell> As I was ignorantly thinking the maximum stack element limit didn't apply anymore last night. 18:31 -!- nick_fre_ [~nick_free@2001:16b8:30c6:da00:e0d6:1aa:ba59:3a79] has joined ##taproot-bip-review 18:31 < sipa> gmaxwell: that one is even explicitly spelled out in the bip, i just forgot about it :) 18:32 < gmaxwell> (and a lot of limits don't apply anymore) 18:32 < gmaxwell> The reason for that one is stuff like quadratic OP_ROLL cost? 18:33 -!- isho [47cae496@c-71-202-228-150.hsd1.ca.comcast.net] has joined ##taproot-bip-review 18:33 < sipa> yeah 18:34 < gmaxwell> Makes sense. 18:34 < sipa> and there are certainly ways to avoid the quadratic cost, but they're nontrivial and can have high constant factors 18:34 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:c02e:159f:60aa:956c] has quit [Ping timeout: 245 seconds] 18:36 < sipa> (an OP_SUCCESS could lift that limit, btw) 18:38 <@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? 18:38 < andytoshi> i believe my paper is correct but there is disagreement on whether the security model makes sense 18:39 < 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 18:40 < andytoshi> but real_or_random had some argument that this didn't cover something 18:40 < andytoshi> that i didn't fully grok 18:41 < sipa> the attacker gets to know the script, right? 18:41 < andytoshi> oh, right, in my proof this is the case 18:41 < andytoshi> i don't address privacy at all, in any form 18:42 < andytoshi> which is one problem with it 18:42 < 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? 18:42 < andytoshi> oh right! i implicitly assume this is not the case 18:43 < sipa> which isn't interesting, but by modelling the script as an abstract thing you can't consider cases like that 18:43 < andytoshi> yep 18:43 < 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 18:44 < 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 18:45 < andytoshi> i don't really like this, it fails to capture any nontrivial use of script 18:45 < sipa> i agree - it's not complete 18:45 < 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 18:46 < sipa> but it does capture things like: what if the internal key gets reused inside one of the scripts? 18:46 < gmaxwell> this seems way too application specific. 18:46 < gmaxwell> It's not like we expect to have a security proof for the hashtree that says it's kosher with timelocks. :P 18:46 < andytoshi> well, there's an intuition that you can't reveal the wrong script, or spend without satisfying the script or producing a signature 18:47 <@aj> 14m left; do feel free to interrupt with questions if you still have them 18:47 < andytoshi> that would be worthwhile to capture formally 18:47 < 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. 18:47 < sipa> gmaxwell: andytoshi has that 18:48 < andytoshi> for that, my proof is sufficient 18:48 < andytoshi> though it's pretty noisy because it tries to do more 18:48 < sipa> but i think that's a fairly low-level property 18:48 < arik_> Andrew, would you mind sharing a link to your paper in the chat? 18:48 < arik_> thanks! 18:48 <@aj> arik_: https://github.com/apoelstra/taproot 18:49 < gmaxwell> it's unclear to me that you can achieve a higher level without rapidly running into absurdity like "op_roll invalidates the proof". 18:49 < arik_> thanks, aj! 18:50 <@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 18:50 < sipa> another interesting property is showing that if the internal key is random, a taproot output is indistinguishable from any other 18:51 < sipa> (i don't think anyone doubts that's the case, but a proof would still be nice) 18:51 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 260 seconds] 18:51 < gmaxwell> that should be trivial to proof, almost a definition, of H() is a random oracle. 18:51 < gmaxwell> s/of/if/ 18:51 < sipa> yes. 18:54 < 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. 18:56 < arik_> yeah, I imagine as long as the field and group orders are mentioned it's trivial 18:57 < arik_> pardon my ignorance, but have we had previous proofs of security for proposals of a similar scope, like for p2sh or segwit? 18:57 < sipa> nope. 18:57 < sipa> nor script. 18:57 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 240 seconds] 18:58 < andytoshi> i think with segwit the only property that needed proving was that everything was committed to 18:58 < gmaxwell> andytoshi: no, that there weren't 'hash emulation' would have been useful to prove. 18:58 < 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. 18:59 < andytoshi> ah. yes. 18:59 < gmaxwell> hm I guess thats what you meant. 18:59 < andytoshi> technically yes 18:59 < andytoshi> but morally no 18:59 < andytoshi> i meant something dumber :P 19:00 < andytoshi> along the lines of "moving data from one part of the tree to another doesn't remove it from the tree" 19:00 <@aj> okay, that's the hour! 19:00 <@aj> #endmeeting 19:00 < lightningbot> Meeting ended Thu Nov 7 03:00:54 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.html 19:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.txt 19:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-07-02.00.log.html 19:07 -!- yas [~yas@bzq-79-181-233-241.red.bezeqint.net] has quit [Ping timeout: 268 seconds] 19:09 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 264 seconds] 19:11 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 19:39 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has left ##taproot-bip-review [] 20:31 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 20:50 -!- isho [47cae496@c-71-202-228-150.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 21:03 -!- soju__ [~soju@2601:640:8780:6d90:8d5f:7c5a:ed4:a0bf] has joined ##taproot-bip-review 21:05 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has joined ##taproot-bip-review 21:07 -!- soju__ [~soju@2601:640:8780:6d90:8d5f:7c5a:ed4:a0bf] has quit [Ping timeout: 245 seconds] 21:14 -!- eltneg [uid401571@gateway/web/irccloud.com/x-cxztiaikocbwtqeu] has joined ##taproot-bip-review 21:29 -!- isho [47cae496@c-71-202-228-150.hsd1.ca.comcast.net] has joined ##taproot-bip-review 21:30 -!- isho [47cae496@c-71-202-228-150.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 22:01 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has quit [Ping timeout: 245 seconds] 22:59 -!- kabaum [~kabaum@185.224.57.161] has joined ##taproot-bip-review 23:04 -!- soju__ [~soju@2601:640:8780:6d90:8d5f:7c5a:ed4:a0bf] has joined ##taproot-bip-review 23:28 -!- evoskuil [~evoskuil@c-67-161-88-73.hsd1.wa.comcast.net] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D] 23:33 -!- eltneg [uid401571@gateway/web/irccloud.com/x-cxztiaikocbwtqeu] has quit [Quit: Connection closed for inactivity] 23:56 -!- soju__ [~soju@2601:640:8780:6d90:8d5f:7c5a:ed4:a0bf] has quit [Remote host closed the connection]