Posted by olkurbatov
Feb 1, 2026/20:57 UTC
In the realm of cryptographic security, the discussion revolves around optimizing confidentiality and integrity through efficient key management mechanisms. The conversation highlights an innovative approach to realizing CNF-by-clauses using replicated secrets, which involves selecting a unique secret for each clause and distributing it privately among members of the OR-subtree. This method hinges on all participants agreeing on the public keys for clauses, thereby guaranteeing that only a qualified set can sign off on actions, while preventing unauthorized access.
A notable methodology discussed is the BLISK approach, which offers several advantages over traditional methods like RSS/private broadcasting. Firstly, BLISK eliminates the need for storing new secret materials by ensuring that the only long-term secrets are the participants' existing keys. This is achieved by making the clause material derivable via key agreement, thus avoiding the distribution of additional secrets and reducing the complexity related to secure storage and authenticated channels. The design is stateful, with the shared state being resistant to corruption and comprising a set of public keys representing nodes.
Another significant advantage of BLISK is its ability to prevent cheating in OR-gate constructions without necessitating co-signatures from all clause members for resolution. This addresses a critical vulnerability where a resolver could publish an arbitrary public key for an OR node, potentially compromising the system's liveness and semantics. BLISK's model allows any eligible member to resolve issues, with the verification process being non-interactive and thus more efficient, especially in scenarios involving large or overlapping clauses and partially offline participants.
The conversation also delves into the importance of rotation and the role of zero-knowledge proofs (ZKPs) in enhancing verifiability. Unlike RSS, where rotation might involve complex re-sharing or distribution protocols, BLISK utilizes ZKPs to allow for public checking of updates or resolutions to internal-node keys without extensive distribution efforts. This ensures that while one party updates their key, the public keys of other participants remain unchanged, albeit requiring proof verification to update a common state with the new version. This mechanism underscores the utility of ECDH for local-derivability of OR secrets without introducing new replicated secrets, with ZKPs ensuring the consistency and well-formedness of OR resolutions.
Thread Summary (13 replies)
Jan 26 - Feb 5, 2026
14 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback