01:16:34 I think the spy nodes may have finally updated their software, there are no spy nodes under digitalocean & there are nodes passing the spy nodes checks under LionLink: https://moneronet.info/ 01:18:32 so far it seems like ~200 nodes have switch sides 01:29:57 (removed) 01:29:58 (removed) 01:29:58 (removed) 01:29:58 (removed) 02:25:23 Yes it's equivalent > would doing s_sr = ConvertPointE(d_e * K^j_v) be equivalent? 02:27:18 To do s_sr = d_e ConvertPointE(K^j_v) and s_sr = ConvertPointE(d_e K^j_v) 02:28:04 That's interesting that the vartime ed25519 impl is faster, but I honestly can't imagine that this portion of transaction construction is a performance blocker compared to the FCMPs. 04:58:07 Nah, it's for p2pool output calculation context 04:58:40 At least on p2pool we don't need to do the FCMP just make the outputs 06:21:05 jeffro256: annotated my X25519 ScalarMult to clarify that only scalars mod l return valid results, and otherwise they behave as if scalar[31] &= 127 clamping is applied (even when carrot says it's unclamped). This matches mx25519 unclamped behavior and raw rust -dalek library. 06:21:07 https://git.gammaspectra.live/P2Pool/consensus/commit/e53b1cd70d6b9ac2335caf107beb3607d22b3aa0 06:21:14 Otherwise had failing tests on the custom test vectors when fuzzed 06:22:41 This may be obvious but when one reads https://github.com/jeffro256/carrot/blob/master/carrot.md#331-curve25519 06:22:41 > In this specification, when we mention scalar-point multiplication, we always mean a "full" scalar multiplication, without "scalar clamping" [15]. Most implementations of X25519 [16], an ECDH algorithm on Curve25519, will "clamp" the scalar, treating some bits implicitly as always 0s or always 1s. 06:22:57 one might think that no clamping at all is done, for full 255 bits 06:23:07 however later > the private view key could be any unclamped element of Fℓ 06:23:58 this then introduces the precondition of scalar being mod l, however, neither mx25519 fork or -dalek do verify this is the case 06:25:08 in real usage this would never be hit but when making unit tests you can have garbage data in garbage data out when specifying random scalars (unreduced) 08:13:24 (removed) 08:13:24 (removed) 08:13:24 (removed) 08:13:24 (removed) 08:20:06 <321bob321> Thanks mbll 08:28:17 > jeffro256: annotated my X25519 ScalarMult to clarify that only scalars mod l return valid results, and otherwise they behave as if scalar[31] &= 127 clamping is applied (even when carrot says it's unclamped). This matches mx25519 unclamped behavior and raw rust -dalek library. 08:28:17 What do you mean by "only scalars mod l return valid results"? X25519 can take any 32-bit array as a scalar and produce consistent scalar-point multiplications. Just because the 255th bit is ignored doesn't mean that scalars not mod l are invalid. I chose to not clamp the multiplication in Carrot because we need to support l [... too long, see https://mrelay.p2pool.observer/e/xK6e8sIKc2ZJdkVm ] 08:29:32 yeah, that's what I mean that for real usage the 255th bit is never set (mod l) 08:30:11 however the raw exposed function can take non-mod l scalars, which then have it's 255th bit ignored 08:31:08 this causes a split in tests testing for "full unclamped (all 255 bits are multiplied)" to "255th bit is clamped" (current behavior, which is ok behavior) 08:33:48 say scalar = a046e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4, point = e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c 08:33:50 mx25519 scalar mult gives c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552 08:33:52 unclamped scalar mult (not ignoring 255th bit) gives c1e8b5670164e2296fc04e4aec3bbd7b40b288d7a26f421a3a92afe6a5522939 08:34:52 I wouldn't mind as much as this is fine behavior, except the testcases explicitly then go and include tests with that bit set (against real world usage) so that 255th bit clamping should get documented 08:35:35 (those values are from mx25519 tests from the unclamped fork) 08:40:39 in a few implementations I looked up of the montgomery ladder used for the scalar mult of X25519, they have a comment around using 254 due to 255th bit being clamped between others, but the unclamped one uses the full 255 bits 08:42:14 This is a far point. I am considering tweaking the derivation of Carrot-derived k_v to do a field-wise clamp of a 32-byte array which would produce equivalent results if doing a true unclamped Curve25519 scalar-point mul with modified scalar or an RFC 7748 clamped scalar-point mul with unmodified scalar. It would give Carrot implementors flexibility with the libraries that they can choose. 08:42:20 Not that it's relevant as a citing but the Wikipedia example https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Constant_time_Montgomery_ladder does use for i from l - 1 downto 0 do where l-1 is 255 so this behavior could be repeated 08:43:01 DataHoarder: Yes according to RFC 7748, the 254th bit should always be set. mx25519 is non-conforming in this regard 08:44:21 right, yeah, that too, but here I was looking just at the 255th bit itself 08:45:53 in my case I had to lift the inner x25519 scalar mult then adapt it, yeah, would be nicer to use existing libraries for it (or just document it well with a test vector set) 08:46:26 I included your mx25519 fork test vectors here https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/crypto/curve25519/montgomery_test.go 08:48:09 > Not that it's relevant as a citing but the Wikipedia example https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Constant_time_Montgomery_ladder does use for i from l - 1 downto 0 do where l-1 is 255 so this behavior could be repeated 08:48:09 Yes a Montgomery ladder in general can do as many bits as your heart desires, but the X25519 and Carrot spec both ignore the 255th bit 08:48:41 DataHoarder: Why not just clamp the 255th bit and pass that to some other library ? 08:49:06 yes, clamping would be fine as well. But document it :) 08:49:59 document that X25519 clamping according to RFC is not done, instead 255th bit is clamped and rest are unclamped 08:58:06 in my case I have field elements to do the ladder with so I just imported the single function (and added the tests around it) 15:29:57 Updates: https://github.com/monero-project/research-lab/issues/151#issuecomment-3451901765