Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Thetacrypt: A Distributed Service for Threshold Cryptography

T0 review · 3 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Thetacrypt claims threshold cryptography can be a modular, plug-in service for distributed systems, with performance dominated by local crypto at small scale and network latency at large scale.

desk verdict Solid systems paper, worth refereeing, but the standalone deployment claim has a reliability gap that needs fixing. read the letter →

arxiv 2502.03247 v1 pith:S7XBROGC submitted 2025-02-05 cs.CR

Mariarosaria Barbaraci , Noah Schmid , Orestis Alpos , Michael Senn , Christian Cachin This is my paper · ORCID
classification cs.CR
keywords thresholdcryptographydistributedsystemsmodularsoftwarearchitecturesignaturesencryptionrandomnessByzantinefaulttoleranceperformanceevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that threshold cryptography—distributed signing, decryption, and randomness—can be packaged as a modular service that any distributed application or blockchain can plug into, without tying the cryptography to a particular network stack. Thetacrypt implements six published schemes behind one round-based protocol interface and a language-agnostic RPC interface, with adapters for peer-to-peer and total-order-broadcast communication. If the design works as claimed, application developers would no longer reimplement threshold protocols per platform, and researchers would gain a controlled testbed for comparing schemes under identical conditions. The evaluation further claims that system-level performance is governed by different factors at different scales: local cryptographic cost at small node counts, and network latency and participant count at large ones.

What carries the argument

The load-bearing object is the Threshold Round Interface (TRI), a round-based state machine with five hooks—do_round(), update(), is_ready_to_finalize(), is_ready_for_next_round(), and finalize()—that separates local cryptographic computation from network communication. Each scheme plugs into this interface, the orchestration module runs it as a stateful protocol instance, and the network layer abstracts peer-to-peer and total-order-broadcast delivery behind pluggable adapters (gRPC proxies or the bundled libp2p gossip overlay). The TRI is what lets schemes be added or swapped without touching protocol logic, and it is also what lets the same codebase run both non-interactive and multi-round protocols.

What would settle it

Run a 31-node global deployment in the default mode while dropping or reordering a small fraction of peer-to-peer messages between two nodes: if a threshold protocol still terminates with a correct output, the reliable-communication assumption is unnecessary, while if it hangs or produces an invalid result, the assumption is load-bearing. Alternatively, compare SG02 and SH00 latency at 127 nodes on a single low-latency cluster, where the paper predicts near-identical latencies, whereas a purely crypto-bound view predicts RSA to be far slower.

Watch

Extended reading notes

Core claim

The paper's central claim is that threshold cryptography can be factored out of the applications that use it and offered as a standalone, language-agnostic service, and that Thetacrypt is the first system to do this. To support the claim, the paper describes a three-layer architecture (service, core, network) in which six published schemes—SG02, BZ03, SH00, KG20, BLS04, and CKS05—are driven through a common Threshold Round Interface, and it reports measurements showing that at 7 nodes the choice of cryptographic assumption determines latency, while at 127 nodes the number of participants and network latency make scheme differences almost negligible. The paper also introduces two metrics, the residual delay factor and the latency fairness index, to quantify how slow nodes affect the completion of threshold protocols.

Load-bearing premise

The whole design assumes every pair of nodes can reliably exchange messages and, for some schemes, all receive them in the same order, yet the built-in default gossip network does not itself guarantee either property.

Editorial extensions

