lazy_static, if no_std environments were used, effectively required always
using spin locks. This resolves the ergonomics of that while adopting Rust std
code.
no_std does still use a spin based solution. Theoretically, we could use
atomics, yet writing our own Mutex wasn't a priority.
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
* Initial work on an In Inherents pallet
* Add an event for when a batch is executed
* Add a dummy provider for InInstructions
* Add in-instructions to the node
* Add the Serai runtime API to the processor
* Move processor tests around
* Build a subxt Client around Serai
* Successfully get Batch events from Serai
Renamed processor/substrate to processor/serai.
* Much more robust InInstruction pallet
* Implement the workaround from https://github.com/paritytech/subxt/issues/602
* Initial prototype of processor generated InInstructions
* Correct PendingCoins data flow for InInstructions
* Minor lint to in-instructions
* Remove the global Serai connection for a partial re-impl
* Correct ID handling of the processor test
* Workaround the delay in the subscription
* Make an unwrap an if let Some, remove old comments
* Lint the processor toml
* Rebase and update
* Move substrate/in-instructions to substrate/in-instructions/pallet
* Start an in-instructions primitives lib
* Properly update processor to subxt 0.24
Also corrects failures from the rebase.
* in-instructions cargo update
* Implement IsFatalError
* is_inherent -> true
* Rename in-instructions crates and misc cleanup
* Update documentation
* cargo update
* Misc update fixes
* Replace height with block_number
* Update processor src to latest subxt
* Correct pipeline for InInstructions testing
* Remove runtime::AccountId for serai_primitives::NativeAddress
* Rewrite the in-instructions pallet
Complete with respect to the currently written docs.
Drops the custom serializer for just using SCALE.
Makes slight tweaks as relevant.
* Move instructions' InherentDataProvider to a client crate
* Correct doc gen
* Add serde to in-instructions-primitives
* Add in-instructions-primitives to pallet
* Heights -> BlockNumbers
* Get batch pub test loop working
* Update in instructions pallet terminology
Removes the ambiguous Coin for Update.
Removes pending/artificial latency for furture client work.
Also moves to using serai_primitives::Coin.
* Add a BlockNumber primitive
* Belated cargo fmt
* Further document why DifferentBatch isn't fatal
* Correct processor sleeps
* Remove metadata at compile time, add test framework for Serai nodes
* Remove manual RPC client
* Simplify update test
* Improve re-exporting behavior of serai-runtime
It now re-exports all pallets underneath it.
* Add a function to get storage values to the Serai RPC
* Update substrate/ to latest substrate
* Create a dedicated crate for the Serai RPC
* Remove unused dependencies in substrate/
* Remove unused dependencies in coins/
Out of scope for this branch, just minor and path of least resistance.
* Use substrate/serai/client for the Serai RPC lib
It's a bit out of place, since these client folders are intended for the node to
access pallets and so on. This is for end-users to access Serai as a whole.
In that sense, it made more sense as a top level folder, yet that also felt
out of place.
* Move InInstructions test to serai-client for now
* Final cleanup
* Update deny.toml
* Cargo.lock update from merging develop
* Update nightly
Attempt to work around the current CI failure, which is a Rust ICE.
We previously didn't upgrade due to clippy 10134, yet that's been reverted.
* clippy
* clippy
* fmt
* NativeAddress -> SeraiAddress
* Sec fix on non-provided updates and doc fixes
* Add Serai as a Coin
Necessary in order to swap to Serai.
* Add a BlockHash type, used for batch IDs
* Remove origin from InInstruction
Makes InInstructionTarget. Adds RefundableInInstruction with origin.
* Document storage items in in-instructions
* Rename serai/client/tests/serai.rs to updates.rs
It only tested publishing updates and their successful acceptance.
* convert AddressSpec subbaddress to tuple
* add wallet-rpc tests
* fix payment id decryption bug
* run fmt
* fix CI
* use monero-rs wallet-rpc for tests
* update the subaddress index type
* fix wallet-rpc CI
* fix monero-wallet-rpc CI actions
* pull latest monero for CI
* fix pr issues
* detach monero wallet rpc
Co-authored-by: Luke Parker <lukeparker5132@gmail.com>
Not only did we already have multiple booleans in it, yet it theoretically
could expand in the future. Not only is this more explicit, it actually cleans
some existing code.
commit e0a9e8825d6c22c797fb84e26ed6ef10136ca9c2
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Fri Jan 6 04:24:08 2023 -0500
Remove Scanner::address
It either needed to return an Option, panic on misconfiguration, or return a
distinct Scanner type based on burning bug immunity to offer this API properly.
Panicking wouldn't be proper, and the Option<Address> would've been... awkward.
The new register_subaddress function, maintaining the needed functionality,
also provides further clarity on the intended side effect of the previously
present Scanner::address function.
commit 7359360ab2fc8c9255c6f58250c214252ce217a4
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Fri Jan 6 01:35:02 2023 -0500
fmt/clippy from last commit
commit 80d912fc19cd268f3b019a9d9961a48b2c45e828
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Thu Jan 5 19:36:49 2023 -0500
Add Substrate "assets" pallet
While over-engineered for our purposes, it's still usable.
Also cleans the runtime a bit.
commit 2ed2944b6598d75bdc3c995aaf39b717846207de
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Wed Jan 4 23:09:58 2023 -0500
Remove the timestamp pallet
It was needed for contracts, which has since been removed. We now no longer
need it.
commit 7fc1fc2dccecebe1d94cb7b4c00f2b5cb271c87b
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Wed Jan 4 22:52:41 2023 -0500
Initial validator sets pallet (#187)
* Initial work on a Validator Sets pallet
* Update Validator Set docs per current discussions
* Update validator-sets primitives and storage handling
* Add validator set pallets to deny.toml
* Remove Curve from primitives
Since we aren't reusing keys across coins, there's no reason for it to be
on-chain (as previously planned).
* Update documentation on Validator Sets
* Use Twox64Concat instead of Identity
Ensures an even distribution of keys. While xxhash is breakable, these keys
aren't manipulatable by users.
* Add math ops on Amount and define a coin as 1e8
* Add validator-sets to the runtime and remove contracts
Also removes the randomness pallet which was only required by the contracts
runtime.
Does not remove the contracts folder yet so they can still be referred to while
validator-sets is under development. Does remove them from Cargo.toml.
* Add vote function to validator-sets
* Remove contracts folder
* Create an event for the Validator Sets pallet
* Remove old contracts crates from deny.toml
* Remove line from staking branch
* Remove staking from runtime
* Correct VS Config in runtime
* cargo update
* Resolve a few PR comments on terminology
* Create a serai-primitives crate
Move types such as Amount/Coin out of validator-sets. Will be expanded in the
future.
* Fixes for last commit
* Don't reserve set 0
* Further fixes
* Add files meant for last commit
* Remove Staking transfer
commit 3309295911d22177bd68972d138aea2f8658eb5f
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Wed Jan 4 06:17:00 2023 -0500
Reorder coins in README by market cap
commit db5d19cad33ccf067d876b7f5b7cca47c228e2fc
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Wed Jan 4 06:07:58 2023 -0500
Update README
commit 606484d744b1c6cc408382994c77f1def25d3e7d
Author: Luke Parker <lukeparker5132@gmail.com>
Date: Wed Jan 4 03:17:36 2023 -0500
cargo update
commit 3a319b229f
Author: akildemir <aeg_asd@hotmail.com>
Date: Wed Jan 4 16:26:25 2023 +0300
update address public API design
commit d9fa88fa76
Author: akildemir <aeg_asd@hotmail.com>
Date: Mon Jan 2 13:35:06 2023 +0300
fix clippy error
commit cc722e897b
Merge: cafa9b3eeca440
Author: akildemir <aeg_asd@hotmail.com>
Date: Mon Jan 2 11:39:04 2023 +0300
Merge https://github.com/serai-dex/serai into develop
commit cafa9b361e
Author: akildemir <aeg_asd@hotmail.com>
Date: Mon Jan 2 11:38:26 2023 +0300
fix build errors
commit ce5b5f2b37
Merge: f502d6749c4acf
Author: akildemir <aeg_asd@hotmail.com>
Date: Sun Jan 1 15:16:25 2023 +0300
Merge https://github.com/serai-dex/serai into develop
commit f502d67282
Author: akildemir <aeg_asd@hotmail.com>
Date: Thu Dec 22 13:13:09 2022 +0300
fix pr issues
commit 26ffb226d4
Author: akildemir <aeg_asd@hotmail.com>
Date: Thu Dec 22 13:11:43 2022 +0300
remove extraneous rpc call
commit 0e829f8531
Author: akildemir <aeg_asd@hotmail.com>
Date: Thu Dec 15 13:56:53 2022 +0300
add scan tests
commit 5123c7f121
Author: akildemir <aeg_asd@hotmail.com>
Date: Thu Dec 15 13:56:13 2022 +0300
add new address functions & comments
* Remove the explicit included participants from FROST
Now, whoever submits preprocesses becomes the signing set. Better separates
preprocess from sign, at the cost of slightly more annoying integrations
(Monero needs to now independently lagrange/offset its key images).
* Support caching preprocesses
Closes https://github.com/serai-dex/serai/issues/40.
I *could* have added a serialization trait to Algorithm and written a ton of
data to disk, while requiring Algorithm implementors also accept such work.
Instead, I moved preprocess to a seeded RNG (Chacha20) which should be as
secure as the regular RNG. Rebuilding from cache simply loads the previously
used Chacha seed, making the Algorithm oblivious to the fact it's being
rebuilt from a cache. This removes any requirements for it to be modified
while guaranteeing equivalency.
This builds on the last commit which delayed determining the signing set till
post-preprocess acquisition. Unfortunately, that commit did force preprocess
from ThresholdView to ThresholdKeys which had visible effects on Monero.
Serai will actually need delayed set determination for #163, and overall,
it remains better, hence it's inclusion.
* Document FROST preprocess caching
* Update ethereum to new FROST
* Fix bug in Monero offset calculation and update processor
A type alias of MoneroAddress is provided to abstract away the generic.
To keep the rest of the library sane, MoneroAddress is used everywhere.
If someone wants to use this library with another coin, they *should* be
able to parse a custom address and then recreate it as a Monero address.
While that's annoying to them, better them than any person using this
lib for Monero.
Closes#152.
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
* 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
Updates how change outputs are handled, with a far more logical
construction offering greater flexibility.
prepare_outputs can not longer error. SignaableTransaction::new will.
