Published on: 2020-01-29T13:14:19+00:00
In a recent forum post, Matt Corallo proposed an approach to prevent routing nodes from overcharging transaction fees. He suggested defining a fixed and proportional max fee and selecting a random route that pays no more than those fees unless no such route is available. He also recommended biasing towards old or good-reputation nodes, routing across nodes hosted on different ISPs/Tor/across continents, etc.Christian, from c-lightning, explained that they set up a fee budget of 0.5% and then select a random route within this constraint. They also fuzz the amount and other parameters within this range to obfuscate the distance to the recipient, i.e., slightly overpaying the recipient but simulating a shadow route. This randomization helps with privacy. Recent research results show that attempting to squeeze the very last bit of fees out has a detrimental effect on sender-receiver-privacy.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.In a thread-hijack, ZmnSCPxj discusses the possibility of route-hijacking, where someone provides routing for a lower fee and users happily take it. This creates a catch-22 situation: If users notice lower fees and go to lower-fee channels, then route-hijacking is possible and surveillors can pay via sacrificed fees for better surveillance. But if users ignore lower fees, then forwarding nodes will jack up their prices to 21 million Bitcoin `fee_base`, because users are going to go through their nodes with equal probability as lower-priced nodes. The traits that make one a good forwarding node, such as having a large number of channels, cheap fees, central location, high uptime, low latency, also makes one a good surveillance node.Fortunately, this second-layer Lightning network remains censorship-resistant, just like on the blockchain layer, and censors can be evicted by jacking up willingness to pay fees, including on-chain fees to move channels away from the censoring node and towards the node the user wants to pay.A subsequent email from Matt Corallo further explains that there's no real reason lightning nodes have to have confidence in proof-of-funds locked, as long as a node routes the payment to the next hop, how they do it doesn't really matter. Allowing things like non-lightning channels would actually be quite compelling. The reason that lightning nodes today require proof-of-funds-locked is largely for DoS resistance, effectively rate-limiting flooding the global routing table with garbage, but such rate-limiting could be accomplished via other means.In another email, 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. If we do not verify that the funding transaction has been confirmed, nodes can cheat us that a particular transaction is confirmed when it is not the case. This information is broadcasted in the channel_announcement message in the short_channel_id field which includes the block number, transaction number and vout. Since Bitcoin does not allow confidential transactions, we can query the blockchain and find out the channel capacity even when the amounts are never explicitly mentioned.In a discussion on the Lightning-dev mailing list, ZmnSCPxj and Matt Corallo responded to a question about the potential problem of not revealing channel capacity publicly but just providing a range proof of the attribute.
Updated on: 2023-07-31T22:34:54.637636+00:00