[Lightning-dev] RBF and dual-fund interactions

Rusty Russell rusty at rustcorp.com.au
Tue Nov 20 02:36:24 UTC 2018

ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> 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.

Yes, you shouldn't agree to a funding tx which you have inputs which
also has tiny fees, as it might get stuck.  We'll make sure to note that
in the proposal.

> Alternatively, instead of providing change outputs for liquidity
> providers, instead require that liquidity providers cannot have a
> change output on the funding tx.

Don't require it, though that may be how they work in practice.


More information about the Lightning-dev mailing list