Feed for tag: channels
Potential Privacy Issue With Dual Funded Channels

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.

Andreas Antonopolous Splicing Is Probably on of the Most Powerful and Underappreciated Features

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

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.