Published on: 2015-08-14T01:26:44+00:00
Rusty Russell, a developer, has been non-responsive in the development of a bitcoinj implementation of Lightning. However, he acknowledges the importance of any implementation for the Bitcoin ecosystem and enjoys collaborating with other implementers on protocol design. Mats Jerratsch and Joseph Poon discuss the implications of calling a proposed system a Lightning Network Implementation. Poon expresses concerns about implicit trust and long-term systemic risks, suggesting testing with dummy opcodes on testnet instead of using semi-trusted implementations. They agree that scalability of bitcoin micropayments is important and appreciate any implementation that helps with this.The conversation between Poon and Jerratsch focuses on security issues with the Lightning Network Implementation. They discuss attack vectors related to Funding and HTLCs, which can be partially mitigated by a reserve. They explore scenarios where Alice broadcasts mutated versions of Commitment 20, resulting in Bob losing funds or being locked into negotiations. They suggest setting the minimum stealable amount of Alice higher than concurrent payments minus blockchain fees to mitigate these attacks. They conclude that open payments are problematic while settled balances can be stolen with one transaction.Poon and Jerratsch further discuss the primary attack vector of hash-based revocation and the mitigation of Funding and HTLCs through a reserve. They clarify that only Alice would be harmed if she mutates the channel transaction, as Bob has both keys of the multisig. They emphasize the importance of having an incentive to clear out payments of the channel and highlight the vulnerability of open payments compared to settled balances.The conversation between Jerratsch and Poon delves into the topic of channel histories and holding funds hostage. They discuss the problem of one party holding all the funds at some point, leading to negotiations for their return. They explain that reserve requirements are not effective in preventing this, but setting a hard requirement on the spendable amount could provide mitigation. They mention the complexities of Alice mutating a transaction where she has more money than Bob, but Bob has funds locked up in a multisig.In a thread discussing the Lightning Network protocol, Jerratsch and Poon discuss the ability of the client to close a channel. They note that the client can enforce the channel despite the slight favor given to the server in the channel design. They explore hypothetical scenarios involving mutated commitments and hostage negotiations. They determine that if Alice resubmits Commitment 20, she would lose BTC while Bob would still receive the funds. They also highlight the security differences between open payments and settled balances, suggesting a hard requirement on the spendable amount as a possible mitigation.Poon explains the potential for a client to hold up funds from the server by mutating their transaction. He provides an example where Alice's mutation causes the server to lose funds. He discusses the implications of reserve requirements and how they can be circumvented by an attacker with more money. He suggests setting a higher minimum stealable amount for Alice to mitigate this issue.In an email exchange, Poon offers feedback on Jerratsch's Lightning Network Payment-Hub + Client implementation in Java. He suggests not calling it a Lightning Network implementation due to differences in design and trust models. Poon raises concerns about exit scams, malleability risks, and an asymmetric playing field. They agree that payment channel-based systems have value in allowing important transactions of higher value while leaving space for everyday payments on the blockchain.Jerratsch has developed a Lightning Network Payment-Hub + Client implementation in Java, accessible on http://thunder.network and https://github.com/matsjj/thundernetwork. The implementation is low-trust, working on the current Blockchain without requiring softforks. Jerratsch plans to develop a potent backend in the future and encourages other developers to add these functionalities to their existing wallets. The use of such payment networks can alleviate pressure in the blocksize-debate and leave more space for important transactions. Jerratsch is available for further explanations and discussion on IRC channels under the name mjerr.
Updated on: 2023-07-31T18:12:48.074676+00:00