If this is right

  • A new threshold scheme can be added by implementing only its cryptographic primitives in the schemes module, and the protocol and orchestration layers support it automatically.
  • Applications on blockchain validators can request threshold signatures, decryptions, or random coins through gRPC, using the host platform's existing consensus for ordering when needed.
  • Deployments with about 7 nodes should choose schemes by their cryptographic assumptions (ECDH before pairings before RSA), while at about 127 nodes the choice barely affects latency.
  • The residual delay factor and latency fairness index give operators a way to detect when slow nodes are skewing a threshold protocol, rather than relying on averages alone.
  • System capacity in these tests is set mainly by local computation: moving from a single data center to a global deployment did not shift the knee point of any scheme.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Not in the paper: the same architectural separation could be extended to distributed key generation, since the current service assumes a trusted dealer for setup, leaving that as the one remaining centralized bottleneck.
  • Not in the paper: the scale result predicts that for large enough networks the number of communication rounds, not the cost of the underlying group operation, will decide which scheme is fastest; the crossover point is an experimentally testable quantity.
  • Not in the paper: the residual delay factor and fairness index are defined for threshold protocols but measure a generic straggler effect that could also diagnose BFT consensus or distributed randomness beacons.
  • Not in the paper: whether Thetacrypt is truly the first modular treatment depends on how much modularity one grants to integrated platforms such as the Internet Computer; the paper's distinctive contribution is the explicit decoupling from the host platform.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents Thetacrypt, a modular service/library for integrating threshold cryptographic schemes into distributed systems. It describes a three-layer architecture (service, core, network) with a Threshold Round Interface, a protocol API, language-agnostic gRPC interfaces, and six implemented schemes (SG02, BZ03, SH00, KG20, BLS04, CKS05). The evaluation compares these schemes across small (7-node), medium (31-node), and large (127-node) deployments in local and global settings, introducing two latency-derived metrics (residual delay factor and latency fairness index). The main claims are that Thetacrypt decouples threshold cryptography from particular platforms, that it is the first modular system of its kind, and that in large deployments network effects dominate cryptographic cost.

Significance. If the design and evaluation were fully supported, Thetacrypt would be a useful open-source contribution to practical threshold cryptography, offering a common interface and a controlled testbed for comparative evaluation. The paper's strongest points are its clear architectural separation of concerns, the inclusion of both non-interactive and interactive protocols (FROST as a multi-round test case), and the attempt to go beyond microbenchmarks with system-level metrics. However, the significance is currently limited by a mismatch between the formal communication model and the default standalone transport, and by an evaluation without replication or error bars, which weakens the quantitative conclusions.

major comments (3)
  1. [Sec. 3.2 and 3.6] The system model in Sec. 3.2 assumes reliable communication between every pair of nodes and optionally a total-order broadcast primitive, with no bound on network delay. The default network component described in Sec. 3.6 is a libp2p gossip overlay, which is best-effort and does not guarantee reliable delivery or ordering. Since the standalone service and the capacity/steady-state evaluations use this default P2P component, the implemented default deployment does not satisfy the model under which the security and termination of the threshold protocols are argued. The proxy modules for a replicated service are an alternative integration path, not the default. The authors should either implement a reliability layer over gossip (e.g., retransmission, acknowledgements, or bounded retries with abort) and demonstrate it with fault-injection experiments, or explicitly qualify the standalone deployment as best-effort and state that the correctness guarantees apply only when Thetacrypt is connected to a reliable P2P/TOB service.
  2. [Sec. 4.4 and 4.5] The capacity test is performed with a single one-minute run per configuration (Sec. 4.4) and the knee capacities are determined by visual inspection of Fig. 4 (Sec. 4.5), without repeated trials or confidence intervals. Because the global deployment spans data centers with network latencies of about 100 ms and 43 ms, the reported distinctions among schemes (e.g., knee points at 8 vs 4 req/s, or 'nearly negligible' differences at 127 nodes) may be within run-to-run variability. The evaluation should include multiple repetitions, report means and spreads (or percentile intervals), and define an algorithmic rule for knee detection so that the comparative claims are reproducible.
  3. [Sec. 1 and Sec. 5] The claim that Thetacrypt is 'the first system to treat threshold cryptography as a modular component' (Sec. 1) is not supported by a systematic comparison with existing threshold-cryptography libraries and frameworks; Sec. 5 discusses a handful of platform-integrated systems but does not survey general-purpose libraries (e.g., threshold-signature libraries for coins or threshold ECDSA toolkits). The claim should be either backed by a concrete survey with selection criteria or downgraded to a statement about the authors' specific design choices.
