Hello Rusty. Exciting stuff! A few observations: On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell <ru...@rustcorp.com.au> 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. > 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). > 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? > 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. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
