12019-11-26T01:11:44  *** rottensox has quit IRC
  22019-11-26T01:12:07  *** rottensox has joined ##taproot-bip-review
  32019-11-26T01:22:33  *** Chris_Stewart_5 has quit IRC
  42019-11-26T01:26:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
  52019-11-26T02:37:57  *** Chris_Stewart_5 has quit IRC
  62019-11-26T03:02:16  *** ZmnSCPxj_ has joined ##taproot-bip-review
  72019-11-26T03:19:54  *** pinheadmz_ has joined ##taproot-bip-review
  82019-11-26T03:23:14  *** pinheadmz has quit IRC
  92019-11-26T03:23:15  *** pinheadmz_ is now known as pinheadmz
 102019-11-26T03:57:02  *** jonatack_ has quit IRC
 112019-11-26T04:24:06  *** pinheadmz has quit IRC
 122019-11-26T04:28:30  *** pinheadmz has joined ##taproot-bip-review
 132019-11-26T04:49:27  *** luke-jr has quit IRC
 142019-11-26T05:13:15  *** ZmnSCPxj__ has joined ##taproot-bip-review
 152019-11-26T05:16:01  <ZmnSCPxj__> harding: possibly we can move to sending h(r * G) "early", i.e. in the previous `commitment_signed`, we already sent our `h(r * G)` for our *current* `commitment_signed`.
 162019-11-26T05:17:09  <ZmnSCPxj__> ...but the other side still needs to send back its `R` as well before we can send our partial `s`, hmm, no.
 172019-11-26T05:20:27  <ZmnSCPxj__> current LN already requires 1.5 round trips to forward a payment.  We can batch multiple payments together but there's still turnaround time for the remote side to accept the creation of the HTLC.
 182019-11-26T05:22:49  *** luke-jr has joined ##taproot-bip-review
 192019-11-26T05:22:51  <ZmnSCPxj__> There is my old proposal for fast forwards as well, which reduces forwarding to 0.5 round trips but requires a later "cleanup" that batches several forwards + claims/errors.
 202019-11-26T05:22:54  <ZmnSCPxj__> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
 212019-11-26T05:23:36  <ZmnSCPxj__> If we use MuSig for only the funding transaction output, then it's only the later "cleanup" that needs the 2.5 round trips overhead of the MuSig protocol.
 222019-11-26T05:30:28  <ZmnSCPxj__> Such a tradeoff may be acceptable.  In the happy case where most closes are mutual, then channel closes look exactly like singlesig spends.
 232019-11-26T05:30:29  *** yaslama_ has quit IRC
 242019-11-26T05:30:45  *** yaslama has joined ##taproot-bip-review
 252019-11-26T05:31:19  <ZmnSCPxj__> This adds overhead for updating the actual channel mechanism, but my fast forwards proposal does not use the channel mechanism "directly", it instead spends the output the forwarding side owns
 262019-11-26T05:32:05  <ZmnSCPxj__> Then on claiming the forwardee adds another transaction that spends that HTLC.
 272019-11-26T05:32:27  <ZmnSCPxj__> And *then* the channel mechanism is used to cut through the intermediate transactions
 282019-11-26T05:33:24  <ZmnSCPxj__> But by then the hash preimage has been provided and the transaction has completed, and the cut-through is now "just" an optimization enabled by the update mechanism.
 292019-11-26T05:38:42  <ZmnSCPxj__> Or just punt and do not use MuSig for channel commitment updates, instead use a MuSig(A, B) internal key and a Tapscript with a `<A> OP_CHECKSIGVERIFY <B>  OP_CHECKSIG`, and only use MuSig for mutual closes anyway.
 302019-11-26T05:55:18  *** rottensox_ has joined ##taproot-bip-review
 312019-11-26T05:57:42  *** rottensox has quit IRC
 322019-11-26T05:58:51  *** rottensox__ has joined ##taproot-bip-review
 332019-11-26T05:59:18  *** dr-orlovsky has quit IRC
 342019-11-26T06:01:19  *** rottensox_ has quit IRC
 352019-11-26T06:27:59  *** jonatack_ has joined ##taproot-bip-review
 362019-11-26T06:28:15  *** jonatack_ has quit IRC
 372019-11-26T06:28:32  *** jonatack has joined ##taproot-bip-review
 382019-11-26T06:43:13  <aj> ZmnSCPxj__: could have a script path that only takes 1 round, so that the routing can continue quickly, but also clean up afterwards by finishing musig key path spend as well
 392019-11-26T07:29:27  *** ZmnSCPxj__ has quit IRC
 402019-11-26T07:44:45  *** rottensox__ has quit IRC
 412019-11-26T08:01:04  *** jonatack_ has joined ##taproot-bip-review
 422019-11-26T08:04:41  *** jonatack has quit IRC
 432019-11-26T08:08:24  *** hebasto has quit IRC
 442019-11-26T08:08:49  *** hebasto has joined ##taproot-bip-review
 452019-11-26T08:14:01  *** ZmnSCPxj___ has joined ##taproot-bip-review
 462019-11-26T08:15:11  <ZmnSCPxj___> aj: True, though note this still requires 1.5 round trips to forward, whereas fast forwards requires 0.5 round trips and the signing for the new commitment transactions is no longer on the hot path.
 472019-11-26T08:16:21  <ZmnSCPxj___> However fast forward requires symmetrical  CSVs, I believe there was an argument recently against syemmtrical CSVs.
 482019-11-26T08:29:43  <aj> ZmnSCPxj___: hmm, that doesn't sound right, but i've definitely lost track of what non-eltoo taproot ln scripts might look like
 492019-11-26T08:40:41  <ZmnSCPxj___> there has not been *any* discussion of taproot usage in Lightning yet. Perhaps I should spam another article on lightning-dev, I have not been spamming it enough recently....
 502019-11-26T08:41:00  <ZmnSCPxj___> I mean in relation to Poon-Dryja, not Decker-Russell-Osuntokun
 512019-11-26T08:41:34  <ZmnSCPxj___> Taproot use for Decker-Russell-Osuntokun has had some discussion, but potentially not enough.
 522019-11-26T08:44:49  <aj> ZmnSCPxj___: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001038.html
 532019-11-26T08:46:15  <aj> https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md has some links too, but that was the only poon-dryja one i think
 542019-11-26T08:47:02  *** jeremyrubin has quit IRC
 552019-11-26T08:48:50  *** b10c has joined ##taproot-bip-review
 562019-11-26T08:50:48  <ZmnSCPxj___> Your first link seems to point only to Schnorr, not *taproot*, so...................
 572019-11-26T08:50:50  <ZmnSCPxj___> :)
 582019-11-26T08:52:32  <ZmnSCPxj___> as does the second; it is about scriptless script, not tapscript, I think.
 592019-11-26T08:53:37  <ZmnSCPxj___> So far there has been no discussion on the use of taproot in Lightning, from what I can tell; I believe the thought was that everything could be done with pre-signed txes and scriptless script.
 602019-11-26T08:53:53  <ZmnSCPxj___> Even revocation I believe could be done with scriptless script.
 612019-11-26T08:54:40  <ZmnSCPxj___> No, not even scriptless. Just give your secret as the revocation key, since you do not exchange the revocation key for anything other than the continuation of the protocol.
 622019-11-26T08:57:33  <ZmnSCPxj___> i.e. to-self output would be a 2-of-2 MuSig between you and counterparty with temporary  keys, you get a presigned transaction that spends that output and gives it to you, but with a `nSequence` encumbrance; then to revoke that you give the secret to that key, which lets the counterparty spend it completely without you as it now knows both secrets.
 632019-11-26T09:00:56  <gmaxwell> I've wondered what you could do with a tree of distinct CSVs and you incrementally hand out private keys at different CSV levels, closer and closer to current.
 642019-11-26T09:07:40  <aj> ZmnSCPxj___: yeah, if you don't care about all the round trips for musig, i think everything works scriptlessly, which means you just need schnorr not taproot
 652019-11-26T09:08:03  <aj> ZmnSCPxj___: if you want to minimise round trips, i think an alternate script path might be worth the extra sigs, but not sure
 662019-11-26T09:12:26  *** achow101 has quit IRC
 672019-11-26T09:15:19  *** CubicEarth has quit IRC
 682019-11-26T09:18:33  *** CubicEarth has joined ##taproot-bip-review
 692019-11-26T09:39:43  *** achow101 has joined ##taproot-bip-review
 702019-11-26T09:49:10  *** CubicEarth has quit IRC
 712019-11-26T09:54:49  *** CubicEarth has joined ##taproot-bip-review
 722019-11-26T10:01:43  *** ZmnSCPxj___ has quit IRC
 732019-11-26T10:23:10  *** jonatack_ has quit IRC
 742019-11-26T10:23:27  *** jonatack has joined ##taproot-bip-review
 752019-11-26T10:41:17  *** CubicEarth has quit IRC
 762019-11-26T10:54:30  *** CubicEarth has joined ##taproot-bip-review
 772019-11-26T11:17:40  <ZmnSCPxj_> gmaxwell: replicates the decrementing-`nSequence` mechanism in Decker Wattenhofer I think
 782019-11-26T11:18:48  <ZmnSCPxj_> aj: I think that "alternate script path" technique is something worth discussing on lightning-dev, and is what I was referring to about there not being any discussion about this yet.
 792019-11-26T11:19:54  <ZmnSCPxj_> gmaxwell: could be interesting with `OP_SECURETHEBAG` / `OP_CHECKOUTPUTHASHVERIFY`?
 802019-11-26T11:33:33  *** Chris_Stewart_5 has joined ##taproot-bip-review
 812019-11-26T12:49:17  *** Chris_Stewart_5 has quit IRC
 822019-11-26T12:54:26  *** Chris_Stewart_5 has joined ##taproot-bip-review
 832019-11-26T13:22:50  *** dr-orlovsky has joined ##taproot-bip-review
 842019-11-26T13:28:42  *** Chris_Stewart_5 has quit IRC
 852019-11-26T13:40:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
 862019-11-26T13:48:45  *** kabaum has quit IRC
 872019-11-26T13:51:47  *** kabaum has joined ##taproot-bip-review
 882019-11-26T14:14:02  *** dr-orlovsky has quit IRC
 892019-11-26T15:09:36  *** dr-orlovsky has joined ##taproot-bip-review
 902019-11-26T15:10:37  *** pyskell has joined ##taproot-bip-review
 912019-11-26T15:15:41  *** pyskl has joined ##taproot-bip-review
 922019-11-26T15:19:06  *** pyskell has quit IRC
 932019-11-26T15:32:40  *** mryandao has quit IRC
 942019-11-26T15:32:58  *** mryandao has joined ##taproot-bip-review
 952019-11-26T16:17:11  *** andrewtoth_ has joined ##taproot-bip-review
 962019-11-26T17:09:05  *** andytoshi has joined ##taproot-bip-review
 972019-11-26T17:59:25  *** Chris_Stewart_5 has quit IRC
 982019-11-26T18:13:43  *** Chris_Stewart_5 has joined ##taproot-bip-review
 992019-11-26T18:36:40  *** _andrewtoth_ has joined ##taproot-bip-review
