A proposal by Lisa Neigut allowing LN nodes advertise their willingness to provide incoming capacity in exchange of fees in a “market” of advertised liquidity rates. This would help merchants to have access to incoming capacity which they need in order to receive payments from customers. The current alternatives would be either for customers to wait for on-chain confirmations and open a new channel or for merchants to make arrangements with other merchants that offer channel liquidity.
Commitment transactions are huge part of the penalty system Lightning enforces to make sure everyone plays nicely with one another, it make sure that if someone in the channel broadcasts an older transaction, thus trying to scam the other party, the commitment transaction will allow the first party access to the scamming party’s coins.
There were recently a few proposals to edit the commitment transaction, mainly the edits are about the format. Making the CLTV timeout symmetrical to avoid trying to pressure the peer into closing, making the remotepubkey BIP-32 styled and using the OP-TRUE style output to allow Child Pays For Parent fee dependancy.
A proposal was made on lightning-dev for a fee-less, omni-beneficial rebalancing scheme in LN channels.
Rebalancing a Lightning channel is currently a bit of work, to understand what we’re talking about, lets first give an example of what rebalancing a channel is.
A very interesting question was raised by ZmnSCPxj on transporting smart contracts through LN, which is possible in principle if the smart contract can be implemented as a Bitcoin Script. An opinion was given that Poon-Dryja channel is more reliable for transporting “arbitrary” contracts than Decker-Wattenhofer or Decker-Osuntokun-Russell channels, although the latter are better in every other sense.
Dmytro Piatkivskyi started the following discussion on lightning-dev regarding the topic of channel rebalancing.
There has been a lot of discussion on sending cycle transactions to oneself to ’re-balance’ the network. On LN mailing list  or numerous places elsewhere. There has been even a paper suggesting a smart mechanism to do the re-balancing (see Revive or Liquidity network ). My question is what do we actually get from it?  states that the distribution of funds in channels does not really affect the network liquidity. I can see cheaper fees or shorter paths if the network is kept balanced. But don’t you think that a smart fee strategy will do the job?
To save your time,  explains the gist from .
-  https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
-  https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
-  https://arxiv.org/abs/1007.0515
-  https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
Developer ZmnSCPxj brought to mind
that in the Elements Project implementation of lightning network, receiving via
an unpublished channel doesn’t work as it should, as he was implementating
r field in invoices he stumbled upon some issues regarding
creating invoices with