GITBOOK-429: change request with no subject merged in GitBook

SUMMARY.md

@@ -55,6 +55,7 @@
   * [Receiving Payments](lightning-network-tools/lnd/receiving.md)
   * [Unconfirmed Bitcoin Transactions](lightning-network-tools/lnd/unconfirmed-bitcoin-transactions.md)
   * [Channel Fees](lightning-network-tools/lnd/channel-fees.md)
+  * [Inbound Channel Fees](lightning-network-tools/lnd/inbound-channel-fees.md)
   * [Macaroons](lightning-network-tools/lnd/macaroons.md)
   * [Configuring Watchtowers](lightning-network-tools/lnd/watchtower.md)
   * [Pathfinding](lightning-network-tools/lnd/pathfinding.md)

lightning-network-tools/lnd/inbound-channel-fees.md

@@ -0,0 +1,42 @@
+---
+description: >-
+  Inbound channel fees allow node operators to more efficiently signal where
+  liquidity scarcities occur. This improves capital allocation in the Lightning
+  Network and allows channels to be utilized more
+---
+
+# Inbound Channel Fees
+
+Inbound channel fees allow a node operator to set a fee on the incoming channel of a payment, as opposed to only the outgoing channel. This allows for a more granular fee schedule, which more accurately signals supply and demand of liquidity.
+
+While it is currently possible to limit the flow of funds to certain peers by raising outbound fees, it is not possible to limit the flow from certain peers.
+
+Inbound channel fees make this possible and solve the problem of “outbound drains.” Such outbound drains are nodes that open channels to you, push their funds outwards through your node and close their channel, leaving you without adequate outbound, an onchain UTXO, and no compensation.
+
+## How inbound channel fees work
+
+Inbound channel fees are available as negative fees, or discounts on the outgoing channel fee. This allows for backwards compatibility, as nodes not compatible with inbound channel fees will still be able to make use of the channels, albeit without making use of the discount.
+
+To allow for safe usage of inbound channel fees, the discount is only applied as long as the total fee is larger than the combined fee of incoming and outgoing channel. This makes it impossible to lose funds through routing.
+
+Inbound channel fees are propagated as part of the general Lightning gossip, as older nodes will pass on information even if they do not understand it themselves.
+
+Positive inbound channel fees can optionally be set as well. However, as these positive inbound channel fees can only be understood by upgraded nodes, setting positive inbound channel fees is risky, as it can lead to routing failures among older nodes.
+
+To be able to set positive inbound channel fees, add the following to your `lnd.conf` file:\
+`accept-positive-inbound-fees=true`
+
+For updated nodes, both positive and negative inbound channel fees become part of the network graph and are taken into account when calculating the fee of a potential payment route.
+
+## How to set inbound channel fees
+
+Similar to outbound channel fees, inbound channel fees consist of a flat base fee, expressed in milli-satoshis, and a variable fee rate, expressed in parts per million (ppm).
+
+As of now, inbound channel fees can only be specified through the update channel policy command. For now, inbound channel fees should only be defined as a discount, e.g. set to zero or a negative value.
+
+All other values also have to be set every time this command is called. For example:
+
+`lncli updatechanpolicy --base_fee_msat 100 --fee_rate 1000 --time_lock_delta 80  --inbound_base_fee_msat -1000 --inbound_fee_rate_ppm -100 --chan_point b9740e90782497f9109fbbf4a787b1bf024e480813d781f402679a1ede96043c:0`
+
+\
+An empty array should be returned in case of success.

lightning-network-tools/lnd/sweeper.md

@@ -12,7 +12,7 @@ The Sweeper has undergone major adjustments in LND 0.18. Use this document to un
 
 When Lightning Network channels are unilaterally closed, funds are not directly settled into LND’s internal wallet, but rather into specific contracts that specify who can settle their funds when, and under what conditions. This also applies to both incoming and outgoing HTLCs, which also have to be swept.
 
-Not all sweeps are of equal importance. Some sweeps are time-sensitive and have to be confirmed within a predefined number of blocks, while others are primarily done for the convenience of being able to restore as much of the onchain funds as possible using LND’s internal wallet alone. Other sweeps, such as those picking up [anchors](https://docs.lightning.engineering/the-lightning-network/taproot-assets/glossary#docs-internal-guid-85ae5d8e-7fff-f351-537f-243d2bc233ca), are needed to bump the transaction fee of the parent transaction.
+Not all sweeps are of equal importance. Some sweeps are time-sensitive and have to be confirmed within a predefined number of blocks, while others are primarily done for the convenience of being able to restore as much of the onchain funds as possible using LND’s internal wallet alone. Other sweeps, such as those picking up [anchors](../../the-lightning-network/taproot-assets/glossary.md), are needed to bump the transaction fee of the parent transaction.
 
 The Sweeper takes the recovered amount and urgency into account when deciding on appropriate onchain fees for its sweeps. It achieves this by requiring a budget and deadline for each sweep. This budget can either be defined in the node’s configuration file, or passed on a case-by-case basis through the RPC. Inputs with the same deadline are batched into a single sweeping transaction.