From rusty at rustcorp.com.au Tue Nov 20 02:36:24 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 20 Nov 2018 13:06:24 +1030 Subject: [Lightning-dev] RBF and dual-fund interactions In-Reply-To: References: Message-ID: <87a7m4cw5z.fsf@rustcorp.com.au> ZmnSCPxj via Lightning-dev 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.