--- Log opened Mon Jun 22 00:01:00 2020
00:48 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:52 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined ##taproot-bip-review
00:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
01:59 -!- jonatack [~jon@184.75.221.179] has joined ##taproot-bip-review
02:17 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review
03:14 < alec> when tweaking a public key with t, is t added to the x- and y-coordinates?
04:17 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:55 -!- jonatack [~jon@184.75.221.179] has quit [Ping timeout: 240 seconds]
05:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
05:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-bip-review
06:01 < ghost43> alec: grep bip341 for "def taproot_tweak_pubkey"
06:02 < ghost43> P + t1*G,  where t1 is some hash that involves both t and P
07:14 < alec> right, found it, thanks
07:15 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined ##taproot-bip-review
07:17 < alec>     t = int_from_bytes(tagged_hash("TapTweak", pubkey + h))
07:17 < alec> I guess pubkey here is the compressed pubkey consisting only of the x-coordinate
07:17 < alec> or is it a point, then it becomes pubkey.x=h, pubkey.y+h?
07:21 < alec> well, must be scalar since tagged_hash's second argument is expected to be bytes
07:26 < 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?
07:29 < aj> a private key tweak of "q" always corresponds to a public key tweak of "q*G"
07:32 < alec> that makes sense
07:34 < 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
07:35 < alec> I'm somehow missing the part where the additivity property comes into play. can you tell me where that is?
07:41 < 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
07:41 < aj> adding H(R,P+tG,m)*t to s ?
07:43 < 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
07:46 < aj> Q=q*G usually
07:46 < alec> from there it looks like normal Schnorr verification. I'm missing where I need P+tG=(p+t)G
07:46 < alec> aj: sorry, I meant qG
07:47 < aj> If you take a partial signature, using privkey p,  s = r + H(r*G, P+t*G, m)p
07:47 < aj> and then add H(r*G, P+t*G, m)t   (same hash, multiplied by the tweak as a scalar)
07:47 < aj> call that x
07:48 < 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)
07:48 < aj> multiply both by G, to turn into points
07:48 < aj> you get (s+x)*G = r*G + H(R, Q, m)*Q   where Q=P+t*G
07:49 < aj> which gets you back to a normal schnorr sig  s+x, R  with pubkey Q on message m
07:49 < alec> aj: thanks for the information! I'll try to work through it
07:50 < 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
07:51 < 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
07:52 < alec> oh ok. so the key path spend of a P2TR does not need Schnorr's additivity property?
07:52 < alec> if I sign with q=p+t, that is
07:53 < 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"
07:54 < alec> ok, let's rephrase that to "does not take advantage of its additivity propety"
07:54 < 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
07:55 < alec> aj: thanks, that answers my question
07:56 -!- raj_149 is now known as raj_
07:58 < alec> as to the script path: the additivity propery is not required, either, right?
07:59 < alec> you just make sure tweaked public key according to the data provided matches Q from the script_pubkey, right?
08:00 < 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)
08:02 < 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?
08:02 < alec> ok, I got that so far
08:04 < 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
08:04 < 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?
08:05 < 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
08:05 < alec> if I sign with q=p+t, I could spend funds locked with Q, too.
08:07 < 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
08:08 < alec> aj: okay, now I know I'm not crazy
08:08 < 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"
08:08 < 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
08:09 < 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
08:09 < alec> yeah, I know that P_alice_and_bob=P_alice+P_bob only works with schnorr, not ECDSA
08:10 < alec> aj: one final question, then I'll be out of your hair. thanks so far, anyway!
08:11 < 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
08:11 < alec> in script path, how is theft of funds by substituting output's script_pubkeys in unconfirmed transactions addressed?
08:11 < aj> "substituting output's script pubkeys" ? the ones in the script, or the scriptPubKey from the utxo?
08:11 < 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
08:12 < alec> the one's in the outputs that spend the inputs that unlock a P2TR using script path
08:12 < 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
08:13 < alec> aj: I'm talking about the newly created UTXO
08:13 < alec> if I spend a P2TR using keypath and create a P2WPKH output that pays to some key hash
08:13 < alec> I can't change the key hash because it's signed
08:13 < 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
08:13 < alec> but in P2TR using script path, I don't see a signature
08:14 < aj> so Q = P + H(P, "alexpubkey CHECKSIG")*G
08:14 < 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
08:15 < 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)
08:17 < alec> aj: I understand. but I was refering to something else. let me rephrease it
08:18 < 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
08:18 < alec> my transaction created a P2WPKH output, whose script_pubkey is payalex
08:19 < 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
08:19 < 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
08:20 < aj> so the conclusion is always put a checksig in your scripts :)
08:20 < alec> oh okay. so P2SH and P2WSH has the same problem, only I never thought of it
08:21 < alec> thanks so much for taking the time to answer my questions. I estimate you've saved me several days of work!
08:21 < aj> surehttps://www.reddit.com/r/Bitcoin/comments/5vqd6k/sha1_collision_bounty_has_been_claimed/ <-- example of some addresses that didn't require signatures
08:21 < aj> s/sure// doh
09:03 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
09:23 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review
09:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Client Quit]
09:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review
11:01 < alec> do parties need to exchange their R values for schnorr multisig?
11:02 < 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
11:06 < 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²
11:32 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined ##taproot-bip-review
11:46 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:49 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has joined ##taproot-bip-review
11:49 < 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
12:26 -!- dr-orlovsky [~dr-orlovs@xdsl-188-154-186-21.adslplus.ch] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:03 -!- davterra [~dulyNoded@89.45.90.34] has joined ##taproot-bip-review
--- Log closed Tue Jun 23 00:00:59 2020