Loop attack with onion routing.. [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2015-09-02T05:42:52+00:00


Summary:

The context discusses various aspects of the Lightning Network and Bitcoin transactions. Anthony Towns highlights the challenges in charging fees for Bitcoin transactions, suggesting that a fee of at least 1% would be required for a $5 coffee or a minimum of 5c for microtransactions. He also mentions the possibility of using Hash Time-Locked Contracts (HTLCs) with thousandths of satoshi as a solution. The conversation delves into the implementation of lightning transactions and the need for lightweight initiation. The participants discuss the role of H in routing a transaction to D and the importance of end-to-end communication. They also explore the idea of fines in the routing system and how they can be enforced. The conversation touches on the concept of onion routing and the need for privacy in payments. Rusty Russell proposes a scheme to ensure valid unilateral close transactions, which receives support from Anthony Towns. The discussion also addresses the smallness of blockchain fees and their potential impact on transactions. The participants consider the future exchange rate and the need for more precision or alternative solutions for small transactions. The context further examines the issues related to fines in the Lightning Network, including distribution, enforcement, and potential attacks. In a series of conversations and email exchanges between Rusty Russell, Anthony Towns, Joseph Poon, and other Bitcoin Lightning Network developers, several concerns and potential attacks on the network were discussed. One of the main concerns raised was the possibility of fraudulent behavior on the Lightning Network. One suggestion to prevent fraudulent behavior was to use different keys for each channel on the Lightning Network, which would unlink the key from the Lightning Network ID used for routing. However, it was acknowledged that this may not be enough to deter all fraudulent behavior, as someone could still construct a fake channel closure transaction. Another topic of discussion was the connection between Dave's public key ID and the HTLC transaction in order for Carol to prove to Bob that she closed the channel. Rusty argued that there was no reason for the two to be connected, while Anthony suggested that the HTLC transaction provided Dave's public key ID, which is the only name that matters. The conversation also delved into resolving hashed time-locked contracts (HTLC) in scenarios where timeouts occur. If Dave fails to resolve the HTLC within the required timeframe, Carol has to dump the commit transaction to the blockchain. However, she can include the commit transaction and HTLC transactions in the blame packet back to Bob without naming Dave. Collusion between participants in the Lightning Network was another concern. The possibility of collusion delaying transaction notifications to encourage fund deposits on specific channels was discussed. The potential risks and consequences of such collusion were explored. The risk model for the Lightning Network's payment channel system was also discussed. Concerns were raised about judging transaction timing within a large range and the need for offloading HTLCs to third-party channel liquidity providers. Delays and fees for timeout periods were debated, with the understanding that hubs assuming timeouts will never occur might lose money in the long run. The use of onion routing in the Lightning Network was another topic of conversation. The advantages and disadvantages of onion routing were explored, including the potential for faster transactions with disclosure of R but higher costs in the time aspect. The idea of sending funds to each participant with multiple signatures for different disclosure times was suggested as a possible solution. Throughout the discussions, concerns were raised about potential attacks on the Lightning Network, the need for security measures to prevent fraud, and the trade-offs involved in implementing certain features. While some ideas and suggestions were proposed, no clear solutions were finalized at the time of the conversations and email exchanges. Rusty Russell sought feedback from other developers regarding the proposed solutions. Overall, the conversations and email exchanges highlighted the importance of addressing security concerns, preventing fraudulent behavior, and finding ways to improve the efficiency and reliability of the Lightning Network.


Updated on: 2023-07-31T18:14:45.515510+00:00