📅 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>;
lisa neigut [ARCHIVE] /
npub1sp…s64t2
2023-06-09 12:52:55
in reply to nevent1q…lwpj
Author Public Key
npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2Published at
2023-06-09 12:52:55Event JSON
{
"id": "19d31b9abe6fb67836d1f53b5a012903feb629b0508443fa982aed6b37a82a86",
"pubkey": "804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a",
"created_at": 1686315175,
"kind": 1,
"tags": [
[
"e",
"7d2f82c243d88197c3ccdbb3c172e25ab566f0ed67baf16e6557099ed7dfd5e3",
"",
"root"
],
[
"e",
"9a47743c056a31fb23d0f374df7316f492f903e85d230cd8d5797e3afbbdad90",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-21\n📝 Original message:\nHello Rusty. Exciting stuff! A few observations:\n\nOn Fri, Nov 16, 2018 at 12:18 AM Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e ### Confirming a splice: `splice_confirm`\n\u003e\n\u003e 1. type: 43 (`splice_confirm`) (`option_splice`)\n\u003e 2. data:\n\u003e * [`32`:`channel_id`]\n\u003e * [`64`:`signature`]\n\u003e * [`2`:`num_witnesses`]\n\u003e * [`num_witnesses*witness_stack`]\n\u003e\n\u003e\nI don't believe that you need the `signature` field here; if I'm\nunderstanding correctly the sigs for the inputs should be the witness stack\nthat you're sending.\n\n\n\u003e The sender:\n\u003e\n...\n\n\u003e - MUST ensure it will have sufficient funds post-splice above its\n\u003e reserve to pay for the splice transaction at the new feerate.\n\u003e\n\nIf fees outstrip the value of the updated splice transaction, what then?\nIt's not really possible to abandon a splice, practically you'd end up\nclosing the channel. This feels like an obvious observation, but worth\nnoting that splicing is 'risky' in that regard i.e. channel closure due to\nextenuating circumstances (fee spike).\n\n\n\u003e Message Changes During Splicing\n\u003e -------------------------------\n\u003e Once you've sent `splice_confirm` each commitment transaction is needs\n\u003e to be duplicated for every splice transaction (thanks to RBF, there can\n\u003e be multiple at once). These are in rbf-received order (increasing fee\n\u003e order, if initiator is spec compliant):\n\u003e\n\u003e Are HTLC's to be duplicated as well? CPFP seems like a neater construction\nthan RBF in this case, as it avoids fee rate negotiation and ballooning\nHTLC/commitment txn management. It also makes the single-payer for fees\n(initiator) less burdensome which is nice for skewed benefit updates. We\ncan reuse the scheme we came up with for commitment txns (either party can\nspend, I believe).\n\nWas there an argument against using CPFP on funding txns that I'm not\nremembering?\n\n\n\u003e NOTES:\n\u003e\n\u003e 1. I suggest that the option_data_loss_protect fields MUST BE set here if\n\u003e option_splice (there's no reason not to AFAICT). Or do we want to try\n\u003e TLV\n\u003e here?\n\u003e\n\n+1 for moving to TLV, in the spirit of moving towards the new spec\nguidelines.\n\n\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/261a0f03/attachment.html\u003e",
"sig": "ae746a1b31c85d75a8a2a372f9043534f02b8210c74bef87eb58e01a91e3b37f99af6f3589fa6bc524d3be534c2b213776fb4041a1da2d81130623aeaaba87c4"
}