Tweak DLEq README and rename the experimental_cross_group feature to just experimental

crypto/dleq/Cargo.toml

@@ -31,7 +31,7 @@ transcript = { package = "flexible-transcript", path = "../transcript", features
 
 [features]
 serialize = []
-experimental_cross_group = ["multiexp"]
+experimental = ["multiexp"]
 secure_capacity_difference = []
 
 # Only applies to cross_group, yet is default to ensure security

crypto/dleq/README.md

@@ -1,19 +1,19 @@
 # Discrete Log Equality
 
-Implementation of discrete log equality both within a group and across groups,
+Implementation of discrete log equality proofs for curves implementing
-the latter being extremely experimental, for curves implementing the ff/group
+`ff`/`group`. There is also a highly experimental cross-group DLEq proof, under
-APIs. This library has not undergone auditing and the cross-group DLEq proof has
+the `experimental` feature, which has no formal proofs available yet is
-no formal proofs available.
+available here regardless. This library has NOT undergone auditing.
 
 ### Cross-Group DLEq
 
 The present cross-group DLEq is based off
 [MRL-0010](https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf),
 which isn't computationally correct as while it proves both keys have the same
-discrete-log value for the G'/H' component, yet doesn't prove a lack of a G/H
+discrete logarithm for their `G'`/`H'` component, it doesn't prove a lack of a
-component. Accordingly, it was augmented with a pair of Schnorr Proof of
+`G`/`H` component. Accordingly, it was augmented with a pair of Schnorr Proof of
-Knowledges, proving a known G'/H' component, guaranteeing a lack of a G/H
+Knowledges, proving a known `G'`/`H'` component, guaranteeing a lack of a
-component (assuming an unknown relation between G/H and G'/H').
+`G`/`H` component (assuming an unknown relation between `G`/`H` and `G'`/`H'`).
 
 The challenges for the ring signatures were also merged, removing one-element
 from each bit's proof with only a slight reduction to challenge security (as
@@ -32,18 +32,19 @@ The following variants are available:
   signature size for both bits yet decreasing the amount of
   commitments/challenges in total.
 
-- `EfficientLinear`. This provides ring signatures in the form ((R_G, R_H), s),
+- `EfficientLinear`. This provides ring signatures in the form
-  instead of (e, s), and accordingly enables a batch verification of their final
+  `((R_G, R_H), s)`, instead of `(e, s)`, and accordingly enables a batch
-  step. It is the most performant, and also the largest, option.
+  verification of their final step. It is the most performant, and also the
+  largest, option.
 
-- `CompromiseLinear`. This provides signatures in the form ((R_G, R_H), s) AND
+- `CompromiseLinear`. This provides signatures in the form `((R_G, R_H), s)` AND
   proves for 2-bits at a time. While this increases the amount of steps in
   verifying the ring signatures, which aren't batch verified, and decreases the
   amount of items batched (an operation which grows in efficiency with
   quantity), it strikes a balance between speed and size.
 
-The following numbers are from benchmarks performed with Secp256k1/Ed25519 on a
+The following numbers are from benchmarks performed with k256/curve25519_dalek
-Intel i7-118567:
+on a Intel i7-118567:
 
 | Algorithm          | Size                    | Performance       |
 |--------------------|-------------------------|-------------------|
@@ -52,11 +53,11 @@ Intel i7-118567:
 | `EfficientLinear`  | 65145 bytes (+46%)      | 122ms (-22%)      |
 | `CompromiseLinear` | 48765 bytes  (+9%)      | 137ms (-12%)      |
 
-CompromiseLinear is the best choce by only being marginally sub-optimal
+`CompromiseLinear` is the best choice by only being marginally sub-optimal
 regarding size, yet still achieving most of the desired performance
 improvements. That said, neither the original postulation (which had flaws) nor
 any construction here has been proven nor audited. Accordingly, they are solely
 experimental, and none are recommended.
 
-All proofs are suffixed Linear in the hope a logarithmic proof makes itself
+All proofs are suffixed "Linear" in the hope a logarithmic proof makes itself
 available, which would likely immediately become the most efficient option.

crypto/dleq/src/lib.rs

@@ -9,7 +9,7 @@ use group::prime::PrimeGroup;
 #[cfg(feature = "serialize")]
 use std::io::{self, ErrorKind, Error, Read, Write};
 
-#[cfg(feature = "experimental_cross_group")]
+#[cfg(feature = "experimental")]
 pub mod cross_group;
 
 #[cfg(test)]

crypto/dleq/src/tests/mod.rs

@@ -1,4 +1,4 @@
-#[cfg(feature = "experimental_cross_group")]
+#[cfg(feature = "experimental")]
 mod cross_group;
 
 use hex_literal::hex;