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