lightning-dev

Combined summary - Routing and explicit trust

Combined summary - Routing and explicit trust

In June 2015, Rusty Russell engaged in an email conversation with a user named 'sickpig' regarding their subscription to a new list called lightning-dev.

Rusty confirmed that sickpig was one of the early subscribers and mentioned that there were only 15 subscribers at the time. He expressed his intention of waiting before initiating any substantial discussions on the list.The discussion revolved around the lightning-dev list, which is hosted by linuxfoundation.org. Rusty Russell explained that while the lightning network hub cannot steal money, it can only delay it, making the process trustless. However, he acknowledged that there may be time-preference costs that could affect individuals differently based on their access to other funds. Sickpig asked if they were already on the new list, to which Rusty thanked them for the question.Rusty Russell also mentioned his plan to have a conversation with CJP, the author of Amiko pay, about an open question in the future. The specific context of this conversation is unclear, but it can be inferred that it pertains to Amiko pay.Another individual named Benjamin expressed interest in a paper but had queries regarding the terms "channel counterparty" and "clearinghouse" used in the document. Rusty informed Benjamin that he had written a blog series explaining these terms, which can be found on his website at http://rusty.ozlabs.org/?p=477. Furthermore, Benjamin inquired about the risks associated with the counterparty and why routing through them would be trustless. Rusty clarified that payments could be delayed until they timed out or forced to flush to the blockchain and wait for the timeout, ensuring trustlessness. Additionally, Benjamin questioned how users of the network could find and select intermediaries. Rusty stated that this was an open question and that he planned to discuss it with CJP on the new list.The paper under discussion raised questions about the terms "channel counterparty" and "clearinghouse". The author sought to understand the risks involved in routing through these parties and why it would be trustless. They also expressed curiosity about how users could find and choose intermediaries on the network. While building trust-based level 2 protocols is a good idea, it may not be effective without explicit trust. Opening a channel requires trusting the counterparty up to a certain amount, with the risk capped at that amount if the counterparty disappears. In contrast, the current banking system allows for minimizing counterparty risk by shifting unwanted exposures. However, systemic risk poses a problem, as failures within the interconnected network can propagate unexpectedly. This means that even if A trusts B but not C, B might have exposure to C, making it impossible to diversify A's exposure.

Discussion History

0
BenjaminOriginal Post
June 23, 2015 10:36 UTC
1
June 23, 2015 10:41 UTC
2
June 23, 2015 10:56 UTC
3
June 23, 2015 11:27 UTC
4
June 23, 2015 11:32 UTC
5
June 23, 2015 12:15 UTC