--- Log opened Tue Jan 28 00:00:22 2020
00:03 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Ping timeout: 248 seconds]
04:03 -!- jl2012 [sid133844@gateway/web/irccloud.com/x-efdjepelehtqxeqa] has quit []
04:03 -!- jl2012 [sid133844@gateway/web/irccloud.com/x-erbonvcxulpfnamc] has joined #bitmetas
12:32 < jnewbery> sipa: in that case, do you think the terminology "quadratic residue" should be removed entirely from BIP340? (And we just talk about scalars being square in field of integers mod SECP256K1_FIELD_SIZE)?
12:38 < sipa> jnewbery: perhaps... though maybe just one footnote explaining that squares in the field of integers mod n is the same as those numbers interpreted as integers being quadratic residues... 
15:12 < jnewbery> I'm trying to work out how to do a generic (non-taproot) pay-to-contract with 32-byte bip-schnorr.
15:12 < jnewbery> With 33 byte pubkeys, we have a privkey d/pubkey P, then set Q := P + H(P|c)G. We can sign with d + H(P|c) and prove that we committed to c by showing that Q = P + H(P|c).
15:12 < jnewbery> With 32 byte pubkeys the point Q might not have square Y, and we can still sign by negating the tweaked privkey (FIELD_SIZE - d - H(P|c)), but we can no longer show that Q = P + H(P|c).
15:13 < jnewbery> That's why in taproot the control block has a bit to determine whether to negate Q in the script-path spend.
15:13 < jnewbery> Is that right? How would it work in a more generic pay-to-contract?
15:14 < jnewbery> * sorry, negated tweaked privkey should be (GROUP_ORDER - d - H(P|c))
15:17 < sipa> jnewbery: if you consider f(P,c) = P + H(P||c)G as a commitment scheme, in an x-only point encoding world, the opening of the commitment consists of P,c, and the negation bit
15:19 < sipa> well; only if you want a batch-verifiable commitment
15:19 < jnewbery> ok, so the prover just gives an extra bit to the verifier?
15:19 < sipa> otherwise the verifier can just recompute f(P,c) and compare it with the provided commitment
15:19 < sipa> yup
15:20 < sipa> jnewbery: btw, https://github.com/sipa/bips/issues/190 and https://github.com/sipa/bips/issues/191
15:20 < jnewbery> if you don't want batch verifiability, the prover just tries with 0 and 1?
15:20 < sipa> the verifier, you mean?
15:20 < sipa> that's one possibility - but he can also recompute
15:20 < jnewbery> sorry, yes the verifier
15:20 < sipa> the verifier is given P and c, he can recompute f(P,c), which doesn't require knowing the negation flag
15:20 < sipa> but is also not batch verifiable
15:21 < jnewbery> ok, so verifier recomputes P + H(P||c)G, and if the x value of that point is the Q pubkey, then we're good
15:22 < sipa> yup, that works
15:22 < jnewbery> great. Thanks!
15:57 < aj> jnewbery: https://twitter.com/jfnewbery/status/1222273819337003008 reminds me of https://www.youtube.com/watch?v=E0E0ynyIUsg
15:58 < sipa> aj: did you see https://github.com/sipa/bips/issues/190 and https://github.com/sipa/bips/issues/191 ?
15:59 < sipa> we're considering changing the pubkey tiebreaker from square-y to even-y, as it seems this actually makes signing faster (and verification very very slightly slower), and means less headaches integrating with existing bip32-based key derivation infrastructure and psbt
16:14 < aj> sipa: so much for no semantic changes
16:20 < sipa> aj: yeah...
23:40 < sipa> https://github.com/sipa/bips/pull/192
23:43 < aj> sipa: maybe BIP340/nonce BIP340/challenge for the tagged hashes?
23:44 < sipa> aj: i'm not really a fan of tying these things to the document that initially defines them, but it's a possibility
23:45 < aj> "Seitch" -> "Switch" in the PR title
23:46 < sipa> maybe BIP340 in there is not bad; it's super unambiguous
--- Log closed Wed Jan 29 00:00:23 2020