Published on: 2016-02-11T21:00:32+00:00
In a series of email threads and discussions, several issues and potential solutions regarding the Lightning Network development are addressed. One recurring problem is the intertwinement of channel balance and collateral, which leads to the need for documentation to prevent its recurrence. A hypothetical scenario involving two parties, Alice and Eve, is presented to explain the issue in detail. The scenario highlights the importance of timing and the consequences of unresponsiveness on one channel. It is suggested that both proposed solutions should be implemented side by side if there is demand for it.Another discussion focuses on closing channels in the Lightning Network. Four options are identified: keeping the channel open, unilateral closure by either party, or cooperative closure. It is determined that cooperative closure is preferred over unilateral closure due to the delay introduced by OP_CSV. However, if a lower transaction fee can be used or funds can be spent directly to a useful output address, cooperative closure is better than unilateral closure. The potential benefits of implementing OP_CSV on both sides of HTLCs are also discussed.A potential problem with the HTLC system is raised, where Eve could steal funds from Alice by not revealing the transaction R value. To prevent this, delaying all outputs to Alice in her commit transaction via OP_CSV, including HTLC outputs, is proposed. A separate email thread delves into the details of the HTLC system and the requirements for successful implementation. The conversation clarifies the relationship between HTLC lifetimes and commit transactions.Furthermore, the Lightning Network paper introduces the concept of revocable transactions, allowing outputs to be spent by either the owner or a counterparty who knows a secret. The use of hashes instead of private keys is proposed as a more efficient solution.Rusty Russell has made improvements to the Lightning Network's private key sending function by using a hypercube multi-dimensional array of preimages. This approach reduces setup time and eliminates the need for private keys in revoking transactions. The implementation can be found in the ccan/crypto/shachain module on Github.In the original draft paper, private keys were used to revoke transactions. However, Rusty Russell has introduced "revocation preimages" as a replacement for sending pubkeys. This design change is considered an improvement.To generate hash time-locked contracts for the lightning network, commitment transactions receive an additional output. This output can be spent under four conditions: if the recipient knows the R value (funds go to recipient), if the HTLC has timed out (funds return to initiator), if the HTLC has been revoked (funds go to "non-cheating" side), or if the commit transaction has been revoked (funds go to "non-cheating" side). The use of "revocation preimages" instead of pubkeys in revoking transactions results in a scriptPubKey from the commitment tx for the HTLC.It is important to introduce delays in cases where payment can go to A so that B has a chance to steal the funds if the HTLC or commitment tx has been revoked. The resulting scriptPubKey from the commitment tx for the HTLC is provided as an example.Overall, Rusty Russell's improvements to the Lightning Network's private key sending function and the use of "revocation preimages" instead of pubkeys have streamlined the process and enhanced security. Feedback, fixes, and optimizations are welcome.
Updated on: 2023-07-31T18:06:29.844128+00:00