[Lightning-dev] RBF and dual-fund interactions

ZmnSCPxj ZmnSCPxj at protonmail.com
Sat Nov 17 13:54:12 UTC 2018

Good morning list,

After some thinking, I suggest that RBF and dual-fund have some complex interactions.

Let us consider some node who wishes to provide liquidity in exchange for a fee.
For simplicity, let us suppose this liquidity provider owns a single UTXO containing its entire funding.

A customer appears and purchases some liquidity.
The liquidity being purchased is less than the total money of the liquidity provider.
Thus the funding tx has a change output that goes to the liquidity provider.

Suppose, while the funding tx is unconfirmed, that another customer appears and purchases liquidity.
The liquidity provider cannot provide liquidity from a confirmed output, but can only get liquidity from the change output from the first customer funding tx.

Now suppose the first customer gets tired of waiting for a confirmation on its funding tx, and RBF its funding tx.
The second customer funding tx is now removed from mempools, since its root was replaced.
Now the liquidity provider also has to ask the second customer to sign a new tx.

This is potentially an attack vector (although I suppose we could consider simply ignoring edge-case attack vectors).
Since the second customer pays the fees and designates its own inputs, it can gather all its dust, then give a very low fee, creating a large tx that has too low feerate to be mined, but too large total fee to get over the RBF rule 1 (The replacement transaction pays an absolute higher fee than the original transactions.).
The first customer can then find it very difficult to get its own channel confirmed unless it pays an uneconomical onchain fee.

To my mind, channel initiation RBF is more important than dual-fund.
Off-to-onchain services (which can already be built on top of existing LN, because proof-of-payment) can provide incoming liquidity by reversing the polarity of the satoshi flow, and in addition, can be used to put funds in cold storage or pay people onchain.


Alternatively, instead of providing change outputs for liquidity providers, instead require that liquidity providers cannot have a change output on the funding tx.
Thus the liquidity provider will have to create a transaction from its single UTXO to two UTXOs, only one of which is actually added to the channel, and the other being the liquidity provider change output.
The liquidity provider can provide this with minimum relay fee and deduct it from the channel liquidity it is selling, so that the fee for this tx is CPFP by the first customer and so initiator-pays remains.
This allows a second output that is not dependent on the funding tx, and which allows the two customers to RBF independently of each other.
It has the unfortunate drawback of increasing blockchain usage.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181117/29b03f93/attachment.html>

More information about the Lightning-dev mailing list