* Use a struct in an enum for Bulletproofs
* verification bp working for just one proof
* add some more assert tests
* Clean BP verification
* Implement batch verification
* Add a debug assertion w_cache isn't 0
It's initially set to 0 and if not updated, this would be broken.
* Correct Monero workflow yaml
* Again try to corrent Monero workflow yaml
* Again
* Finally
* Re-apply weights as required by Bulletproofs
Removing these was insecure and my fault.
Co-authored-by: DangerousFreedom <dangfreed@tutanota.com>
* Initial stab at Bulletproofs+
Does move around the existing Bulletproofs code, does still work as
expected.
* Make the Clsag RCTPrunable type work with BP and BP+
* Initial set of BP+ bug fixes
* Further bug fixes
* Remove RING_LEN as a constant
* Monero v16 TX support
Doesn't implement view tags, nor going back to v14, nor the updated BP
clawback logic.
* Support v14 and v16 at the same time
Introduces missing CLSAG checks. The only difference now should be the
additional rejection of torsioned points, which is relevant to
https://github.com/serai-dex/serai/issues/25. Considering this is only
currently used for FROST verification, this should be fine.
Closes https://github.com/serai-dex/serai/issues/19 by making it
irrelevant.
Increases priority of https://github.com/serai-dex/serai/issues/68, as
now it's used for the BP generators which are done at first-proof.
Also merges BP's stricter hash_to_point with the library's, since CLSAG
has the same bound.
* Initial attempt at Bulletproofs
I don't know why this doesn't work. The generators and hash_cache lines
up without issue. AFAICT, the inner product proof is valid as well, as
are all included formulas.
* Add yinvpow asserts
* Clean code
* Correct bad imports
* Fix the definition of TWO_N
Bulletproofs work now :D
* Tidy up a bit
* fmt + clippy
* Compile a variety of XMR dependencies with optimizations, even under dev
The Rust bulletproof implementation is 8% slower than C right now, under
release. This is acceptable, even if suboptimal. Under debug, they take
a quarter of a second to two seconds though, depending on the amount of
outputs, which justifies this move.
* Remove unnecessary deref in BPs
Currently intended to be done with:
cargo clippy --features "recommended merlin batch serialize experimental
ed25519 ristretto p256 secp256k1 multisig" -- -A clippy::type_complexity
-A dead_code
The two-generator limit wasn't required nor beneficial. This does
theoretically optimize FROST, yet not for any current constructions. A
follow up proof which would optimize current constructions has been
noted in #38.
Adds explicit no_std support to the core DLEq proof.
Closes#34.
While Serai only needs the simple DLEq which was already present under
monero, this migrates the implementation of the cross-group DLEq I
maintain into Serai. This was to have full access to the ecosystem of
libraries built under Serai while also ensuring support for it.
The cross_group curve, which is extremely experimental, is feature
flagged off. So is the built in serialization functionality, as this
should be possible to make nostd once const generics are full featured,
yet the implemented serialization adds the additional barrier of
std::io.
Increases usage of standardization while expanding dalek_ff_group.
Closes https://github.com/serai-dex/serai/issues/26 by moving
dfg::EdwardsPoint to only be for the prime subgroup.
Updates how change outputs are handled, with a far more logical
construction offering greater flexibility.
prepare_outputs can not longer error. SignaableTransaction::new will.
Modifies FROST behavior so group_key has the offset applied regardless
of if view was called. The unaltered secret_share and
verification_shares (as they have differing values depending on the
signing set) are no longer publicly accessible.
Doesn't fully utilize ec's hash2curve module as k256 Scalar doesn't have
FromOkm for some reason. The previously present bigint reduction is
preserved.
Updates ff/group to 0.12.
Premised on https://github.com/cfrg/draft-irtf-cfrg-frost/pull/205 being
merged, as while this Ed25519 is vector compliant, it's technically not
spec compliant due to that conflict.
While it was fine as-is, as it only had one variable length property,
this is a bit more robust. Also binds the Curve ID, which should declare
differently even for just different basepoints, and therefore adds two
variable length properties (justifying the transcript).
No functional changes have been made to signing, with solely slight API
changes being made.
Technically not actually FROST v5 compatible, due to differing on zero
checks and randomness, yet the vectors do confirm the core algorithm.
For any valid FROST implementation, this will be interoperable if they
can successfully communicate. For any devious FROST implementation, this
will be fingerprintable, yet should still be valid.
Relevant to https://github.com/serai-dex/serai/issues/9 as any curve can
now specify vectors for itself and be tested against them.
Moves the FROST testing curve from k256 to p256. Does not expose p256
despite being compliant. It's not at a point I'm happy with it, notably
regarding hash to curve, and I'm not sure I care to support p256. If it
has value to the larger FROST ecosystem...
It was never used as we derive entropy via the other fields in the
transcript, and explicitly add fields directly as needed for entropy.
Also drops an unused crate and corrects a bug in FROST's Schnorr
implementation which used the Group's generator, instead of the Curve's.
Also updates the Monero crate's description.
Also updates Bulletproofs from C to not be length prefixed, yet rather
have Rust calculate their length.
Corrects an error in key_gen where self was blamed, instead of the
faulty participant.
Saves roughly 0.8s when running the tests, which took 16.6s and now take
15.8 (5%).
Removes the larger sample size, which replaced the closest selected
decoy with the real spend, per advice of Rucknium.
Saves ~8% during FROST key gen, even with dropping a vartime for a
constant time (as needed to be secure), as the new batch verifier is
used where batch verification previously wasn't. The new multiexp API
itself also offered a very slight performance boost, which may solely be
a measurement error.
Handles most of https://github.com/serai-dex/serai/issues/10. The blame
function isn't binary searched nor randomly sorted yet.
Changes the output index to a u8. While it may expand to a u16 at some
point, this can remain canonical using little endian serialization while
dropping the latter byte if it's 0 (or simply only using u16 when it's
actually possible).
Honestly, the borrowed keys are frustrating, and this probably reduces
performance while no longer offering an order when iterating. That said,
they enable full u16 indexing and should mildly improve the API.
Cleans the Proof of Knowledge handling present in key gen.
Currently solely used for single signer change outputs, intended to be
used for funds into Serai and multisig change outputs (dependent on #2).
Also cleans the file layout, makes scanning a bit more robust, doesn't
return outputs of amount 0, and shuffles outputs.
Remove's CLSAG's msg Rc for the msg available through AlgorithmMachine.
Potentially slightly more inefficient, as it needs to be converted from
a slice to a [u8; 32], yet removes a re-impl.
Also removes a match for an if.
Updates decoy selection with an explicit panic, the removal of a divide
by 0 (causing tests to fail on new chains), and a minor optimization
when dealing with a large quantity of locked outputs.
Also increases documentation, acknowledging infinite loops and breakage
from Monero more.
While all the transcript/extension code works as expected, which means,
they don't cause any conflicts, n was still capped at u64::MAX at
creation when it needs to be u16. Furthermore, participant index and
scalars/points were little endian instead of big endian/curve dependent.
Updates CLSAG signing as needed. Moves around Error types.
CLSAG multisig and the multisig feature is currently completely borked
because of this. The created TXs are accepted by Monero nodes.
