12019-12-09T00:15:37  *** davterra has quit IRC
  22019-12-09T00:16:08  *** pinheadmz has joined ##taproot-bip-review
  32019-12-09T00:16:32  *** davterra has joined ##taproot-bip-review
  42019-12-09T00:27:32  *** davterra has quit IRC
  52019-12-09T01:20:00  *** afk11 has quit IRC
  62019-12-09T01:22:34  *** afk11 has joined ##taproot-bip-review
  72019-12-09T01:23:28  <aj> elichai2: has_square_y(R) will be false if R is 0; so verification should fail by my reading
  82019-12-09T01:24:53  <aj> elichai2: i think getting s=0 without R=P=0 is implausible?
  92019-12-09T01:25:57  <aj> elichai2: (R=0 would mean you'd know the discrete log of R (k=0) so you could solve for P's private key)
 102019-12-09T01:48:30  *** mryandao- is now known as mryanado
 112019-12-09T01:48:35  *** mryanado is now known as mryandao
 122019-12-09T02:00:30  *** Chris_Stewart_5 has joined ##taproot-bip-review
 132019-12-09T02:21:51  *** achow101 has quit IRC
 142019-12-09T02:36:03  *** achow101 has joined ##taproot-bip-review
 152019-12-09T03:06:49  *** Chris_Stewart_5 has quit IRC
 162019-12-09T03:25:26  *** ZmnSCPxj has joined ##taproot-bip-review
 172019-12-09T03:26:36  *** ZmnSCPxj_ has quit IRC
 182019-12-09T03:40:19  *** arik_ has joined ##taproot-bip-review
 192019-12-09T03:47:20  *** davterra has joined ##taproot-bip-review
 202019-12-09T04:22:31  *** pinheadmz has quit IRC
 212019-12-09T06:09:38  *** rottensox is now known as sanders2020
 222019-12-09T06:52:33  *** sanders2020 is now known as rottensox
 232019-12-09T07:00:35  *** arik_ has quit IRC
 242019-12-09T07:07:48  <gmaxwell> s=0 is a perfectly valid signature. r=0 can't ever be valid because no point on the curve has x=0.  I don't know why you'd want to have rules for these things.
 252019-12-09T07:08:06  <gmaxwell> They're not corner cases in any impementation that comes to mind.
 262019-12-09T07:08:35  <gmaxwell> implementation*
 272019-12-09T08:09:22  <gmaxwell> you could try the worst bch code of this size and see ifit's also true.
 282019-12-09T08:09:45  <gmaxwell> and that would say if it's a consequence of bch or some other algebraic property the code happens to have
 292019-12-09T08:10:11  <gmaxwell> (which might also be responsible for its atypically good performance for 5 errors)
 302019-12-09T08:14:29  <gmaxwell> oops wrong channel
 312019-12-09T08:25:34  <elichai2> gmaxwell: for some reason I remembered this was a check in jonasnick's implementation. But I misremembered, it's a check in ecdsa not schnorr
 322019-12-09T08:26:48  <gmaxwell> situation is different for ecdsa. S is inverted in ecdsa, and 0 doesn't have a modular inverse.
 332019-12-09T09:01:17  <elichai2> 👍
 342019-12-09T09:13:35  *** jonatack has quit IRC
 352019-12-09T09:21:39  *** arik_ has joined ##taproot-bip-review
 362019-12-09T09:30:17  *** arik_ has quit IRC
 372019-12-09T09:31:15  *** arik_ has joined ##taproot-bip-review
 382019-12-09T09:40:17  *** arik_ has quit IRC
 392019-12-09T09:41:15  *** arik_ has joined ##taproot-bip-review
 402019-12-09T09:58:11  *** jonatack has joined ##taproot-bip-review
 412019-12-09T10:03:17  *** jonatack has quit IRC
 422019-12-09T10:03:40  *** jonatack has joined ##taproot-bip-review
 432019-12-09T10:10:15  *** b10c has joined ##taproot-bip-review
 442019-12-09T10:16:44  *** evoskuil[m] has quit IRC
 452019-12-09T10:56:33  *** dr-orlovsky has quit IRC
 462019-12-09T10:57:12  *** dr-orlovsky has joined ##taproot-bip-review
 472019-12-09T11:15:00  *** reallll has joined ##taproot-bip-review
 482019-12-09T11:16:26  *** belcher has quit IRC
 492019-12-09T11:19:51  *** evoskuil[m] has joined ##taproot-bip-review
 502019-12-09T11:31:09  *** Chris_Stewart_5 has joined ##taproot-bip-review
 512019-12-09T12:09:21  *** Chris_Stewart_5 has quit IRC
 522019-12-09T12:13:28  *** ZmnSCPxj has quit IRC
 532019-12-09T12:13:37  *** ZmnSCPxj has joined ##taproot-bip-review
 542019-12-09T13:50:00  *** reallll is now known as belcher
 552019-12-09T14:20:23  *** luke-jr has quit IRC
 562019-12-09T14:24:56  *** jonatack has quit IRC
 572019-12-09T14:47:10  *** luke-jr has joined ##taproot-bip-review
 582019-12-09T15:04:04  *** luke-jr has quit IRC
 592019-12-09T15:09:26  *** luke-jr has joined ##taproot-bip-review
 602019-12-09T15:37:09  *** pinheadmz has joined ##taproot-bip-review
 612019-12-09T15:54:53  *** jonatack has joined ##taproot-bip-review
 622019-12-09T15:59:15  *** andrewtoth_ has joined ##taproot-bip-review
 632019-12-09T16:00:08  *** _andrewtoth_ has quit IRC
 642019-12-09T16:07:36  *** andrewtoth_ has quit IRC
 652019-12-09T16:17:04  *** andrewtoth_ has joined ##taproot-bip-review
 662019-12-09T16:29:25  *** t-bast has joined ##taproot-bip-review
 672019-12-09T16:29:47  <t-bast> Hi
 682019-12-09T16:29:48  <t-bast> Now that we're using 32-byte public keys, does it mean that introducing things like ANYPREVOUT can only be done via script-spend (and not key-path spend)?
 692019-12-09T16:29:48  <t-bast> Or am I missing something? It seems that it's only available by extending script when keys have a length that's neither 0 or 32 (at least that's how I understand the BIP).
 702019-12-09T16:30:10  <t-bast> It looks like the annex may be usable for that too, is that correct?
 712019-12-09T16:36:01  *** michaelfolkson has joined ##taproot-bip-review
 722019-12-09T16:40:42  *** t-bast-42 has joined ##taproot-bip-review
 732019-12-09T16:42:43  *** t-bast has quit IRC
 742019-12-09T16:43:47  *** t-bast-official has joined ##taproot-bip-review
 752019-12-09T16:45:27  <ZmnSCPxj> My understanding is that even with x-only pubkey, we can use non-32-byte SegWit v1 (i.e. "explicit output tagging")
 762019-12-09T16:45:59  *** t-bast-42 has quit IRC
 772019-12-09T16:46:12  <ZmnSCPxj> alternately, we can hide it in a new tapscript version, or any of a number of ways, including new `OP_` codes, or allowing pubkey types in `OP_CHECKSIG`
 782019-12-09T16:48:15  <ZmnSCPxj> In any case, most who want to impose limits on `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT` want outputs to be tagged, and do not want chaperone signatures.
 792019-12-09T16:48:29  <ZmnSCPxj> And annexes are input tagging, not output tagging, as far as I can understand them.
 802019-12-09T16:48:53  <ZmnSCPxj> Thus, while annexes *can* be used to enable `SIGHASH_NOINPUT`, I doubt they will
 812019-12-09T16:48:54  *** michaelfolkson has quit IRC
 822019-12-09T16:59:21  <t-bast-official> But none of your suggestions allow key-path spend with ANYPREVOUT, do they? Except maybe the first one ("explicit output tagging"), can you point me to more details about that?
 832019-12-09T16:59:33  <t-bast-official> They're all for script-path spends, right?
 842019-12-09T17:01:31  *** michaelfolkson has joined ##taproot-bip-review
 852019-12-09T17:02:20  *** michaelfolkson has quit IRC
 862019-12-09T17:05:30  <harding> t-bast-official: I don't think anyprevout ever worked with key-path spends, see footnote 3 in bip-anyprevout: "What about key path spends? This proposal only supports ANYPREVOUT spends via script path, and does not support ANYPREVOUT key path spends. [...]"
 872019-12-09T17:05:46  *** ZmnSCPxj has quit IRC
 882019-12-09T17:05:49  *** davterra has quit IRC
 892019-12-09T17:06:36  *** ZmnSCPxj has joined ##taproot-bip-review
 902019-12-09T17:06:41  <t-bast-official> harding: interesting, I had forgotten that, I'll re-read the latest version of the BIP
 912019-12-09T17:08:50  <t-bast-official> harding: thanks for raising this, I'm not fully convinced by the first two arguments but the third one ("it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent.") makes a lot of sense
 922019-12-09T17:09:39  <t-bast-official> It seems like generally we'll want to avoid pubkey namespacing on the key-path spend, to avoid those namespaces to leak until they're actually used for spending
 932019-12-09T17:13:41  <harding> Yep.  Also, looking at the three reasons, I think #1 makes sense because we can't add a new sighash to key-path spending in a separate soft fork from taproot (i.e. bip-taproot says "The following use of hash_type are invalid, and fail execution: [...] Using any hash_type value that is not 0x00, 0x01, 0x02, 0x03, 0x81, 0x82, or 0x83".  Reason #2 makes sense to ignore since everyone seems to be leaning towards dropping chaparone
 942019-12-09T17:13:41  <harding> sigs and a requirement.  Reason #3, as you say, makes sense for privacy/fungibility.
 952019-12-09T17:14:46  <harding> Whoops, that should've said: dropping chaparone sigs *as a requirement*
 962019-12-09T17:15:42  <t-bast-official> Got it, thanks for the answer!
 972019-12-09T17:15:56  <harding> Sure!
 982019-12-09T17:15:56  *** t-bast-official has quit IRC
 992019-12-09T17:44:17  *** michaelfolkson has joined ##taproot-bip-review
1002019-12-09T17:50:37  *** michaelfolkson has quit IRC
1012019-12-09T17:52:38  *** _andrewtoth_ has joined ##taproot-bip-review
1022019-12-09T17:54:00  *** andrewtoth_ has quit IRC
1032019-12-09T17:56:28  *** _andrewtoth_ has quit IRC
1042019-12-09T18:16:16  *** michaelfolkson has joined ##taproot-bip-review
1052019-12-09T18:16:32  *** michaelfolkson has quit IRC
1062019-12-09T18:24:48  *** pinheadmz has quit IRC
1072019-12-09T19:49:18  *** _andrewtoth_ has joined ##taproot-bip-review
1082019-12-09T20:39:29  *** pinheadmz has joined ##taproot-bip-review
1092019-12-09T21:09:06  *** pinheadmz has quit IRC
1102019-12-09T21:46:58  *** arik_ has quit IRC
1112019-12-09T22:26:58  *** luke-jr has quit IRC
1122019-12-09T22:29:29  *** arik_ has joined ##taproot-bip-review
1132019-12-09T22:36:11  *** arik_ has quit IRC
1142019-12-09T22:43:35  *** calvz14 has joined ##taproot-bip-review
1152019-12-09T23:02:58  *** b10c has quit IRC
1162019-12-09T23:11:18  *** calvz14 has quit IRC
1172019-12-09T23:55:38  *** luke-jr has joined ##taproot-bip-review