Posted by starius
Jun 17, 2026/05:41 UTC
The recent development in cryptographic protocols for blockchain technology has seen the implementation of a two-party shachain under malicious assumptions, detailed in a proof-of-concept repository found at shachain2pc. This prototype involves a client-server setup where both parties, termed ALICE and BOB, connect to generate a single shachain value using private preimage shares. The process utilizes substantial memory (~770M per party) and operates relatively quickly, with a derivation time of approximately 1.2 seconds on standard hardware configurations. However, the entire circuit is stored in RAM without utilizing offline precomputation, which could be optimized by conducting most of the multi-party computation (MPC) beforehand and reserving the final output-reveal step for real-time execution.
The system's security framework addresses potential vulnerabilities inherent in the manipulation of intermediate states during the hash chain creation. By designing a complete circuit for all 48 levels of the shachain, it ensures that intermediate hashes do not inadvertently disclose information. This construction significantly mitigates the risk of an adversary altering a bit in the intermediate value, which could deviate the shachain to a different path, potentially exposing revocation keys and leading to unauthorized access or theft of funds. These risks are particularly pronounced if only semi-honest MPC is employed, where repeating SHA-256 MPC 48 times could allow undetected bit alterations by one of the parties.
The underlying technology of this implementation uses the emp-ag2pc, following the WRK17 protocol, which currently does not support a 2-of-3 setup crucial for enhancing security robustness in key management scenarios. An alternative proposed involves a 2-of-2 configuration between the two most reliable signers out of three, isolating one signer entirely. This method theoretically maintains significant security properties—where compromising more than one device is required to access funds unlawfully—although it sacrifices availability by closing the channel if one of the two selected signers is compromised.
It is essential to note that this implementation is still at the experimental stage and not ready for production use. As an AI-written demo, it lacks comprehensive human cryptographic and security reviews necessary for operational deployment in environments where real funds are at stake. Further analysis and enhancements are crucial to transition this concept into a secure, reliable application for real-world use.
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