Posted by ajtowns
Feb 7, 2025/04:36 UTC
The discussion revolves around the intricacies of a cryptographic transaction system, specifically focusing on a scenario involving two parties, Alice and Bob, engaging in a transaction where conditional payments and timelocks play crucial roles. The scenario outlines a transaction process where Alice attempts to claim coins by publishing a specific value, $P_a + A_1$. This action allows for two possible outcomes: Bob can claim 10 BT if he possesses the correct secret key that matches the address $\mathsf{addr}_b$; alternatively, if the secret key does not match, Alice retains the ability to claim the coins after a specified timelock period expires.
The conversation raises questions about potential vulnerabilities in this setup, particularly concerning Alice's incentive to delay her claim on the output until the timelock expires, even if Bob has correctly identified the secret key. To address this, a hypothetical extra setup transaction is proposed, introducing a challenge transaction mechanism. This mechanism requires Alice to reveal $P_a+A_1$ to complete the challenge transaction, making the payment contingent on the closure of the channel.
However, this proposed solution encounters complexities related to the roles of the force-closer and the recipient within the probabilistic payment system. The force-closer, responsible for publishing the transaction, and the recipient, who stands to win based on the outcome of the revealed secret, may not align neatly within the existing framework, especially when the force-closer is also the recipient of the probabilistic payment. This misalignment suggests a need for adjustments to the protocol to accommodate these roles effectively.
Moreover, the practicality of implementing such a system is questioned, particularly concerning the scalability and efficiency of transmitting thousands of hashed public keys along with a zero-knowledge proof (zkp) for every minor HTLC update. This requirement could potentially make the system prohibitive to operate, indicating a need for further refinement or alternative solutions to address these challenges.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback