lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-21 📝 Original message: Hello Rusty. Exciting ...
📅 Original date posted:2018-11-21
📝 Original message:
Hello Rusty. Exciting stuff! A few observations:
On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/261a0f03/attachment.html>;
📝 Original message:
Hello Rusty. Exciting stuff! A few observations:
On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/261a0f03/attachment.html>;