12020-06-22T01:16:46 *** belcher has quit IRC
22020-06-22T02:02:49 *** achow101 has quit IRC
32020-06-22T02:09:33 *** achow101 has joined ##taproot-bip-review
42020-06-22T03:04:50 *** achow101 has quit IRC
52020-06-22T03:05:24 *** achow101 has joined ##taproot-bip-review
62020-06-22T03:47:31 *** achow101 has quit IRC
72020-06-22T03:47:50 *** achow101 has joined ##taproot-bip-review
82020-06-22T04:11:27 *** achow101_ has joined ##taproot-bip-review
92020-06-22T04:12:32 *** achow101_ has quit IRC
102020-06-22T04:54:23 *** achow101 has quit IRC
112020-06-22T04:54:43 *** achow101 has joined ##taproot-bip-review
122020-06-22T05:00:21 *** achow101 has quit IRC
132020-06-22T05:00:38 *** achow101 has joined ##taproot-bip-review
142020-06-22T05:20:42 *** achow101 has quit IRC
152020-06-22T05:20:59 *** achow101 has joined ##taproot-bip-review
162020-06-22T06:13:55 *** dr-orlovsky has joined ##taproot-bip-review
172020-06-22T06:21:38 *** achow101 has quit IRC
182020-06-22T06:22:16 *** achow101 has joined ##taproot-bip-review
192020-06-22T07:48:52 *** dr-orlovsky has quit IRC
202020-06-22T07:52:37 *** dr-orlovsky has joined ##taproot-bip-review
212020-06-22T07:56:47 *** jonatack has quit IRC
222020-06-22T08:59:30 *** jonatack has joined ##taproot-bip-review
232020-06-22T09:17:48 *** belcher has joined ##taproot-bip-review
242020-06-22T10:14:39 <alec> when tweaking a public key with t, is t added to the x- and y-coordinates?
252020-06-22T11:17:22 *** dr-orlovsky has quit IRC
262020-06-22T11:55:34 *** jonatack has quit IRC
272020-06-22T12:54:32 *** luke-jr has quit IRC
282020-06-22T12:57:49 *** luke-jr has joined ##taproot-bip-review
292020-06-22T13:01:46 <ghost43> alec: grep bip341 for "def taproot_tweak_pubkey"
302020-06-22T13:02:41 <ghost43> P + t1*G, where t1 is some hash that involves both t and P
312020-06-22T14:14:34 <alec> right, found it, thanks
322020-06-22T14:15:57 *** dr-orlovsky has joined ##taproot-bip-review
332020-06-22T14:17:05 <alec> t = int_from_bytes(tagged_hash("TapTweak", pubkey + h))
342020-06-22T14:17:20 <alec> I guess pubkey here is the compressed pubkey consisting only of the x-coordinate
352020-06-22T14:17:58 <alec> or is it a point, then it becomes pubkey.x=h, pubkey.y+h?
362020-06-22T14:21:48 <alec> well, must be scalar since tagged_hash's second argument is expected to be bytes
372020-06-22T14:26:53 <alec> so my previous question should have been answered with no. the private key tweak is H(P,S), not H(P,S)G as for the public key. right?
382020-06-22T14:29:41 <aj> a private key tweak of "q" always corresponds to a public key tweak of "q*G"
392020-06-22T14:32:21 <alec> that makes sense
402020-06-22T14:34:56 <alec> one more question. I've written down verification for a tweaked key sG = R+H(RâQâm)Q. i inserted the signature R,s which yields (k+H(RâQâm)q)G = kG+H(RâQâm)Q. then I substitute Q for qG and get (k+H(RâQâm)q)G = kG+H(RâQâm)qG, at which point I divide by G and everything works out
412020-06-22T14:35:34 <alec> I'm somehow missing the part where the additivity property comes into play. can you tell me where that is?
422020-06-22T14:41:25 <aj> you "can't" divide by G -- that would be solving the discrete log; i think the addititive property you're thinking of is distributitvity which lets you say (k+Hq)*G = kG + (Hq)*G = kG + H*(qG) = kG + H*Q? alternatively, it's that with a tweaked key, Q=P+t*G, you can calculate a partial-signature with P, s = r + H(r*G, P+tG, m)*p, then can convert s,R*G into a signature for the tweaked key Q by
432020-06-22T14:41:26 <aj> adding H(R,P+tG,m)*t to s ?
442020-06-22T14:43:50 <alec> aj: I'm still missing something. s is a random number. I'm adding another number to it. so it becomes another random number, q. I can then create a public key from this number using Q=qP
452020-06-22T14:46:15 <aj> Q=q*G usually
462020-06-22T14:46:16 <alec> from there it looks like normal Schnorr verification. I'm missing where I need P+tG=(p+t)G
472020-06-22T14:46:31 <alec> aj: sorry, I meant qG
482020-06-22T14:47:07 <aj> If you take a partial signature, using privkey p, s = r + H(r*G, P+t*G, m)p
492020-06-22T14:47:31 <aj> and then add H(r*G, P+t*G, m)t (same hash, multiplied by the tweak as a scalar)
502020-06-22T14:47:41 <aj> call that x
512020-06-22T14:48:08 <aj> you get s+x = r + H(r*G, P+t*G, m)p + x = r + H(r*G, P+t*G, m)(p+t)
522020-06-22T14:48:20 <aj> multiply both by G, to turn into points
532020-06-22T14:48:49 <aj> you get (s+x)*G = r*G + H(R, Q, m)*Q where Q=P+t*G
542020-06-22T14:49:06 <aj> which gets you back to a normal schnorr sig s+x, R with pubkey Q on message m
552020-06-22T14:49:43 <alec> aj: thanks for the information! I'll try to work through it
562020-06-22T14:50:57 <aj> it's kind of angel's on pinheads -- you could just as easily calculate the private key q = p+t and sign with it directly, with no weird additions needed
572020-06-22T14:51:30 <aj> the above just lets you sign something slightly weird with the original private key p, and still get a useful result. that becomes more interesting when the signer doesn't know the tweak t, which then gets into multisignature stuff like muSig
582020-06-22T14:52:26 <alec> oh ok. so the key path spend of a P2TR does not need Schnorr's additivity property?
592020-06-22T14:52:49 <alec> if I sign with q=p+t, that is
602020-06-22T14:53:29 <aj> it's a mathematical property, it's there whether you need it or not... it's like saying "i don't need to know 2 = 1+1 when i multiply 2 by 3 to get 6"
612020-06-22T14:54:23 <alec> ok, let's rephrase that to "does not take advantage of its additivity propety"
622020-06-22T14:54:38 <aj> verifying the key path certainly doesn't need it -- you don't know what things to add unless you're the signer or verifying via script path
632020-06-22T14:55:12 <alec> aj: thanks, that answers my question
642020-06-22T14:56:10 *** raj_149 is now known as raj_
652020-06-22T14:58:43 <alec> as to the script path: the additivity propery is not required, either, right?
662020-06-22T14:59:45 <alec> you just make sure tweaked public key according to the data provided matches Q from the script_pubkey, right?
672020-06-22T15:00:18 <aj> nodes verify that the script you present, s and the internal key P match the public key Q by calculating Q = P + H(P, s)*G (that's the code you pasted above)
682020-06-22T15:02:04 <aj> i'm not sure what additive property you're talking about here. Q = qG = (p+t)G = P+tG only matters if you know the secret key, which verifiers don't, or maybe if you're doing security proof with maths?
692020-06-22T15:02:09 <alec> ok, I got that so far
702020-06-22T15:04:06 <alec> aj: yes, by additive I refer to f(x)+f(y)=f(x+y). I understood it is necessary for taproot, so I'm trying to find where it is used
712020-06-22T15:04:43 <alec> with ECDSA, I could take a random private key p, add some value to it, multiply it with G, and get a Q, too, right?
722020-06-22T15:05:18 <aj> it's used in signing then, to calculate s,R where sG=R+H(R,Q,m)*Q you have to know that Q=P+tG means q=p+t gives Q=q*G
732020-06-22T15:05:24 <alec> if I sign with q=p+t, I could spend funds locked with Q, too.
742020-06-22T15:07:13 <aj> yeah, you can do that part with ecdsa too. the part that you can't do is multisignatures, where you can generate a signate s,R corresponding with a public key A+B where Alice knows a, A=a*G and Bob knows b, B=b*G but they never share a,b with each other
752020-06-22T15:08:06 <alec> aj: okay, now I know I'm not crazy
762020-06-22T15:08:11 <aj> so if you did taproot with ecdsa, the key path would be "alice can spend this" or "bob can spend this" or "the key path is unusable by anyone"; schnorr gives you a "2-of-2 key path"
772020-06-22T15:08:50 <alec> so what I was trying to figure out was where exactly in key path and script path the "linearity property" or additive property of schnorr was exploited to do something that's not possible with ECDSA. and I couldn't find it
782020-06-22T15:09:10 <aj> so if your script was "2-of-3 alice, bob or carol" you can make the key path by "alice and bob" and still have it be equally secure (alice and bob combined but without carol is one of the 2-of-3!) and stil have the key path be short
792020-06-22T15:09:40 <alec> yeah, I know that P_alice_and_bob=P_alice+P_bob only works with schnorr, not ECDSA
802020-06-22T15:10:09 <alec> aj: one final question, then I'll be out of your hair. thanks so far, anyway!
812020-06-22T15:11:07 <aj> so the maths *there* is H = H(R1+R2, A+B, m) . s1 = r1 + H*a, s2 = r2 + H*b, s = s1+s2, R = R1+R2, and all you need is Alice to calculate s1,R1 and Bob to calculate s2,R2 and then add them up
822020-06-22T15:11:09 <alec> in script path, how is theft of funds by substituting output's script_pubkeys in unconfirmed transactions addressed?
832020-06-22T15:11:54 <aj> "substituting output's script pubkeys" ? the ones in the script, or the scriptPubKey from the utxo?
842020-06-22T15:11:56 <alec> I see verification involves checking the inputs against the script, and making sure that Q=P+H(P,S)G. but there's no message signature, righht
852020-06-22T15:12:21 <alec> the one's in the outputs that spend the inputs that unlock a P2TR using script path
862020-06-22T15:12:48 <aj> so you have a UTXO that has a taproot scriptPubKey Q, right. it's in the utxo set, so people can't mess with that
872020-06-22T15:13:10 <alec> aj: I'm talking about the newly created UTXO
882020-06-22T15:13:32 <alec> if I spend a P2TR using keypath and create a P2WPKH output that pays to some key hash
892020-06-22T15:13:44 <alec> I can't change the key hash because it's signed
902020-06-22T15:13:47 <aj> someone tries spending it, so they publish a P and a script S. say S = "ajpubkey CHECKSIG", but you created the utxo Q with a script "alexpubkey CHECKSIG" instead
912020-06-22T15:13:57 <alec> but in P2TR using script path, I don't see a signature
922020-06-22T15:14:11 <aj> so Q = P + H(P, "alexpubkey CHECKSIG")*G
932020-06-22T15:14:39 <aj> we then get my proposed tx, which has P, S="ajpubkey CHECKSIG" and calculate Q' = P + H(P,S)*G and see that it doesn't match
942020-06-22T15:15:17 <aj> (if it had matched, we would have executed the script, which would then pull a signature from the witness stack and verify it against ajpubkey)
952020-06-22T15:17:05 <alec> aj: I understand. but I was refering to something else. let me rephrease it
962020-06-22T15:18:32 <alec> some transaction has one input, that spends an P2TR UTXO using script path. I can only do that by providing the correct untweaked public key P, the correct S (which you get by deriving the merkle tree S using the script as input plus the missing merkle tree leaves and branches), and input that satisfies the script
972020-06-22T15:18:57 <alec> my transaction created a P2WPKH output, whose script_pubkey is payalex
982020-06-22T15:19:37 <aj> if the script in the UTXO you're spending was "100 OP_CSV" instead of "pubkey CHECKSIG" there wouldn't be a signature, and anyone could reissue your tx moving the funds to a different address
992020-06-22T15:19:39 <alec> my transaction takes a while to get mind, in the mean team, you create a new transaction with my input but a new output, which is P2WPKH and pays to ajpubkeyhash
1002020-06-22T15:20:07 <aj> so the conclusion is always put a checksig in your scripts :)
1012020-06-22T15:20:33 <alec> oh okay. so P2SH and P2WSH has the same problem, only I never thought of it
1022020-06-22T15:21:09 <alec> thanks so much for taking the time to answer my questions. I estimate you've saved me several days of work!
1032020-06-22T15:21:31 <aj> surehttps://www.reddit.com/r/Bitcoin/comments/5vqd6k/sha1_collision_bounty_has_been_claimed/ <-- example of some addresses that didn't require signatures
1042020-06-22T15:21:36 <aj> s/sure// doh
1052020-06-22T16:03:30 *** belcher has quit IRC
1062020-06-22T16:23:36 *** dr-orlovsky has quit IRC
1072020-06-22T16:57:19 *** jonatack has joined ##taproot-bip-review
1082020-06-22T16:57:22 *** jonatack has quit IRC
1092020-06-22T16:57:30 *** jonatack has joined ##taproot-bip-review
1102020-06-22T18:01:39 <alec> do parties need to exchange their R values for schnorr multisig?
1112020-06-22T18:02:40 <alec> if i do the math for 2-of-2 multisig I get stuck at H(R¹âP¹âm)P¹+ H(R²âP²âm)P² = H(R¹+R²âPâm)P¹+H(R¹+R²âPâm)P², implying the need for parties to exchange their Rs
1122020-06-22T18:06:18 <alec> my fault, it's H(R¹âPâm)P¹+H(R²âPâm)P² = H(R¹+R²âPâm)P¹+H(R¹+R²âPâm)P²
1132020-06-22T18:32:21 *** dr-orlovsky has joined ##taproot-bip-review
1142020-06-22T18:47:00 *** dr-orlovsky has quit IRC
1152020-06-22T18:49:32 *** dr-orlovsky has joined ##taproot-bip-review
1162020-06-22T18:49:57 <aj> alec: yes; have a look at https://blockstream.com/2019/02/18/en-musig-a-new-multisignature-standard/ and https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da for more details on how to do that
1172020-06-22T19:26:20 *** dr-orlovsky has quit IRC