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