Dual funding and splicing mechanisms allow initial negotiations between node to allow the node on the other end an opportunity to put funds at channel opening time or after it. Finding liquidity is a problem that had solutions suggested all the way back in November, the suggestion was, in summary, that a node will advertise initial liquidity matching via their node_announcement, this is meant to help these nodes source inbound capacity from a market of advertised liquidity rates as set by other nodes.

After a recent spec meeting, developer Rene Pickhardt noticed a potential privacy issue with this schema: a node can spam another probing for a lower bound for the amount of BTC available by this node, each time aborting the channel establishing before locking any of its own Bitcoin.

Annotated notes from Let’s Talk Bitcoin Episode 389. Taken from Professor Meow on Twitter.

@TheLTBNetwork Episode 389 annotated: Lightning Network Part. 1@aantonop: [SPLICING] is probably one of the most powerful and underappreciated features.

Full episode HERE: https://t.co/7lvFcyH0Bf 🔥🔥🔥

— Humble.Meow (@ProfessorMeo_w) February 24, 2019

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.

Follow the discussion here

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.

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 [1] or numerous places elsewhere. There has been even a paper suggesting a smart mechanism to do the re-balancing (see Revive or Liquidity network [2]). My question is what do we actually get from it? [3] 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, [4] explains the gist from [3].

• [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
• [2] https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
• [3] https://arxiv.org/abs/1007.0515
• [4] https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31