However, he acknowledges that this would complicate things. One issue with the current system is that receiving on the Lightning Network is actually more costly than sending, especially if the user has less balance than the initial opening of the channel. When asked if the fee can be negative to assist with channel rebalancing, Rusty explains that while this was a possibility in his original implementation, it turned out to be a strange idea that complicates routing.The conversation then shifts to the risks associated with channel initiation and the potential for hubs to close channels with some balance fee-free, leaving users without the channel opening fees and no receiving channel. The current system relies on market pressure and the fact that Bitcoin is more expensive to receive than to send due to larger inputs than outputs. However, with Schnorr signatures, this may no longer be the case, and market pressure may not be a strong enough incentive.Rusty Russell explains that fees are charged on entry to the Lightning Network channel and are paid by the party initiating the transaction. While it would be ideal for both the sender and recipient to set their own fees, forwarding nodes can charge appropriate fees for both parties. He also notes that negative fees would complicate routing and calls it a strange idea. The channel initiator is responsible for paying all onchain fees, which is simple but potentially gamable. Although there are other important factors to consider, such as opening and closing fees, the current alternatives are complex and potentially gamable, so simplicity was prioritized.In a separate email exchange, Rusty clarifies that fees are charged when entering a Lightning Network channel. If a transaction is made from A to B, A charges a fee, and if the transaction is then made from B to C, B charges a fee. However, the sender and recipient cannot set their own fees, which would have been preferable despite adding complexity. Receiving is more costly than sending, and users with more balance than the initial opening of the channel must monitor old states published as it carries risks. The question was raised about whether or not the fee can be negative to assist with channel rebalancing. The information from BOLT #3 was difficult to read for non-experts. Edward also expressed concern about who pays for closing the channel and the possibility of losing the opening fees if the other party simply cashes out the balance without keeping the channel open for receiving.Johan Torås Halseth responds to Edward's concerns and confirms that fees can be set for each direction of the channel. He provides a link to the Github page containing the channel_update message, which allows individual control over fees. After the initial mutual channel_announce message, each peer sends its own channel_update, giving users control over their own fees. Fees are charged on entry to the channel, so if there is an A->B channel, A charges the fee, and if you traverse B->C, B charges the fee. Rusty hopes this clarification resolves any confusion.Further, Johan, a member of a mailing list dedicated to discussing the Lightning Network, responds to a question posed by Edziu Marynarz about setting fees for each direction of a channel. Johan provides a link to a GitHub page that explains how each node in a channel can announce the fee it will take to route a payment in the direction leading "away" from it. He mentions the use of "channel reserves," which ensure that each node always has some balance at stake in case an old state is broadcast. Edziu had asked why such functionality would be necessary. He explains that imbalance occurs when transactions flow mostly in one direction in a bidirectional channel. To prevent this imbalance, fees can be ramped up on the receiving end of the channel that is getting large and lowered on the empty end. This approach could help with rebalancing the channels and mitigate the risk involved, as Lightning Network channels become riskier on the receive side when the channel value deviates from the original state. Edziu suggests that it would be best if Lightning Network applications could automatically regulate imbalances.In summary, there are concerns about the current fee structure for sending and receiving on the Lightning Network. Rusty Russell suggests that it would be better if both the sender and recipient could set their own fees, but acknowledges the complications this would bring. Receiving is more costly than sending, especially if the user has less balance than the initial opening of the channel. Negative fees were considered but deemed a strange idea that complicates routing. There are also risks associated with channel initiation and the potential loss of opening fees if the other party closes the channel without keeping it open for receiving. Johan Torås Halseth confirms that fees can be set for each direction of the channel and provides a link to further information. Edziu