1002019-11-26T18:38:00  *** andrewtoth_ has quit IRC
1012019-11-26T18:42:40  *** _andrewtoth_ has quit IRC
1022019-11-26T18:44:11  *** sipa has joined ##taproot-bip-review
1032019-11-26T18:48:12  *** shesek has quit IRC
1042019-11-26T18:48:35  *** shesek has joined ##taproot-bip-review
1052019-11-26T18:48:35  *** shesek has joined ##taproot-bip-review
1062019-11-26T19:01:10  *** pyskl is now known as pyskell
1072019-11-26T19:01:16  <aj> #startmeeting
1082019-11-26T19:01:16  <lightningbot> Meeting started Tue Nov 26 19:01:16 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
1092019-11-26T19:01:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1102019-11-26T19:01:21  <pyskell> hi
1112019-11-26T19:01:23  <nickler> hi
1122019-11-26T19:01:27  <kabaum> hi
1132019-11-26T19:01:37  *** pyskell has quit IRC
1142019-11-26T19:01:37  *** pyskell has joined ##taproot-bip-review
1152019-11-26T19:01:42  <aj> hi
1162019-11-26T19:01:44  <fanquake> hi
1172019-11-26T19:01:48  <sipa> hi
1182019-11-26T19:01:52  <schmidty> hi
1192019-11-26T19:03:41  <kabaum> Good to see you all again.
1202019-11-26T19:03:43  <kabaum> Q1/2 group 5: "Transaction digest": scriptPubKey is listed as 35 bytes. Shouldn't that be 34 bytes? OP_1 OP_20 <32 byte witness program>? Is the extra byte a leading varint as in the output? If so, why don't we remove it since it's always 35, well 34, bytes?
1212019-11-26T19:04:19  <sipa> kabaum: partially the result of the fact that this existed before P2SH support was removed
1222019-11-26T19:04:22  <ariard_> hi
1232019-11-26T19:04:46  <sipa> because back then, scriptPubKey for a P2SH-taproot spend would actually contain the P2SH scriptPubKey
1242019-11-26T19:04:54  <sipa> (rather than its redeemscript)
1252019-11-26T19:06:08  <sipa> The rationale here is that by default really every signature should commit to vout hash/id, and exact scriptPubKey and amount, as it guarantees offline signing devices can verify the entire path between the claimed UTXO being spent and whatever it commits to
1262019-11-26T19:06:23  <jonatack> hi
1272019-11-26T19:06:44  *** devrando1 has joined ##taproot-bip-review
1282019-11-26T19:07:21  <sipa> And the justification is a very minor issue right now where a software wallet could claim to a HW device that it is spending a P2SH-P2WSH output for example, but the real output is a (native) P2WSH one... making the HW device perhaps misrepresent the necessary fees
1292019-11-26T19:07:50  <sipa> this specific example could have been fixed by just exactly committing to P2SH or not
1302019-11-26T19:07:57  <sipa> but it is not the only example of such mutations
1312019-11-26T19:08:08  <sipa> and they're all fixed by just committing to the scriptPubKey
1322019-11-26T19:08:51  <sipa> so yes, we know it's always 34 bytes, and could thus drop the compactsize length that precedes it
1332019-11-26T19:09:22  <sipa> but as a general principle i think it's better to just make it generic, using an approach that will keep working for other kinds of scriptPubKeys as well
1342019-11-26T19:09:30  <sipa> </monologue>
1352019-11-26T19:10:51  <kabaum> So maybe it's better to not say "Its size is always 35 bytes" then?
1362019-11-26T19:11:20  <sipa> well it is in the specific use in bip-taproot
1372019-11-26T19:11:22  <ariard_> how about future extensions of hash_type ? is epoch the versioning number and if so where would you pass the epoch in future extensions, annex?
1382019-11-26T19:11:37  <sipa> ariard_: i don't understand
1392019-11-26T19:11:42  <kabaum> sipa: sure
1402019-11-26T19:12:12  <sipa> oh, i see
1412019-11-26T19:12:13  <ariard_> sipa: let's say we want to have new hash_types, how would we introduce them?
1422019-11-26T19:12:21  <sipa> ariard_: anyway you like
1432019-11-26T19:12:24  <sipa> (if you find consensus)
1442019-11-26T19:12:44  <ariard_> sure but the epoch would be the most fine-grained one ?
1452019-11-26T19:13:06  <ariard_> compare to the leaf version
1462019-11-26T19:13:16  <fjahr> hi
1472019-11-26T19:13:23  <devrando1> hi
1482019-11-26T19:13:24  <sipa> the epoch is not encoded anywhere, it's not an extension mechanism
1492019-11-26T19:14:13  <sipa> it's just so that if something needs to introduce a completely new sighash construction, they don't need a new tag for the tagged hash
1502019-11-26T19:14:25  <sipa> they can instead just set the epoch to another value, and then do whatever they want
1512019-11-26T19:14:36  <sipa> without the risk of ever colliding with a bip-taproot sighash
1522019-11-26T19:14:59  <ariard_> hmmm but at least in demo code epoch is hardcoded to zero?
1532019-11-26T19:15:12  <sipa> it is not just hardcoded in the demo code to be zero
1542019-11-26T19:15:18  <sipa> bip-taproot defines it to be zero
1552019-11-26T19:15:19  <nickler> ariard_: the sighash_anyprevout hash type is proposed to be introduced with a new pubkey type
1562019-11-26T19:15:35  <sipa> we could just not give it a name
1572019-11-26T19:15:37  <sipa> it's just zero
1582019-11-26T19:16:14  <ariard_> in SignatureHashSchnorr, epoch = 0
1592019-11-26T19:16:19  <sipa> yes
1602019-11-26T19:16:36  <sipa> and bip-taproot says:
1612019-11-26T19:16:37  <sipa> epoch (1): always 0
1622019-11-26T19:16:53  <ariard_> nickler: using key_version?
1632019-11-26T19:17:06  <nickler> yeah
1642019-11-26T19:17:11  <sipa> nickler: ariard_ is asking about epoch, not key version
1652019-11-26T19:17:43  <ariard_> sipa: yes but I thought you could use epoch as a upgrade mechanism like key version, but apparently that's not the case
1662019-11-26T19:18:11  <devrando1> the epoch is not serialized
1672019-11-26T19:18:25  *** midnightmagic is now known as midnight
1682019-11-26T19:18:37  *** arik_ has joined ##taproot-bip-review
1692019-11-26T19:18:46  <devrando1> so you can't use it to communicate anything
1702019-11-26T19:19:40  <devrando1> it's only part of the data bytes that are hashed, but it's a non-stored constant
1712019-11-26T19:20:06  <sipa> i explained it more to ariard_ irl
1722019-11-26T19:20:22  <sipa> but i think the epoch can use better justification in the text
1732019-11-26T19:21:17  <sipa> really, its goal is to enable reusing the tag "TapSigHash" even in potential hypothetical future sighashes that completely change the data hashed
1742019-11-26T19:21:27  <sipa> without risking collisions
1752019-11-26T19:22:11  <sipa> so really, this sighash scheme just sets the first byte to 0, so that there is a simple guaranteed way for future sighashes that intend to be different: they can set the first byte to not-0
1762019-11-26T19:22:28  <sipa> but as far as bip-taproot is concerned, it's not an extension mechanism; it's just a 0
1772019-11-26T19:24:00  <kabaum> sipa: Now I get epoch. Thanks.
1782019-11-26T19:24:56  <kabaum> Q2/2: "Transaction digest": The summary at the end: Isn't another difference that in case ANYONECANPAY is set, we don't commit to 32 zero bytes in place of hashPrevous as we did in BIP143, but to nothing regarding prevouts. Or is that too insignificaant to make the list?
1792019-11-26T19:25:22  <sipa> kabaum: you cannot commit to 32 zero bytes
1802019-11-26T19:25:27  <sipa> there is no information in them
1812019-11-26T19:25:47  <sipa> it's an implementation detail that the exact data hashed changed
1822019-11-26T19:26:01  <sipa> but in terms of semantics, hashing 32 zero bytes never did anything
1832019-11-26T19:26:24  <kabaum> I see.
1842019-11-26T19:30:33  <gmaxwell> The important thing is that there isn't an 'aliasing' problem, where a commitment to two different things might be confused.
1852019-11-26T19:31:06  <gmaxwell> But you don't need zero stuffing to prevent that, hashing that flags that are in use is sufficient-- actually not just sufficient, better than stuffing without flags.
1862019-11-26T19:31:29  <ariard_> Rationale 16: "Despite that, collisions are made impossible by committing to the length of the data before the variable length data", the commitment here is hash_type and spend_type?
1872019-11-26T19:32:02  *** _andrewtoth_ has joined ##taproot-bip-review
1882019-11-26T19:32:03  <ariard_> but they don't tell you the lenght of the variable length data parts, input outpoints, input amounts, ...?
1892019-11-26T19:32:04  <sipa> ariard_: hmm, we may need to revise that
1902019-11-26T19:32:30  <sipa> because scriptPubKey is no longer variable length
1912019-11-26T19:33:07  <sipa> and all other variable length things have indirect commitments to their lengths using intermediate hashes
1922019-11-26T19:33:27  <sipa> (e.g. the annex has its length committed to by being prehashed)
1932019-11-26T19:34:39  <ariard_> okay is collision of final hash by tweaking indirect commitments an issue?
1942019-11-26T19:35:50  <sipa> we assume we have a collision resistant hash function
1952019-11-26T19:35:51  <sipa> so no
1962019-11-26T19:37:29  <sipa> ariard_: collisions through indirect hashes are no more a problem that collisions in the directly hashed data is a problem
1972019-11-26T19:40:12  <devrando1> none of the hashing in bip-taproot (or existing Bitcoin code) is vulnerable to extension attacks because the hashes are signed, right?
1982019-11-26T19:40:43  <devrando1> (vs MACs)
1992019-11-26T19:40:45  <ariard_> sipa: yes I see, the problem is back to finding a collision in subhashes like you said
2002019-11-26T19:40:46  <sipa> devrando1: length extension attacks apply to MACs
2012019-11-26T19:40:59  <sipa> devrando1: we do not use any of our hashes as MACs
2022019-11-26T19:41:19  <sipa> (specifically, a MAC implies there is a secret; all our data hashed is public)
2032019-11-26T19:41:46  <devrando1> got it
2042019-11-26T19:44:17  <sipa> there is a related problem to length extension attacks (and generally apllicable to the same kinds of constructions), namely that IF someone manages to find a collision in a hash function based on Merkle-Damgard, then that can cheaply be extended to be arbitrarily many collisions by suffixing the same data after it
2052019-11-26T19:44:30  <sipa> that's not called a length extension attack though
2062019-11-26T19:44:44  <sipa> and SHA256 is indeed susceptible to thay
2072019-11-26T19:45:09  <sipa> but bitcoin already relies on SHA256 being collision resistant entirely
2082019-11-26T19:45:40  *** andrewtoth_ has joined ##taproot-bip-review
2092019-11-26T19:47:04  *** _andrewtoth_ has quit IRC
2102019-11-26T19:47:13  <ariard_> could you use new public key types to have the public key enforcing hash_types on the signatures, like the "spending transaction must commit to nLockTime"?
2112019-11-26T19:47:37  <sipa> sure
2122019-11-26T19:47:56  <sipa> (all sighash currently already commit to nLockTime, though)
2132019-11-26T19:50:24  <ariard_> yeah but was thinking about more fine-grained hash_types and you would combined them to have a weak covenant
2142019-11-26T19:54:19  <nothingmuch> in bip-schnorr, scalars k and e and are used mod n, the curve order, whereas in bip-taproot t (tap tweak hash) is constrained to be less than n. why is it curve order and not field size? why do these differ? doesn't bip-schnorr footnote 10 apply to all?
2152019-11-26T19:55:16  <nothingmuch> "why do these these differ" refers to the difference in handling of k and e vs. t
2162019-11-26T19:57:12  <sipa> nothingmuch: it's modulo n because they're all integers modulo n
2172019-11-26T19:57:23  <sipa> forgot that we're using elliptic curves
2182019-11-26T19:57:36  <sipa> the field size is only relevant to the specific implementation of the elliptic curve we pick
2192019-11-26T19:58:08  <sipa> but for anything "higher level" construction (including schnorr signatures and the taproot tweak), all that matters is how many elements there are in that group - which is n
2202019-11-26T20:01:00  *** jonatack_ has joined ##taproot-bip-review
2212019-11-26T20:01:17  <sipa> ok, have to run
2222019-11-26T20:01:25  * devrando1 waves
2232019-11-26T20:01:30  <kabaum> Thank you!
2242019-11-26T20:01:32  <nothingmuch> thanks
2252019-11-26T20:01:42  <jonatack_> thanks
2262019-11-26T20:02:00  <aj> #endmeeting
2272019-11-26T20:02:00  <lightningbot> Meeting ended Tue Nov 26 20:02:00 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
2282019-11-26T20:02:00  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.html
2292019-11-26T20:02:00  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.txt
2302019-11-26T20:02:00  <lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.log.html
2312019-11-26T20:02:03  *** devrando1 has quit IRC
2322019-11-26T20:03:14  <nothingmuch> hmm, so why is t not mod n?
2332019-11-26T20:03:15  <gmaxwell> nothingmuch: scalar's k and e are used to number curve points. There are n curve points (including the point at infinity).
2342019-11-26T20:04:06  <gmaxwell> nothingmuch: it is.
2352019-11-26T20:04:07  <gmaxwell> Let t = hashTapTweak(p || km).
2362019-11-26T20:04:07  <gmaxwell> If t ≥ 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 (order of secp256k1), fail.
2372019-11-26T20:05:08  <sipa> i think why nothingmuch is asking why it fails when it overflows, rather than interpreting modulo n
2382019-11-26T20:05:13  *** jonatack has quit IRC
2392019-11-26T20:05:22  <nothingmuch> yes, and was just trying to figure out how to rephrase it more clearly. thank you!
2402019-11-26T20:05:32  <sipa> the answer is it doesn't really matter much - we could make it more consistent actually
2412019-11-26T20:05:54  <sipa> because hitting the case is as hard as creating a collision in SHA256
2422019-11-26T20:06:56  <gmaxwell> In the case of K  doing anything but rejection sampling would look dangerous, because for other common curves where n isn't very close to a power of 2, doing a mod there creates an exploitable bias.
2432019-11-26T20:07:19  <gmaxwell> Other cases don't matter much, though you can debate which handling results in less risk of implementation inconsistency.
2442019-11-26T20:07:55  <gmaxwell> I have a general preference for rejection, we've gone back and forth about this in varrious places.
2452019-11-26T20:09:48  <sipa> one argument is simply implementation: what do we expect is easiest to implement
2462019-11-26T20:13:32  <sipa> gmaxwell: i think there is a distinction between the signing side and verification side
2472019-11-26T20:13:52  <sipa> or rather, whether it's on secret values of public values
2482019-11-26T20:14:47  <sipa> for secret values (nonce, private key) you must do rejection sampling, so the nonce generation algorithm must fail for out of range values (which for secp256k1 is still unobservable)
2492019-11-26T20:15:14  <sipa> for things like e and t which are public and known at verification time, using mod n is possibly simpler than saying they cause failure
2502019-11-26T20:29:07  *** rottensox has joined ##taproot-bip-review
2512019-11-26T20:30:16  <gmaxwell> possibly, though we've seen elsewhere that mod-n isn't always implemented correctly, consistently. Secp256k1's n is close enough to (2^8)^32 that it's probably not a big concern.
2522019-11-26T20:31:11  <gmaxwell> But, for example, in ed25519 implementations handle mod n of the scalar in the signature incorrectly after deserializing, resulting in mutiple mutually incompatible implementations some of which accept malleated signatures.
2532019-11-26T20:31:38  <midnight> yikes :-/
2542019-11-26T20:31:44  <gmaxwell> in any case, I don't mean to argue for one or the other.
2552019-11-26T20:32:03  <gmaxwell> From an auditing perspective, the test is easy to look for-- easier than verifying the modular reduction is done correctly, I think... because it's explicit.
2562019-11-26T20:32:58  <gmaxwell> The only strong position I have on non-secret values is that important thing is just that it is handled in some intentional way and documented clearly.
2572019-11-26T20:33:52  <gmaxwell> For secret values I think its important to use rejection sampling even though n is so close to 2^256,  an auditer shouldn't be burned with having to convince themselves that the statistical distinction is irrelevantly small in all use cases (though I'm convinced of that).
2582019-11-26T20:53:45  *** dr-orlovsky has quit IRC
2592019-11-26T21:20:17  *** Chris_Stewart_5 has quit IRC
2602019-11-26T21:31:46  *** pyskell has quit IRC
2612019-11-26T21:36:15  *** devrando1 has joined ##taproot-bip-review
2622019-11-26T21:37:01  *** jonatack_ has quit IRC
2632019-11-26T21:37:20  *** jonatack has joined ##taproot-bip-review
2642019-11-26T21:40:04  *** dr-orlovsky has joined ##taproot-bip-review
2652019-11-26T21:44:47  *** dr-orlovsky has quit IRC
2662019-11-26T21:50:16  *** dr-orlovsky has joined ##taproot-bip-review
2672019-11-26T22:03:25  *** dr_orlovsky has joined ##taproot-bip-review
2682019-11-26T22:05:57  *** dr-orlovsky has quit IRC
2692019-11-26T22:14:01  *** devrando1 has quit IRC
2702019-11-26T22:19:25  *** afk11 has quit IRC
2712019-11-26T22:21:31  *** afk11 has joined ##taproot-bip-review
2722019-11-26T22:43:42  *** b10c has quit IRC
2732019-11-26T23:15:10  *** andytoshi has quit IRC
2742019-11-26T23:21:16  *** Chris_Stewart_5 has joined ##taproot-bip-review
2752019-11-26T23:38:35  *** Chris_Stewart_5 has quit IRC
2762019-11-26T23:41:53  *** devrando1 has joined ##taproot-bip-review