lightning-dev

Combined summary - Superbolt Proposal - a professionally run LN subset delivering superior UX

Combined summary - Superbolt Proposal - a professionally run LN subset delivering superior UX

The article discusses the vulnerabilities of the proposed Statechain Bitcoin Network (SBN) and how it can be attacked.

The author mentions that anyone who can update the software can easily create a fake node that appears to have completely legitimate channels to one or more real nodes, thereby making SBN worthless. They suggest that to make proof-of-uptime expensive, SBN should charge higher than current feerates for premium reliable service. The author also suggests that adding more OTS-like servers may still allow a minority OTS-server to effectively censor users.Therefore, the author proposes groups of independent citizens put funds in a k-of-n address and continuously spend that k-of-n address to itself on every block. This would require a complicated setup but would ensure the generated R indeed commits to the Merkle tree root of the group uptime proofs. The author concludes by mentioning that although this approach would use roughly the same technologies as SBN, it would be distributed and follow the principle of risk-sharing at the cost of increased blockchain usage.In an email exchange between two individuals about implementing a Bitcoin Lightning Network, one individual suggests using OpenTimeStamps (OTS) to ensure uptime of nodes. However, the other individual points out that this approach only measures node uptime and not node behavior. They use an example of how the London government's attempt to reduce the rat problem resulted in private individuals growing rats for their tails. The proposal is also vulnerable to attacks such as running fake nodes.The economics of mining should provide protection, but multiple nodes can be run by the same entity to get around per-node limits. Therefore, the proposal is modified to include minimum node capacity requirements with no maximum number of channels or capacity limits. Blinded commitments and k-of-n addresses are also suggested as an alternative approach to OTS servers.The author concludes by discussing the concept of offchain systems being pushed onchain. They explain that not everything is online at each block, only at the blocks where the offchain system is pushed onchain. The author signs off with their name, ZmnSCPxj, and regards to the recipient, Robert.The email exchange discusses ways to ensure usability and decentralization of the network, particularly regarding the SBN (Submarine Swap Network). One suggestion is to limit the maximum node size with enforced minimum liquidity requirements per channel. Another proposal is to use OpenTimeStamps for self-attestation, which has a low risk of being coordinated against by an attacker. However, the risk of a minority OTS-server censoring specific nodes remains a possibility. Additionally, proof-of-uptime may not be enough to ensure node correct behavior since it only measures uptime. The issue is presented in the fable of the rat-tail program, where measuring the number of rat tails shown does not necessarily lead to the reduction of rats in the city.Finally, there are suggestions to make proof-of-uptime more expensive and to require groups of independent citizens to put a fund in a k-of-n address and continuously spend that address to themselves on every block, with the proof-of-uptimes of the group embedded in a Merkle tree committed to in the R of the signature.In this conversation, Robert proposes a new system for the Lightning Network called SBN that would aim to ensure usability and decentralization. However, ZmnSCPxj counters that the proposal would actually create a central network of specially chosen nodes, leaving other nodes completely dependent on them. ZmnSCPxj also raises concerns about the proposed maximum node size and attestation process for joining SBN, suggesting that these measures may not actually achieve their intended goals.Instead, ZmnSCPxj proposes using OpenTimeStamps to attest to node uptime and suggests that liquidity is already visible on the blockchain. Additionally, ZmnSCPxj notes that data from cdecker establishes a lower bound on expected user experience with Lightning Network payments, as it assumes every node has an equal chance of being the payee.In response to a question about node uptime, the node shows its signatures attested on OpenTimeStamps. However, the asker would only believe the node if the set of signatures attested on OpenTimeStamps is large enough. To be accepted as a member of SBN (a group), the node needs to prove that it has liquidity, which it already does by the current gossip system, and high uptime, which can be shown by having a certain number of signatures attested on OpenTimeStamps. It is assumed that OpenTimeStamps does not discriminate against "furries," but it may be possible to hide one's "furry-ness" from OpenTimeStamps. Additionally, it is suggested that another attestation mechanism could be used, with a very low onchain footprint, to distribute the risk of attacks.The proposal to split the network into a central network of specially-chosen nodes surrounded by second-class and third-class nodes is criticized as disturbing. The

Discussion History

0
Robert AllenOriginal Post
March 3, 2020 01:19 UTC
1
March 3, 2020 05:07 UTC
2
March 10, 2020 01:52 UTC
3
March 10, 2020 12:10 UTC
4
March 18, 2020 21:51 UTC
5
March 18, 2020 23:35 UTC