Not revealing the channel capacity during opening of channel in lightning network



Summary:

The discussion on the Lightning-dev mailing list has been focused on improving the security and efficiency of the Lightning Network. One issue discussed is route-hijacking, where someone provides routing for a lower fee and users take it. The traits that make one a good forwarding node also makes one a good surveillance node. However, this second-layer Lightning network remains censorship-resistant as censorship leads to loss of profit from fees and censors can be evicted by jacking up willingness to pay fees. Another issue is anti-DoS protection, which could be accomplished with simple equivalent proofs that are somewhat more expensive to create/validate. Matt Corallo notes that there's no real reason lightning nodes have to have confidence in proof-of-funds-locked. If a node routes your payment to the next hop, how they do it doesn't really matter. Allowing things like non-lightning "channels" would actually be quite compelling. Lightning nodes today require proof-of-funds-locked largely for DoS resistance, effectively rate-limiting flooding the global routing table with garbage, but such rate-limiting could be accomplished via other means. Ugam Kamat explains that in order to have faith that the channel announced by the nodes is actually locked on the Bitcoin mainchain, we need to have the outpoint (`txid` and `vout`) of the funding transaction. The information about the funding transaction is broadcasted in the `channel_announcement` message in the `short_channel_id` field which includes the block number, transaction number, and vout.


Updated on: 2023-05-23T02:55:40.776325+00:00