Published on: 2020-03-06T07:33:58+00:00
The conversation revolves around the construction of Hashed Time-Lock Contracts (HTLCs) in the Bitcoin Lightning Network. The initial question raised is why another HTLC is needed from B to A when a single HTLC from A to B should be sufficient for a simple transfer of funds. It is clarified that this is because the use case involves multiple hops, and punishment cannot be enforced in an HTLC from A->B->C due to the need for HTLCs to be set up from left to right. The challenge is that A cannot punish B for not revealing the secret because A does not possess it.The idea of enforcing penalties on the counterparty within the terms of the HTLC itself is then discussed. The suggestion is made to allocate 0.4 BTC to A, 0.2 BTC to B, and 0.4 BTC to the HTLC. If B produces the required information within a set time, it receives back 0.4 BTC; otherwise, after the set time, A can broadcast with 0.4 BTC going to A, preventing B from withholding information and potentially inducing a griefing attack across a longer path. A reference to a paper on fair atomic swaps is shared as further reading.In an email conversation, Subhra seeks clarification on whether one HTLC from A to B would suffice for a simple transfer of funds instead of two. Lloyd explains that the penalty idea is the basis for doing atomic swaps fairly and shares a relevant document. The issue is identified that the shared PDF is based on an exchange of assets, whereas the current matter deals with a straightforward transfer of funds. Two situations are presented to explain the problem. Subhra asks why the first situation, where both A and B lock in 0.1 BTC each, will not work and proposes an alternative solution.The discussion continues with the question of why HTLC terms cannot enforce a penalty on the counterparty to prevent griefing attacks. Lloyd responds that this idea only works for the final hop and not across multiple hops. Subhra raises a scenario involving contracts between A, B, and C, where A wants to transfer money to C. The concern is that if A imposes a penalty on B using its local HTLC, B may include the same clause on C to impose a penalty if C misbehaves. Lloyd points out that setting up both penalties atomically can be problematic if one is set up before the other.The email conversation centers around the Bitcoin Lightning Network and the construction of HTLCs. Subhra proposes modifying the HTLC terms to enforce penalties on the counterparty in case of misbehavior. Lloyd explains that while this concept is the basis for fair atomic swaps, it is only applicable for the final hop and not multiple hops. He shares a link to a paper on financial cryptography for further information. The conversation ends with Subhra signing off.In an email exchange on the Lightning-dev mailing list, Subhra asks about the terms of an HTLC and suggests setting them such that party A receives 0.4 BTC, party B receives 0.2 BTC, and 0.4 BTC is locked in the HTLC. This would allow either party to claim the locked funds, with party A able to claim them after a certain time period if party B does not provide the required knowledge within that time. Lloyd notes that this approach only works for the final hop and shares a link to a paper on atomic swaps. The content of the paper and its relation to the discussion are not further explained.Overall, the conversation delves into the intricacies of constructing HTLCs in the Bitcoin Lightning Network. Different scenarios and ideas are explored, including the enforcement of penalties within the HTLC terms and the challenges of doing so across multiple hops. References to relevant papers are provided to support the discussion.
Updated on: 2023-07-31T22:43:36.972903+00:00