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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev