You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it's somewhat ridiculous to discuss a 2.0 before a 1.0, there are a series of features I'd love to support which likely won't be included in the 1.0 release, yet would be breaking changes.
Arbitrary mutations to keys. Right now, we only support an additive offset. Monero uses the lagrange coefficient as a multiplier before adding that offset. This could be rewritten as [Mul(lagrange), Add(offset)]. Such arbitrary handling would enable easy integration with protocols such as Sub-FROST #80, while simultaneously making the lagrange function modular. This is notable as for MuSig Support Musig2 key aggregation in dkg #186, we have to define a key of key * binding * lagrange.inverse(), so when the lagrange is applied, it restores to key. Ideally, we just write [Mul(binding)].
Composable chaining between MuSig and FROST. While personally, I'd argue since FROST can be used everywhere it should be, I'd highlight the potential desire to use FROST in a MuSig instance which is unaware to any such sub-protocol. Accordingly, we need to support MuSig proper. This likely would be defining a two-round signature protocol crate, which a theoretical MuSig crate and the FROST crate would inherent from.
Abstracted key handling. Right now, the DKG stores keys in RAM. Ideally, this could be anything from the SGX (SGX-backed key management #95) to a hardware wallet.
Sub-FROST (Sub-FROST #80), which would be enabled via the prior bullet point.
The text was updated successfully, but these errors were encountered:
While I appreciate this issue existing, providing a list of items which could fit into a 2.0, we don't have the bandwidth nor benefit to work on this at this time. Since we have no active interest, I'd rather re-open this when things change then keep it open.
While it's somewhat ridiculous to discuss a 2.0 before a 1.0, there are a series of features I'd love to support which likely won't be included in the 1.0 release, yet would be breaking changes.
Arbitrary mutations to keys. Right now, we only support an additive offset. Monero uses the lagrange coefficient as a multiplier before adding that offset. This could be rewritten as
[Mul(lagrange), Add(offset)]
. Such arbitrary handling would enable easy integration with protocols such as Sub-FROST #80, while simultaneously making the lagrange function modular. This is notable as for MuSig Support Musig2 key aggregation in dkg #186, we have to define a key ofkey * binding * lagrange.inverse()
, so when the lagrange is applied, it restores to key. Ideally, we just write[Mul(binding)]
.Composable chaining between MuSig and FROST. While personally, I'd argue since FROST can be used everywhere it should be, I'd highlight the potential desire to use FROST in a MuSig instance which is unaware to any such sub-protocol. Accordingly, we need to support MuSig proper. This likely would be defining a two-round signature protocol crate, which a theoretical MuSig crate and the FROST crate would inherent from.
Abstracted key handling. Right now, the DKG stores keys in RAM. Ideally, this could be anything from the SGX (SGX-backed key management #95) to a hardware wallet.
Sub-FROST (Sub-FROST #80), which would be enabled via the prior bullet point.
The text was updated successfully, but these errors were encountered: