From rusty at rustcorp.com.au Thu Nov 22 01:29:29 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 22 Nov 2018 11:59:29 +1030 Subject: [Lightning-dev] Splicing Proposal: Now with RBF In-Reply-To: References: <87h8gh1wtn.fsf@rustcorp.com.au> Message-ID: <87bm6hoq6e.fsf@rustcorp.com.au> lisa neigut writes: > Hello Rusty. Exciting stuff! A few observations: > > On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell > wrote: > >> ### Confirming a splice: `splice_confirm` >> >> 1. type: 43 (`splice_confirm`) (`option_splice`) >> 2. data: >> * [`32`:`channel_id`] >> * [`64`:`signature`] >> * [`2`:`num_witnesses`] >> * [`num_witnesses*witness_stack`] >> >> > I don't believe that you need the `signature` field here; if I'm > understanding correctly the sigs for the inputs should be the witness stack > that you're sending. You're exactly right, that should be struck. Copy & paste from funding_signed I think. >> The sender: >> > ... > >> - MUST ensure it will have sufficient funds post-splice above its >> reserve to pay for the splice transaction at the new feerate. >> > > If fees outstrip the value of the updated splice transaction, what then? > It's not really possible to abandon a splice, practically you'd end up > closing the channel. This feels like an obvious observation, but worth > noting that splicing is 'risky' in that regard i.e. channel closure due to > extenuating circumstances (fee spike). Our simplfication of only having one splice in progress at a time, that if it goes wrong for any reason, you can't splice any more. But yes, closing the channel is the "fix". Not pretty, but simple. >> Message Changes During Splicing >> ------------------------------- >> Once you've sent `splice_confirm` each commitment transaction is needs >> to be duplicated for every splice transaction (thanks to RBF, there can >> be multiple at once). These are in rbf-received order (increasing fee >> order, if initiator is spec compliant): >> > Are HTLC's to be duplicated as well? CPFP seems like a neater construction > than RBF in this case, as it avoids fee rate negotiation and ballooning > HTLC/commitment txn management. It also makes the single-payer for fees > (initiator) less burdensome which is nice for skewed benefit updates. We > can reuse the scheme we came up with for commitment txns (either party can > spend, I believe). > > Was there an argument against using CPFP on funding txns that I'm not > remembering? On-chain space. It's better for the chain to use RBF, but I'm being swayed by your arguments, given the complexity of the RBF approach above, and the (hopeful) rarity of this case. >> NOTES: >> >> 1. I suggest that the option_data_loss_protect fields MUST BE set here if >> option_splice (there's no reason not to AFAICT). Or do we want to try >> TLV >> here? >> > > +1 for moving to TLV, in the spirit of moving towards the new spec > guidelines. OK, I'll try that in rev 2... Thanks, Rusty.