Re: [Lightning-dev] Splicing Proposal: Now with RBF
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. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Splicing Proposal: Now with RBF
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. > 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
Re: [Lightning-dev] Splicing Proposal: Now with RBF
Good morning Rusty, > I tried to simplify RBF as much as possible; it adds a lot of > complexity :( In particular, below we have one side pay the fees (and > thus responsible for RBF), in violation of the summit agreement, > and simplified the fee amount as much as reasonable. This (initiator-pays) was proposed on the summit, by my memory. At the time, I was going to propose also that only the splice-initiator would then be allowed to add splice-ins and/or splice-outs, since the splice-initiator "owns" the splice (as it pays all the fees). And then, I would also propose that once splice-initiator indicates satisfaction with splice ins and outs, the two switch sides (but the fees proposed by the first splice-initiator remain deducted from the splice-initiator) and the other party has an opportunity to add its own splice-ins/outs, for which it would pay for. However, RBF adds a whole new dimension... It's certainly much easier to reason about a single payer of the fees. > > RBF it implicitly requires multiple (exclusive) splices at once. This > will all require a great deal of testing... Would it be useful to define a dual-funding RBF protocol first, so we have practice for splice RBF? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Splicing Proposal: Now with RBF
Hi all, I tried to simplify RBF as much as possible; it adds a *lot* of complexity :( In particular, below we have one side pay the fees (and thus responsible for RBF), in violation of the summit agreement, and simplified the fee amount as much as reasonable. RBF it implicitly requires multiple (exclusive) splices at once. This will all require a great deal of testing... Changes since initial proposal: 1. We add subtypes so `splice_init`/`splice_accept` etc are single messages. These basically allow us to describe variable numbers of variable-length fields. 2. We include both script and wscript in inputs, for p2sh-wrapping. 3. Initiator pays fees. 4. Other side gets to add the same number of inputs+outputs if they want, minimum 2 (enough for one input, one change output). 5. If we both initiate a splice at once, *fundee*'s tiebreaker (well, funder pays for everything else!). 6. Both sides give a max_extra_witness_len for inputs, to calc fee. 7. Every still-negotiable parameter is renegotiated. 8. We add RBF, at intiator's discretion (they're paying for it!) 9. The language "MUST fail the channel" has been made into "MUST error" in antipation of "soft" errors. ### Initiating a splice: `splice_init` 1. type: 40 (`splice_init`) (`option_splice`) 2. data: * [`32`:`channel_id`] * [`4`:`feerate_per_kw`] * [`2`:`num_inputs`] * [`num_inputs*splice_input`] * [`2`:`num_outputs`] * [`num_outputs`*splice_output`] * [`8`:`max_htlc_value_in_flight_msat`] * [`8`:`channel_reserve_satoshis`] * [`8`:`htlc_minimum_msat`] * [`4`:`minimum_depth`] * [`2`:`to_self_delay`] 1. subtype: `splice_input` 2. data: * [`8`:`satoshis`] * [`32`:`prevtxid`] * [`4`:`prevtxoutnum`] * [`2`:`scriptlen`] * [`scriptlen`:`script`] * [`2`:`max_extra_witness_len`] * [`2`:`wscriptlen`] * [`wscriptlen`:`wscript`] 1. subtype: `splice_output` 2. data: * [`8`:`satoshis`] * [`2`:`scriptlen`] * [`scriptlen`:`script`] The sender of `splice_init`: - if a splice is already in progress - MUST NOT send - MUST ensure each `splice_input` refers to an existing UTXO. - MUST ensure each `splice_output` is a standard script. - SHOULD ensure that `feerate_per_kw` is sufficient for the splice transaction to confirm. - MUST set `feerate_per_kw` to 253 or more. - MUST ensure it will have sufficient funds post-splice above its reserve to pay for the splice transaction at the given `feerate_per_kw` and the amount it contributes to the commitment_transaction fee - MUST NOT have total `splice_output` `satoshis` greater than its current balance minus reserve plus the total `splice_input` `satoshis`. - MUST set `max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`, `htlc_minimum_msat`, `minimum_depth`, `to_self_delay` as specified in `accept_channel`. NOTES: 1. Are we *sure* we don't want to make channel_reserve_satoshis 1% of capacity? That would remove a parameter here. 2. We explicitly allow a null splice to reset parameters or throw away history. The receiver of `splice_init`: - if it has also sent `splice_init`: - if the receiver was the original sender of `open_channel`: - MUST discard its own `splice_init` - otherwise: - MUST discard this `splice_init`. - if a splice is in progress: - MUST error. - if `feerate_per_kw` is less than 253: - SHOULD error. - if the total post-splice balance of the sender would be insufficient to meet its reserve plus the amount it contributes to the commitment_transaction fee: - MUST error. - if both nodes advertised the `option_upfront_shutdown_script` feature, and the receiving node received a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and any splice_output that `shutdown_scriptpubkey` is not equal to `script`: - MUST fail the connection. - MUST respond to `max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`, `htlc_minimum_msat`, `minimum_depth`, `to_self_delay` as specified in `accept_channel`. - SHOULD reply with `splice_accept` ### Accepting a splice: `splice_accept` 1. type: 41 (`splice_accept`) (`option_splice`) 2. data: * [`32`:`channel_id`] * [`2`:`num_inputs`] * [`num_inputs*splice_input`] * [`2`:`num_outputs`] * [`num_outputs`*splice_output`] * [`8`:`max_htlc_value_in_flight_msat`] * [`8`:`channel_reserve_satoshis`] * [`8`:`htlc_minimum_msat`] * [`4`:`minimum_depth`] * [`2`:`to_self_delay`] The sender of `splice_accept`: - consider the `splice_limit` the total number of `splice_input` and `splice_output` from `splice_init`, with minimum 2. - MUST NOT send a number of `splice_input` and/or `splice_output` which exceeds `splice_limit`. - MUST ensure each `splice_input` refers to an existing UTXO. - MUST ensure each `splice_output` is a standard script. - MUST NOT have total `splice_output` `satoshis` greater than its current balance
