2024-09-11 02:46:18 -04:00
|
|
|
use core::fmt;
|
2024-09-10 06:25:21 -04:00
|
|
|
use std::collections::HashMap;
|
|
|
|
|
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
use ciphersuite::*;
|
2025-08-25 09:17:29 -04:00
|
|
|
use ciphersuite_kp256::Secp256k1;
|
2024-09-10 06:25:21 -04:00
|
|
|
|
|
|
|
|
use bitcoin_serai::bitcoin::block::{Header, Block as BBlock};
|
|
|
|
|
|
2025-11-04 19:02:37 -05:00
|
|
|
use serai_client_bitcoin::Address;
|
2024-09-10 06:25:21 -04:00
|
|
|
|
2024-09-11 02:46:18 -04:00
|
|
|
use serai_db::Db;
|
2024-09-10 06:25:21 -04:00
|
|
|
use primitives::{ReceivedOutput, EventualityTracker};
|
|
|
|
|
|
2024-09-10 07:07:09 -04:00
|
|
|
use crate::{hash_bytes, scan::scanner, output::Output, transaction::Eventuality};
|
2024-09-10 06:25:21 -04:00
|
|
|
|
|
|
|
|
#[derive(Clone, Debug)]
|
2024-09-10 07:07:09 -04:00
|
|
|
pub(crate) struct BlockHeader(pub(crate) Header);
|
2024-09-10 06:25:21 -04:00
|
|
|
impl primitives::BlockHeader for BlockHeader {
|
|
|
|
|
fn id(&self) -> [u8; 32] {
|
|
|
|
|
hash_bytes(self.0.block_hash().to_raw_hash())
|
|
|
|
|
}
|
|
|
|
|
fn parent(&self) -> [u8; 32] {
|
|
|
|
|
hash_bytes(self.0.prev_blockhash.to_raw_hash())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-09-11 02:46:18 -04:00
|
|
|
#[derive(Clone)]
|
|
|
|
|
pub(crate) struct Block<D: Db>(pub(crate) D, pub(crate) BBlock);
|
|
|
|
|
impl<D: Db> fmt::Debug for Block<D> {
|
|
|
|
|
fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
|
fmt.debug_struct("Block").field("1", &self.1).finish_non_exhaustive()
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-09-10 06:25:21 -04:00
|
|
|
|
2024-09-11 02:46:18 -04:00
|
|
|
impl<D: Db> primitives::Block for Block<D> {
|
2024-09-10 06:25:21 -04:00
|
|
|
type Header = BlockHeader;
|
|
|
|
|
|
Smash the singular `Ciphersuite` trait into multiple
This helps identify where the various functionalities are used, or rather, not
used. The `Ciphersuite` trait present in `patches/ciphersuite`, facilitating
the entire FCMP++ tree, only requires the markers _and_ canonical point
decoding. I've opened a PR to upstream such a trait into `group`
(https://github.com/zkcrypto/group/pull/68).
`WrappedGroup` is still justified for as long as `Group::generator` exists.
Moving `::generator()` to its own trait, on an independent structure (upstream)
would be massively appreciated. @tarcieri also wanted to update from
`fn generator()` to `const GENERATOR`, which would encourage further discussion
on https://github.com/zkcrypto/group/issues/32 and
https://github.com/zkcrypto/group/issues/45, which have been stagnant.
The `Id` trait is occasionally used yet really should be first off the chopping
block.
Finally, `WithPreferredHash` is only actually used around a third of the time,
which more than justifies it being a separate trait.
---
Updates `dalek_ff_group::Scalar` to directly re-export
`curve25519_dalek::Scalar`, as without issue. `dalek_ff_group::RistrettoPoint`
also could be replaced with an export of `curve25519_dalek::RistrettoPoint`,
yet the coordinator relies on how we implemented `Hash` on it for the hell of
it so it isn't worth it at this time. `dalek_ff_group::EdwardsPoint` can't be
replaced for an re-export of `curve25519_dalek::SubgroupPoint` as it doesn't
implement `zeroize`, `subtle` traits within a released, non-yanked version.
Relevance to https://github.com/serai-dex/serai/issues/201 and
https://github.com/dalek-cryptography/curve25519-dalek/issues/811#issuecomment-3247732746.
Also updates the `Ristretto` ciphersuite to prefer `Blake2b-512` over
`SHA2-512`. In order to maintain compliance with FROST's IETF standard,
`modular-frost` defines its own ciphersuite for Ristretto which still uses
`SHA2-512`.
2025-09-03 12:25:37 -04:00
|
|
|
type Key = <Secp256k1 as WrappedGroup>::G;
|
2024-09-10 06:25:21 -04:00
|
|
|
type Address = Address;
|
|
|
|
|
type Output = Output;
|
|
|
|
|
type Eventuality = Eventuality;
|
|
|
|
|
|
|
|
|
|
fn id(&self) -> [u8; 32] {
|
2024-09-11 02:46:18 -04:00
|
|
|
primitives::BlockHeader::id(&BlockHeader(self.1.header))
|
2024-09-10 06:25:21 -04:00
|
|
|
}
|
|
|
|
|
|
2024-09-19 01:00:31 -04:00
|
|
|
fn scan_for_outputs_unordered(
|
|
|
|
|
&self,
|
|
|
|
|
_latest_active_key: Self::Key,
|
|
|
|
|
key: Self::Key,
|
|
|
|
|
) -> Vec<Self::Output> {
|
2024-09-10 06:25:21 -04:00
|
|
|
let scanner = scanner(key);
|
|
|
|
|
|
|
|
|
|
let mut res = vec![];
|
|
|
|
|
// We skip the coinbase transaction as its burdened by maturity
|
2024-09-11 02:46:18 -04:00
|
|
|
for tx in &self.1.txdata[1 ..] {
|
2024-09-10 06:25:21 -04:00
|
|
|
for output in scanner.scan_transaction(tx) {
|
2024-09-11 02:46:18 -04:00
|
|
|
res.push(Output::new(&self.0, key, tx, output));
|
2024-09-10 06:25:21 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
res
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[allow(clippy::type_complexity)]
|
|
|
|
|
fn check_for_eventuality_resolutions(
|
|
|
|
|
&self,
|
|
|
|
|
eventualities: &mut EventualityTracker<Self::Eventuality>,
|
|
|
|
|
) -> HashMap<
|
|
|
|
|
<Self::Output as ReceivedOutput<Self::Key, Self::Address>>::TransactionId,
|
|
|
|
|
Self::Eventuality,
|
|
|
|
|
> {
|
|
|
|
|
let mut res = HashMap::new();
|
2024-09-11 02:46:18 -04:00
|
|
|
for tx in &self.1.txdata[1 ..] {
|
2024-09-10 06:25:21 -04:00
|
|
|
let id = hash_bytes(tx.compute_txid().to_raw_hash());
|
|
|
|
|
if let Some(eventuality) = eventualities.active_eventualities.remove(id.as_slice()) {
|
|
|
|
|
res.insert(id, eventuality);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
res
|
|
|
|
|
}
|
|
|
|
|
}
|