1 2019-11-26T01:11:44  *** rottensox has quit IRC
  2 2019-11-26T01:12:07  *** rottensox has joined ##taproot-bip-review
  3 2019-11-26T01:22:33  *** Chris_Stewart_5 has quit IRC
  4 2019-11-26T01:26:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
  5 2019-11-26T02:37:57  *** Chris_Stewart_5 has quit IRC
  6 2019-11-26T03:02:16  *** ZmnSCPxj_ has joined ##taproot-bip-review
  7 2019-11-26T03:19:54  *** pinheadmz_ has joined ##taproot-bip-review
  8 2019-11-26T03:23:14  *** pinheadmz has quit IRC
  9 2019-11-26T03:23:15  *** pinheadmz_ is now known as pinheadmz
 10 2019-11-26T03:57:02  *** jonatack_ has quit IRC
 11 2019-11-26T04:24:06  *** pinheadmz has quit IRC
 12 2019-11-26T04:28:30  *** pinheadmz has joined ##taproot-bip-review
 13 2019-11-26T04:49:27  *** luke-jr has quit IRC
 14 2019-11-26T05:13:15  *** ZmnSCPxj__ has joined ##taproot-bip-review
 15 2019-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`.
 16 2019-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.
 17 2019-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.
 18 2019-11-26T05:22:49  *** luke-jr has joined ##taproot-bip-review
 19 2019-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.
 20 2019-11-26T05:22:54  <ZmnSCPxj__> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
 21 2019-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.
 22 2019-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.
 23 2019-11-26T05:30:29  *** yaslama_ has quit IRC
 24 2019-11-26T05:30:45  *** yaslama has joined ##taproot-bip-review
 25 2019-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
 26 2019-11-26T05:32:05  <ZmnSCPxj__> Then on claiming the forwardee adds another transaction that spends that HTLC.
 27 2019-11-26T05:32:27  <ZmnSCPxj__> And *then* the channel mechanism is used to cut through the intermediate transactions
 28 2019-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.
 29 2019-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.
 30 2019-11-26T05:55:18  *** rottensox_ has joined ##taproot-bip-review
 31 2019-11-26T05:57:42  *** rottensox has quit IRC
 32 2019-11-26T05:58:51  *** rottensox__ has joined ##taproot-bip-review
 33 2019-11-26T05:59:18  *** dr-orlovsky has quit IRC
 34 2019-11-26T06:01:19  *** rottensox_ has quit IRC
 35 2019-11-26T06:27:59  *** jonatack_ has joined ##taproot-bip-review
 36 2019-11-26T06:28:15  *** jonatack_ has quit IRC
 37 2019-11-26T06:28:32  *** jonatack has joined ##taproot-bip-review
 38 2019-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
 39 2019-11-26T07:29:27  *** ZmnSCPxj__ has quit IRC
 40 2019-11-26T07:44:45  *** rottensox__ has quit IRC
 41 2019-11-26T08:01:04  *** jonatack_ has joined ##taproot-bip-review
 42 2019-11-26T08:04:41  *** jonatack has quit IRC
 43 2019-11-26T08:08:24  *** hebasto has quit IRC
 44 2019-11-26T08:08:49  *** hebasto has joined ##taproot-bip-review
 45 2019-11-26T08:14:01  *** ZmnSCPxj___ has joined ##taproot-bip-review
 46 2019-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.
 47 2019-11-26T08:16:21  <ZmnSCPxj___> However fast forward requires symmetrical  CSVs, I believe there was an argument recently against syemmtrical CSVs.
 48 2019-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
 49 2019-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....
 50 2019-11-26T08:41:00  <ZmnSCPxj___> I mean in relation to Poon-Dryja, not Decker-Russell-Osuntokun
 51 2019-11-26T08:41:34  <ZmnSCPxj___> Taproot use for Decker-Russell-Osuntokun has had some discussion, but potentially not enough.
 52 2019-11-26T08:44:49  <aj> ZmnSCPxj___: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001038.html
 53 2019-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
 54 2019-11-26T08:47:02  *** jeremyrubin has quit IRC
 55 2019-11-26T08:48:50  *** b10c has joined ##taproot-bip-review
 56 2019-11-26T08:50:48  <ZmnSCPxj___> Your first link seems to point only to Schnorr, not *taproot*, so...................
 57 2019-11-26T08:50:50  <ZmnSCPxj___> :)
 58 2019-11-26T08:52:32  <ZmnSCPxj___> as does the second; it is about scriptless script, not tapscript, I think.
 59 2019-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.
 60 2019-11-26T08:53:53  <ZmnSCPxj___> Even revocation I believe could be done with scriptless script.
 61 2019-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.
 62 2019-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.
 63 2019-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.
 64 2019-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
 65 2019-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
 66 2019-11-26T09:12:26  *** achow101 has quit IRC
 67 2019-11-26T09:15:19  *** CubicEarth has quit IRC
 68 2019-11-26T09:18:33  *** CubicEarth has joined ##taproot-bip-review
 69 2019-11-26T09:39:43  *** achow101 has joined ##taproot-bip-review
 70 2019-11-26T09:49:10  *** CubicEarth has quit IRC
 71 2019-11-26T09:54:49  *** CubicEarth has joined ##taproot-bip-review
 72 2019-11-26T10:01:43  *** ZmnSCPxj___ has quit IRC
 73 2019-11-26T10:23:10  *** jonatack_ has quit IRC
 74 2019-11-26T10:23:27  *** jonatack has joined ##taproot-bip-review
 75 2019-11-26T10:41:17  *** CubicEarth has quit IRC
 76 2019-11-26T10:54:30  *** CubicEarth has joined ##taproot-bip-review
 77 2019-11-26T11:17:40  <ZmnSCPxj_> gmaxwell: replicates the decrementing-`nSequence` mechanism in Decker Wattenhofer I think
 78 2019-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.
 79 2019-11-26T11:19:54  <ZmnSCPxj_> gmaxwell: could be interesting with `OP_SECURETHEBAG` / `OP_CHECKOUTPUTHASHVERIFY`?
 80 2019-11-26T11:33:33  *** Chris_Stewart_5 has joined ##taproot-bip-review
 81 2019-11-26T12:49:17  *** Chris_Stewart_5 has quit IRC
 82 2019-11-26T12:54:26  *** Chris_Stewart_5 has joined ##taproot-bip-review
 83 2019-11-26T13:22:50  *** dr-orlovsky has joined ##taproot-bip-review
 84 2019-11-26T13:28:42  *** Chris_Stewart_5 has quit IRC
 85 2019-11-26T13:40:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
 86 2019-11-26T13:48:45  *** kabaum has quit IRC
 87 2019-11-26T13:51:47  *** kabaum has joined ##taproot-bip-review
 88 2019-11-26T14:14:02  *** dr-orlovsky has quit IRC
 89 2019-11-26T15:09:36  *** dr-orlovsky has joined ##taproot-bip-review
 90 2019-11-26T15:10:37  *** pyskell has joined ##taproot-bip-review
 91 2019-11-26T15:15:41  *** pyskl has joined ##taproot-bip-review
 92 2019-11-26T15:19:06  *** pyskell has quit IRC
 93 2019-11-26T15:32:40  *** mryandao has quit IRC
 94 2019-11-26T15:32:58  *** mryandao has joined ##taproot-bip-review
 95 2019-11-26T16:17:11  *** andrewtoth_ has joined ##taproot-bip-review
 96 2019-11-26T17:09:05  *** andytoshi has joined ##taproot-bip-review
 97 2019-11-26T17:59:25  *** Chris_Stewart_5 has quit IRC
 98 2019-11-26T18:13:43  *** Chris_Stewart_5 has joined ##taproot-bip-review
 99 2019-11-26T18:36:40  *** _andrewtoth_ has joined ##taproot-bip-review
100 2019-11-26T18:38:00  *** andrewtoth_ has quit IRC
101 2019-11-26T18:42:40  *** _andrewtoth_ has quit IRC
102 2019-11-26T18:44:11  *** sipa has joined ##taproot-bip-review
103 2019-11-26T18:48:12  *** shesek has quit IRC
104 2019-11-26T18:48:35  *** shesek has joined ##taproot-bip-review
105 2019-11-26T18:48:35  *** shesek has joined ##taproot-bip-review
106 2019-11-26T19:01:10  *** pyskl is now known as pyskell
107 2019-11-26T19:01:16  <aj> #startmeeting
108 2019-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.
109 2019-11-26T19:01:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
110 2019-11-26T19:01:21  <pyskell> hi
111 2019-11-26T19:01:23  <nickler> hi
112 2019-11-26T19:01:27  <kabaum> hi
113 2019-11-26T19:01:37  *** pyskell has quit IRC
114 2019-11-26T19:01:37  *** pyskell has joined ##taproot-bip-review
115 2019-11-26T19:01:42  <aj> hi
116 2019-11-26T19:01:44  <fanquake> hi
117 2019-11-26T19:01:48  <sipa> hi
118 2019-11-26T19:01:52  <schmidty> hi
119 2019-11-26T19:03:41  <kabaum> Good to see you all again.
120 2019-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?
121 2019-11-26T19:04:19  <sipa> kabaum: partially the result of the fact that this existed before P2SH support was removed
122 2019-11-26T19:04:22  <ariard_> hi
123 2019-11-26T19:04:46  <sipa> because back then, scriptPubKey for a P2SH-taproot spend would actually contain the P2SH scriptPubKey
124 2019-11-26T19:04:54  <sipa> (rather than its redeemscript)
125 2019-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
126 2019-11-26T19:06:23  <jonatack> hi
127 2019-11-26T19:06:44  *** devrando1 has joined ##taproot-bip-review
128 2019-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
129 2019-11-26T19:07:50  <sipa> this specific example could have been fixed by just exactly committing to P2SH or not
130 2019-11-26T19:07:57  <sipa> but it is not the only example of such mutations
131 2019-11-26T19:08:08  <sipa> and they're all fixed by just committing to the scriptPubKey
132 2019-11-26T19:08:51  <sipa> so yes, we know it's always 34 bytes, and could thus drop the compactsize length that precedes it
133 2019-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
134 2019-11-26T19:09:30  <sipa> </monologue>
135 2019-11-26T19:10:51  <kabaum> So maybe it's better to not say "Its size is always 35 bytes" then?
136 2019-11-26T19:11:20  <sipa> well it is in the specific use in bip-taproot
137 2019-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?
138 2019-11-26T19:11:37  <sipa> ariard_: i don't understand
139 2019-11-26T19:11:42  <kabaum> sipa: sure
140 2019-11-26T19:12:12  <sipa> oh, i see
141 2019-11-26T19:12:13  <ariard_> sipa: let's say we want to have new hash_types, how would we introduce them?
142 2019-11-26T19:12:21  <sipa> ariard_: anyway you like
143 2019-11-26T19:12:24  <sipa> (if you find consensus)
144 2019-11-26T19:12:44  <ariard_> sure but the epoch would be the most fine-grained one ?
145 2019-11-26T19:13:06  <ariard_> compare to the leaf version
146 2019-11-26T19:13:16  <fjahr> hi
147 2019-11-26T19:13:23  <devrando1> hi
148 2019-11-26T19:13:24  <sipa> the epoch is not encoded anywhere, it's not an extension mechanism
149 2019-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
150 2019-11-26T19:14:25  <sipa> they can instead just set the epoch to another value, and then do whatever they want
151 2019-11-26T19:14:36  <sipa> without the risk of ever colliding with a bip-taproot sighash
152 2019-11-26T19:14:59  <ariard_> hmmm but at least in demo code epoch is hardcoded to zero?
153 2019-11-26T19:15:12  <sipa> it is not just hardcoded in the demo code to be zero
154 2019-11-26T19:15:18  <sipa> bip-taproot defines it to be zero
155 2019-11-26T19:15:19  <nickler> ariard_: the sighash_anyprevout hash type is proposed to be introduced with a new pubkey type
156 2019-11-26T19:15:35  <sipa> we could just not give it a name
157 2019-11-26T19:15:37  <sipa> it's just zero
158 2019-11-26T19:16:14  <ariard_> in SignatureHashSchnorr, epoch = 0
159 2019-11-26T19:16:19  <sipa> yes
160 2019-11-26T19:16:36  <sipa> and bip-taproot says:
161 2019-11-26T19:16:37  <sipa> epoch (1): always 0
162 2019-11-26T19:16:53  <ariard_> nickler: using key_version?
163 2019-11-26T19:17:06  <nickler> yeah
164 2019-11-26T19:17:11  <sipa> nickler: ariard_ is asking about epoch, not key version
165 2019-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
166 2019-11-26T19:18:11  <devrando1> the epoch is not serialized
167 2019-11-26T19:18:25  *** midnightmagic is now known as midnight
168 2019-11-26T19:18:37  *** arik_ has joined ##taproot-bip-review
169 2019-11-26T19:18:46  <devrando1> so you can't use it to communicate anything
170 2019-11-26T19:19:40  <devrando1> it's only part of the data bytes that are hashed, but it's a non-stored constant
171 2019-11-26T19:20:06  <sipa> i explained it more to ariard_ irl
172 2019-11-26T19:20:22  <sipa> but i think the epoch can use better justification in the text
173 2019-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
174 2019-11-26T19:21:27  <sipa> without risking collisions
175 2019-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
176 2019-11-26T19:22:28  <sipa> but as far as bip-taproot is concerned, it's not an extension mechanism; it's just a 0
177 2019-11-26T19:24:00  <kabaum> sipa: Now I get epoch. Thanks.
178 2019-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?
179 2019-11-26T19:25:22  <sipa> kabaum: you cannot commit to 32 zero bytes
180 2019-11-26T19:25:27  <sipa> there is no information in them
181 2019-11-26T19:25:47  <sipa> it's an implementation detail that the exact data hashed changed
182 2019-11-26T19:26:01  <sipa> but in terms of semantics, hashing 32 zero bytes never did anything
183 2019-11-26T19:26:24  <kabaum> I see.
184 2019-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.
185 2019-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.
186 2019-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?
187 2019-11-26T19:32:02  *** _andrewtoth_ has joined ##taproot-bip-review
188 2019-11-26T19:32:03  <ariard_> but they don't tell you the lenght of the variable length data parts, input outpoints, input amounts, ...?
189 2019-11-26T19:32:04  <sipa> ariard_: hmm, we may need to revise that
190 2019-11-26T19:32:30  <sipa> because scriptPubKey is no longer variable length
191 2019-11-26T19:33:07  <sipa> and all other variable length things have indirect commitments to their lengths using intermediate hashes
192 2019-11-26T19:33:27  <sipa> (e.g. the annex has its length committed to by being prehashed)
193 2019-11-26T19:34:39  <ariard_> okay is collision of final hash by tweaking indirect commitments an issue?
194 2019-11-26T19:35:50  <sipa> we assume we have a collision resistant hash function
195 2019-11-26T19:35:51  <sipa> so no
196 2019-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
197 2019-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?
198 2019-11-26T19:40:43  <devrando1> (vs MACs)
199 2019-11-26T19:40:45  <ariard_> sipa: yes I see, the problem is back to finding a collision in subhashes like you said
200 2019-11-26T19:40:46  <sipa> devrando1: length extension attacks apply to MACs
201 2019-11-26T19:40:59  <sipa> devrando1: we do not use any of our hashes as MACs
202 2019-11-26T19:41:19  <sipa> (specifically, a MAC implies there is a secret; all our data hashed is public)
203 2019-11-26T19:41:46  <devrando1> got it
204 2019-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
205 2019-11-26T19:44:30  <sipa> that's not called a length extension attack though
206 2019-11-26T19:44:44  <sipa> and SHA256 is indeed susceptible to thay
207 2019-11-26T19:45:09  <sipa> but bitcoin already relies on SHA256 being collision resistant entirely
208 2019-11-26T19:45:40  *** andrewtoth_ has joined ##taproot-bip-review
209 2019-11-26T19:47:04  *** _andrewtoth_ has quit IRC
210 2019-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"?
211 2019-11-26T19:47:37  <sipa> sure
212 2019-11-26T19:47:56  <sipa> (all sighash currently already commit to nLockTime, though)
213 2019-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
214 2019-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?
215 2019-11-26T19:55:16  <nothingmuch> "why do these these differ" refers to the difference in handling of k and e vs. t
216 2019-11-26T19:57:12  <sipa> nothingmuch: it's modulo n because they're all integers modulo n
217 2019-11-26T19:57:23  <sipa> forgot that we're using elliptic curves
218 2019-11-26T19:57:36  <sipa> the field size is only relevant to the specific implementation of the elliptic curve we pick
219 2019-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
220 2019-11-26T20:01:00  *** jonatack_ has joined ##taproot-bip-review
221 2019-11-26T20:01:17  <sipa> ok, have to run
222 2019-11-26T20:01:25  * devrando1 waves
223 2019-11-26T20:01:30  <kabaum> Thank you!
224 2019-11-26T20:01:32  <nothingmuch> thanks
225 2019-11-26T20:01:42  <jonatack_> thanks
226 2019-11-26T20:02:00  <aj> #endmeeting
227 2019-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)
228 2019-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
229 2019-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
230 2019-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
231 2019-11-26T20:02:03  *** devrando1 has quit IRC
232 2019-11-26T20:03:14  <nothingmuch> hmm, so why is t not mod n?
233 2019-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).
234 2019-11-26T20:04:06  <gmaxwell> nothingmuch: it is.
235 2019-11-26T20:04:07  <gmaxwell> Let t = hashTapTweak(p || km).
236 2019-11-26T20:04:07  <gmaxwell> If t ≥ 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 (order of secp256k1), fail.
237 2019-11-26T20:05:08  <sipa> i think why nothingmuch is asking why it fails when it overflows, rather than interpreting modulo n
238 2019-11-26T20:05:13  *** jonatack has quit IRC
239 2019-11-26T20:05:22  <nothingmuch> yes, and was just trying to figure out how to rephrase it more clearly. thank you!
240 2019-11-26T20:05:32  <sipa> the answer is it doesn't really matter much - we could make it more consistent actually
241 2019-11-26T20:05:54  <sipa> because hitting the case is as hard as creating a collision in SHA256
242 2019-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.
243 2019-11-26T20:07:19  <gmaxwell> Other cases don't matter much, though you can debate which handling results in less risk of implementation inconsistency.
244 2019-11-26T20:07:55  <gmaxwell> I have a general preference for rejection, we've gone back and forth about this in varrious places.
245 2019-11-26T20:09:48  <sipa> one argument is simply implementation: what do we expect is easiest to implement
246 2019-11-26T20:13:32  <sipa> gmaxwell: i think there is a distinction between the signing side and verification side
247 2019-11-26T20:13:52  <sipa> or rather, whether it's on secret values of public values
248 2019-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)
249 2019-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
250 2019-11-26T20:29:07  *** rottensox has joined ##taproot-bip-review
251 2019-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.
252 2019-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.
253 2019-11-26T20:31:38  <midnight> yikes :-/
254 2019-11-26T20:31:44  <gmaxwell> in any case, I don't mean to argue for one or the other.
255 2019-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.
256 2019-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.
257 2019-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).
258 2019-11-26T20:53:45  *** dr-orlovsky has quit IRC
259 2019-11-26T21:20:17  *** Chris_Stewart_5 has quit IRC
260 2019-11-26T21:31:46  *** pyskell has quit IRC
261 2019-11-26T21:36:15  *** devrando1 has joined ##taproot-bip-review
262 2019-11-26T21:37:01  *** jonatack_ has quit IRC
263 2019-11-26T21:37:20  *** jonatack has joined ##taproot-bip-review
264 2019-11-26T21:40:04  *** dr-orlovsky has joined ##taproot-bip-review
265 2019-11-26T21:44:47  *** dr-orlovsky has quit IRC
266 2019-11-26T21:50:16  *** dr-orlovsky has joined ##taproot-bip-review
267 2019-11-26T22:03:25  *** dr_orlovsky has joined ##taproot-bip-review
268 2019-11-26T22:05:57  *** dr-orlovsky has quit IRC
269 2019-11-26T22:14:01  *** devrando1 has quit IRC
270 2019-11-26T22:19:25  *** afk11 has quit IRC
271 2019-11-26T22:21:31  *** afk11 has joined ##taproot-bip-review
272 2019-11-26T22:43:42  *** b10c has quit IRC
273 2019-11-26T23:15:10  *** andytoshi has quit IRC
274 2019-11-26T23:21:16  *** Chris_Stewart_5 has joined ##taproot-bip-review
275 2019-11-26T23:38:35  *** Chris_Stewart_5 has quit IRC
276 2019-11-26T23:41:53  *** devrando1 has joined ##taproot-bip-review