Advertising Node Liquidity

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 Transaction Format Update Proposals

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.

Proposal for Syncing Channel Updates
An update was suggested to include channel update timestamps to the channel range queries, the reply_channel_range will now include 4 bytes of a timestamp and the query_short_channel_ids will include a flag that is set to 1 if the node should send back a channel announcement and the updates, and would otherwise send just the updates.
LN Splicing Proposal
Last week, a formal proposal was suggested on the Lightning mailing server by developer Rusty Russell on how we can implement Splicing in lightning channels (“top-up” and “drain” bitcoin from a channel). In this post we explain the concept and briefly review the proposal.
Arbitrary Bitcoin Contracts over LN

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.

Channel Rebalancing

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].

Receiving via Unpublished Channels

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 support for r field in invoices he stumbled upon some issues regarding creating invoices with r fields.