š
Original date posted:2018-10-12
š Original message:
Good morning Rusty,
>
> > It may be good to start brainstorming possible failure modes during splice, and how to recover, and also to indicate the expected behavior in the proposal, as I believe these will be the points where splicing must be designed most precisely. What happens when a splice is ongoing and the communication gets disconnected? What happens when some channel failure occurs during splicing and we are forced to drop onchain? And so on.
>
> Agreed, but we're now debating two fairly different methods for
> splicing. Once we've decided on that, we can try to design the
> proposals themselves.
I would suggest more to consider the simpler method, despite its larger onchain footprint (which is galling), but mostly because I do not see splicing as being as important as AMP or watchtowers (and payment decorrelation seems to affect how AMP can be implemented, so its priority also goes up). So I think getting *some* splicing design out would be better even if imperfect. Others may disagree on priority.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:51:44
in reply to nevent1qā¦f7ft
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:51:44Event JSON
{
"id": "03ec7ff7c71bc16b674602122927f5fd369e490c3d5ebaa9f477db8e5317ef69",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315104,
"kind": 1,
"tags": [
[
"e",
"d33837a10906296cdab5e5ff391835a12bd3f5d27bdac072961b20f094855a4d",
"",
"root"
],
[
"e",
"c82a85c210b9cef739a54b6a5c3030e93d5cff56b3d26075f587959c7bf29677",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2018-10-12\nš Original message:\nGood morning Rusty,\n\n\u003e\n\u003e \u003e It may be good to start brainstorming possible failure modes during splice, and how to recover, and also to indicate the expected behavior in the proposal, as I believe these will be the points where splicing must be designed most precisely. What happens when a splice is ongoing and the communication gets disconnected? What happens when some channel failure occurs during splicing and we are forced to drop onchain? And so on.\n\u003e\n\u003e Agreed, but we're now debating two fairly different methods for\n\u003e splicing. Once we've decided on that, we can try to design the\n\u003e proposals themselves.\n\nI would suggest more to consider the simpler method, despite its larger onchain footprint (which is galling), but mostly because I do not see splicing as being as important as AMP or watchtowers (and payment decorrelation seems to affect how AMP can be implemented, so its priority also goes up). So I think getting *some* splicing design out would be better even if imperfect. Others may disagree on priority.\n\nRegards,\nZmnSCPxj",
"sig": "8670f0e3bd143b0d82f9777039a51e293305f10daf88c2c52c1b403f4e0ce2e007b80c8707fba6757883d5fab66f647c7a222737d2309dc8710699baa16e1dc2"
}