minor comments (5)
  1. [Sec. 4.2 and Table 2] The deployment acronym in Sec. 4.2 says 'medium deployment using 31 nodes, with a threshold of 11 (DO-11-L/G)', but Table 2 uses DO-31-L/G for the same deployment; this inconsistency should be fixed.
  2. [Sec. 4.4] In the steady-state analysis description, 'the derived metrics (δres, ηθ) computed from Lnode_95' is inconsistent with the definitions in Sec. 4.3, which use Lnet_95 and Lnet_θ; please clarify the aggregation from node-level to network-level latencies.
  3. [Sec. 4.5] In the last paragraph of Sec. 4.5, 'Lres_θ' appears to be a typo for 'Lnet_θ' or 'Lθ'; please correct it.
  4. [Throughout] There are several typos and grammatical errors that should be fixed in a revision: 'cryptografic' (Sec. 3.5), 'comumn' (Sec. 4.5), 'lenght' (Table 3), 'corrisponding' (Sec. 4.4), and 'studing' (Sec. 4.5).
  5. [Sec. 4.5] The sentence 'We suspect the reason is the second round of communication as well as the fixed signing group requirement' is speculative; it would be stronger to support this with a per-round time breakdown or a controlled experiment isolating the two effects.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: Thetacrypt's metrics are definitions and its evaluation is empirical, not a fitted prediction.

full rationale

This paper presents a software architecture and an empirical evaluation; it does not derive predictions from first principles in a way that could reduce to its own inputs. The latency metrics in Section 4.3 (threshold latency, residual delay factor, and latency fairness index) are explicitly defined in terms of measured latency percentiles and are not fitted to the observed outcomes; the performance conclusions in Section 4.5 are empirical comparisons of externally specified schemes (SG02, BZ03, SH00, KG20, BLS04, CKS05) run under common conditions on the authors' own testbed. No parameter is fitted to a subset of data and then renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no equation in the paper is equivalent to its inputs by construction. The paper cites the authors' own CKS05 scheme, but that citation supplies one of the cryptographic constructions being benchmarked and is not used as load-bearing justification for Thetacrypt's framework claims. Evaluating one's own library is standard practice and does not by itself constitute circularity. The gap between the reliable-communication model in Section 3.2 and the default libp2p gossip layer in Section 3.6 is a substantive model/implementation mismatch, but it is a correctness concern, not a circular derivation, and therefore does not affect the circularity score. The novelty assertion that Thetacrypt is the first modular threshold-cryptography service is an unverified claim about prior art, not a circular step.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on standard cryptographic hardness assumptions, a trusted dealer setup, and the availability of reliable network primitives. The library itself introduces no new mathematical objects or free parameters for fitting; the evaluation metrics are defined directly from measured latency distributions.

assumptions (4)
  • domain assumption The threshold schemes cited (SG02, BZ03, SH00, KG20, BLS04, CKS05) are secure under their stated hardness assumptions.
    Section 3.5 relies on the original papers for security; Thetacrypt does not re-prove them.
  • domain assumption A trusted dealer distributes key material during setup.
    Section 4.4 states: 'We assume a setup phase during which a trusted dealer distributes the key material for all schemes.'
  • domain assumption The underlying network provides reliable communication between every pair of nodes and optionally total-order broadcast.
    Section 3.2 states this model; the implementation uses a gossip protocol over libp2p, which does not by itself guarantee reliable delivery, creating a gap between model and implementation.
  • domain assumption The application maintains the service semantics of Thetacrypt, including valid inputs and ordering requirements.
    Section 3.2: 'the distributed application is also responsible for maintaining the service semantics of Thetacrypt.'

how reviews work

0 comments
Cite this review

Pith. "Pith review of Thetacrypt: A Distributed Service for Threshold Cryptography." pith.science (2026). https://pith.science/paper/S7XBROGC

@misc{pith2026250203247,
  author       = {Pith},
  title        = {Pith review of: Thetacrypt: A Distributed Service for Threshold Cryptography},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/S7XBROGC}},
  note         = {Machine review of arXiv:2502.03247}
}
read the original abstract

Threshold cryptography is a powerful and well-known technique with many applications to systems relying on distributed trust. It has recently emerged also as a solution to challenges in blockchain: frontrunning prevention, managing wallet keys, and generating randomness. This work presents Thetacrypt, a versatile library for integrating many threshold schemes into one codebase. It offers a way to easily build distributed systems using threshold cryptography and is agnostic to their implementation language. The architecture of Thetacrypt supports diverse protocols uniformly. The library currently includes six cryptographic schemes that span ciphers, signatures, and randomness generation. The library additionally contains a flexible adapter to an underlying networking layer that provides peer-to-peer communication and a total-order broadcast channel; the latter can be implemented by distributed ledgers, for instance. Thetacrypt serves as a controlled testbed for evaluating the performance of multiple threshold-cryptographic schemes under consistent conditions, showing how the traditional micro benchmarking approach neglects the distributed nature of the protocols and its relevance when considering system performance.

Figures

Figures reproduced from arXiv: 2502.03247 by the authors.

Figure 1
Figure 1. Integration of the Thetacrypt module (Θ) in a blockchain network, where each network node runs a five-layer blockchain stack. The intended deployment of Thetacrypt is in the form of a distributed service coupled with a dis￾tributed application that accesses Thetacrypt’s operations. The natural setup consists of a fault-tolerant replicated service with as many independent nodes as there are Thetacrypt nodes and with … view at source ↗
Figure 2
Figure 2. The Thetacrypt architecture consists of three layers. Cryptographic operations are provided by the schemes module and they are connected to the network through the protocols and orchestration modules. Thetacrypt itself encompasses three layers, as shown in [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. The orchestration module and its components 3.6 Network Layer The network layer is designed to serve all the possible deployment configurations of Thetacrypt. A net￾work manager module sets up the needed components based on the configuration provided at start-up. By default, the communication layer provides peer-to-peer (P2P) communication, on which, optionally, one can enable end-to-end authentication. In addition,… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Server-side Throughput-Latency graphs range from a lower bound imposed by network latency to an upper bound due to the experiment time (≈ 60s), as we calculate latency solely for completed requests. he measurements show that the category of a scheme (i.e., cipher, sign…
Figure 5
Figure 5. Figure 5: Five-minute experiments at knee capacity. only exception is BLS04 going from a knee point of 2 req/s (DO-127-L) to 1 req/s (DO-127-G). This indicates that the achievable capacity depends primarily on the local computation power; in other words, throughput remains unaff…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Not eXactly Byzantine: Efficient and Resilient TEE-Based State Machine Replication

    cs.DC 2025-01 conditional novelty 6.0 of 10

    NxBFT is a TEE-based, asynchronous, leaderless DAG consensus protocol that achieves the highest throughput in the authors' comparison against MinBFT and Chained-Damysus for up to 40 replicas, at the cost of higher lat...

Reference graph

Works this paper leans on

47 extracted references · 47 canonical work pages · cited by 1 Pith paper

  1. [1]

    DHAES: an encryption scheme based on the diffie- hellman problem,

    M. Abdalla, M. Bellare, and P. Rogaway, “DHAES: an encryption scheme based on the diffie- hellman problem,” IACR Cryptol. ePrint Arch., p. 7, 1999

    work page 1999

  2. [2]

    The oracle diffie-hellman assumptions and an analysis of DHIES,

    M. Abdalla, M. Bellare, and P. Rogaway, “The oracle diffie-hellman assumptions and an analysis of DHIES,” inTopics in Cryptology - CT-RSA 2001, The Cryptographer’s Track at RSA Conference 2001, San Francisco, CA, USA, April 8-12, 2001, Proceedings (D. Naccache, ed.), vol. 2020 of Lecture Notes in Computer Science, pp. 143–158, Springer, 2001

    work page

  3. [3]

    Simple and efficient threshold cryptosystem from the gap diffie-hellman group,

    J. Baek and Y . Zheng, “Simple and efficient threshold cryptosystem from the gap diffie-hellman group,” in Proceedings of the Global Telecommunications Conference, 2003. GLOBECOM ’03, San Francisco, CA, USA, 1-5 December 2003, pp. 1491–1495, IEEE, 2003

    work page 2003

  4. [4]

    Ferveo: Threshold decryption for mempool privacy in BFT networks,

    J. Bebel and D. Ojha, “Ferveo: Threshold decryption for mempool privacy in BFT networks,”IACR Cryptol. ePrint Arch., p. 898, 2022

    work page 2022

  5. [5]

    Short signatures from the weil pairing,

    D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weil pairing,” J. Cryptol., vol. 17, no. 4, pp. 297–319, 2004

    work page 2004

  6. [6]

    Asynchronous verifiable secret sharing and proactive cryptosystems,

    C. Cachin, K. Kursawe, A. Lysyanskaya, and R. Strobl, “Asynchronous verifiable secret sharing and proactive cryptosystems,” in Proceedings of the 9th ACM Conference on Computer and Com- munications Security, CCS 2002, Washington, DC, USA, November 18-22, 2002 (V . Atluri, ed.), pp. 88–97, ACM, 2002. 17

    work page 2002

  7. [7]

    Secure and efficient asynchronous broadcast protocols,

    C. Cachin, K. Kursawe, F. Petzold, and V . Shoup, “Secure and efficient asynchronous broadcast protocols,” in Advances in Cryptology - CRYPTO 2001, 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19-23, 2001, Proceedings (J. Kilian, ed.), vol. 2139 of Lecture Notes in Computer Science, pp. 524–541, Springer, 2001

    work page 2001

  8. [8]

    Random oracles in constantinople: Practical asynchronous byzantine agreement using cryptography,

    C. Cachin, K. Kursawe, and V . Shoup, “Random oracles in constantinople: Practical asynchronous byzantine agreement using cryptography,”J. Cryptol., vol. 18, no. 3, pp. 219–246, 2005

    work page 2005

Show all 47 references
  1. [9]

    Internet computer consensus,

    J. Camenisch, M. Drijvers, T. Hanke, Y . Pignolet, V . Shoup, and D. Williams, “Internet computer consensus,” in PODC ’22: ACM Symposium on Principles of Distributed Computing, Salerno, Italy, July 25 - 29, 2022 (A. Milani and P. Woelfel, eds.), pp. 81–91, ACM, 2022

    2022

  2. [10]

    SCRAPE: scalable randomness attested by public entities,

    I. Cascudo and B. David, “SCRAPE: scalable randomness attested by public entities,” in Applied Cryptography and Network Security - 15th International Conference, ACNS 2017, Kanazawa, Japan, July 10-12, 2017, Proceedings (D. Gollmann, A. Miyaji, and H. Kikuchi, eds.), vol. 1035...

    2017

  3. [11]

    Sok: Distributed randomness beacons,

    K. Choi, A. Manoj, and J. Bonneau, “Sok: Distributed randomness beacons,” in 44th IEEE Sym- posium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 21-25, 2023 , pp. 75–92, IEEE, 2023

    2023

  4. [12]

    https://grpc.io/

    Cloud Native Computing Foundation, “grpc,” 2024. https://grpc.io/

    2024

  5. [13]

    Protocol buffers,

    Cloud Native Computing Foundation, “Protocol buffers,” 2024. https://grpc.io/

    2024

  6. [14]

    Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,

    P. Daian, S. Goldfeder, T. Kell, Y . Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels, “Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,” in 2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA,...

    2020

  7. [15]

    Spurt: Scalable distributed randomness beacon with transparent setup,

    S. Das, V . Krishnan, I. M. Isaac, and L. Ren, “Spurt: Scalable distributed randomness beacon with transparent setup,” in43rd IEEE Symposium on Security and Privacy, SP 2022, San Francisco, CA, USA, May 22-26, 2022, pp. 2502–2517, IEEE, 2022

    2022

  8. [16]

    Threshold cryptography,

    Y . Desmedt, “Threshold cryptography,”Eur. Trans. Telecommun., vol. 5, no. 4, pp. 449–458, 1994

    1994

  9. [17]

    The DFINITY foundation,

    “The DFINITY foundation,” 2024. https://dfinity.org

    2024

  10. [18]

    Dfns: Web3 wallets as an API,

    “Dfns: Web3 wallets as an API,” 2023. https://www.dfns.co

    2023

  11. [19]

    drand: Distributed randomness beacon,

    “drand: Distributed randomness beacon,” 2023. https://drand.love

    2023

  12. [20]

    Secure causal atomic broadcast, revisited,

    S. Duan, M. K. Reiter, and H. Zhang, “Secure causal atomic broadcast, revisited,” in 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2017, Denver, CO, USA, June 26-29, 2017, pp. 61–72, IEEE Computer Society, 2017

    2017

  13. [21]

    Shutter network: Private transactions from threshold cryptography

    S. Dziembowski, S. Faust, and J. Luhn, “Shutter network: Private transactions from threshold cryptography.” Cryptology ePrint Archive, Paper 2024/1981, 2024

    2024

  14. [22]

    Fully distributed verifiable random functions and their application to decentralised random beacons,

    D. Galindo, J. Liu, M. Ordean, and J. Wong, “Fully distributed verifiable random functions and their application to decentralised random beacons,” in IEEE European Symposium on Security and Privacy, EuroS&P 2021, Vienna, Austria, September 6-10, 2021, pp. 88–102, IEEE, 2021

    2021

  15. [23]

    A public key cryptosystem and a signature scheme based on discrete logarithms,

    T. E. Gamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” IEEE Trans. Inf. Theory, vol. 31, no. 4, pp. 469–472, 1985. 18

    1985

  16. [24]

    Sok: A consensus taxonomy in the blockchain era,

    J. A. Garay and A. Kiayias, “Sok: A consensus taxonomy in the blockchain era,” in Topics in Cryptology - CT-RSA 2020 - The Cryptographers’ Track at the RSA Conference 2020, San Fran- cisco, CA, USA, February 24-28, 2020, Proceedings (S. Jarecki, ed.), vol. 12006 of Lecture Not...

  17. [25]

    Fast multiparty threshold ECDSA with fast trustless setup,

    R. Gennaro and S. Goldfeder, “Fast multiparty threshold ECDSA with fast trustless setup,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018 (D. Lie, M. Mannan, M. Backes, and X. Wang, ed...

    2018

  18. [26]

    Threshold-optimal DSA/ECDSA signatures and an application to bitcoin wallet security,

    R. Gennaro, S. Goldfeder, and A. Narayanan, “Threshold-optimal DSA/ECDSA signatures and an application to bitcoin wallet security,” in Applied Cryptography and Network Security - 14th International Conference, ACNS 2016, Guildford, UK, June 19-22, 2016. Proceedings(M. Manulis,...

    2016

  19. [27]

    Secure distributed key generation for discrete- log based cryptosystems,

    R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Secure distributed key generation for discrete- log based cryptosystems,” J. Cryptol., vol. 20, no. 1, pp. 51–83, 2007

    2007

  20. [28]

    A digital signature scheme secure against adaptive chosen-message attacks,

    S. Goldwasser, S. Micali, and R. L. Rivest, “A digital signature scheme secure against adaptive chosen-message attacks,” SIAM J. Comput., vol. 17, no. 2, pp. 281–308, 1988

    1988

  21. [29]

    FROST: flexible round-optimized schnorr threshold signatures,

    C. Komlo and I. Goldberg, “FROST: flexible round-optimized schnorr threshold signatures,” in Selected Areas in Cryptography - SAC 2020 - 27th International Conference, Halifax, NS, Canada (Virtual Event), October 21-23, 2020, Revised Selected Papers (O. Dunkelman, M. J. J. Jr....

    2020

  22. [30]

    The byzantine generals problem,

    L. Lamport, R. E. Shostak, and M. C. Pease, “The byzantine generals problem,” ACM Trans. Pro- gram. Lang. Syst., vol. 4, no. 3, pp. 382–401, 1982

    1982

  23. [31]

    Digital asset management with MPC,

    Y . Lindell, “Digital asset management with MPC,” 2023. https://www.coinbase.com/ blog/digital-asset-management-with-mpc-whitepaper

    2023

  24. [32]

    CHURP: dynamic- committee proactive secret sharing,

    S. K. D. Maram, F. Zhang, L. Wang, A. Low, Y . Zhang, A. Juels, and D. Song, “CHURP: dynamic- committee proactive secret sharing,” inProceedings of the 2019 ACM SIGSAC Conference on Com- puter and Communications Security, CCS 2019, London, UK, November 11-15, 2019(L. Cavallaro...

    2019

  25. [33]

    MIRACL core,

    MIRACL, “MIRACL core,” 2024. https://github.com/miracl/core

    2024

  26. [34]

    Public-key cryptosystems provably secure against chosen ciphertext at- tacks,

    M. Naor and M. Yung, “Public-key cryptosystems provably secure against chosen ciphertext at- tacks,” in Proceedings of the 22nd Annual ACM Symposium on Theory of Computing, May 13-17, 1990, Baltimore, Maryland, USA (H. Ortiz, ed.), pp. 427–437, ACM, 1990

    1990

  27. [35]

    Multi-party threshold cryptography (mptc) project

    NIST, “Multi-party threshold cryptography (mptc) project.” https://csrc.nist.gov/ Projects/Threshold-Cryptography/, 2019

    2019

  28. [36]

    Partisia: Solving the blockchain trilemma

    Partisia Blockchain, “Partisia: Solving the blockchain trilemma.” https:// partisiablockchain.com, 2023

    2023

  29. [37]

    A threshold cryptosystem without a trusted party (extended abstract),

    T. P. Pedersen, “A threshold cryptosystem without a trusted party (extended abstract),” inAdvances in Cryptology - EUROCRYPT ’91, Workshop on the Theory and Application of of Cryptographic Techniques, Brighton, UK, April 8-11, 1991, Proceedings (D. W. Davies, ed.), vol. 547 of...

    1991

  30. [38]

    libp2p: The peer-to-peer network,

    Protocol Labs, “libp2p: The peer-to-peer network,” 2024. https://libp2p.io/. 19

    2024

  31. [39]

    How to securely replicate services,

    M. K. Reiter and K. P. Birman, “How to securely replicate services,” ACM Trans. Program. Lang. Syst., vol. 16, no. 3, pp. 986–1009, 1994

    1994

  32. [40]

    ROAST: robust asynchronous schnorr threshold signatures,

    T. Ruffing, V . Ronge, E. Jin, J. Schneider-Bensch, and D. Schr¨oder, “ROAST: robust asynchronous schnorr threshold signatures,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS 2022, Los Angeles, CA, USA, November 7-11, 2022 (H. Yi...

    2022

  33. [41]

    Implementing fault-tolerant services using the state machine approach: A tuto- rial,

    F. B. Schneider, “Implementing fault-tolerant services using the state machine approach: A tuto- rial,” ACM Comput. Surv., vol. 22, no. 4, pp. 299–319, 1990

    1990

  34. [42]

    Efficient signature generation by smart cards,

    C. Schnorr, “Efficient signature generation by smart cards,” J. Cryptol., vol. 4, no. 3, pp. 161–174, 1991

    1991

  35. [43]

    Practical threshold signatures,

    V . Shoup, “Practical threshold signatures,” inAdvances in Cryptology - EUROCRYPT 2000, Inter- national Conference on the Theory and Application of Cryptographic Techniques, Bruges, Belgium, May 14-18, 2000, Proceeding (B. Preneel, ed.), vol. 1807 of Lecture Notes in Computer ...

    2000

  36. [44]

    Securing threshold cryptosystems against chosen ciphertext attack,

    V . Shoup and R. Gennaro, “Securing threshold cryptosystems against chosen ciphertext attack,” J. Cryptol., vol. 15, no. 2, pp. 75–96, 2002

    2002

  37. [45]

    Thresh-Hold: Assessment of Threshold Cryptography in Leader-Based Consensus,

    R. von Seck, F. Rezabek, and G. Carle, “Thresh-Hold: Assessment of Threshold Cryptography in Leader-Based Consensus,” in 2024 IEEE 49th Conference on Local Computer Networks (LCN) , pp. 1–8, IEEE, Oct. 2024

    2024

  38. [46]

    The latency price of threshold cryptosystem in blockchains,

    Z. Xiang, S. Das, Z. Li, Z. Ma, and A. Spiegelman, “The latency price of threshold cryptosystem in blockchains,” CoRR, vol. abs/2407.12172, 2024

    2024 arXiv

  39. [47]

    F3B: A low- overhead blockchain architecture with per-transaction front-running protection,

    H. Zhang, L. Merino, Z. Qu, M. Bastankhah, V . Estrada-Gali ˜nanes, and B. Ford, “F3B: A low- overhead blockchain architecture with per-transaction front-running protection,” in 5th Confer- ence on Advances in Financial Technologies, AFT 2023, October 23-25, 2023, Princeton, N...

    2023

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.