📅 Original date posted:2021-10-08
📝 Original message:
Good morning aj,
> On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain, you need
> to calculate the fees for it in advance so that they'll be sufficient
> when you do want to put it on chain, and you can't update it without
> going onchain, because there's no way to revoke old off-chain funding
> transactions.
Yes, onchain fees, right?
*Assuming* CPFP is acceptable, then fees for the commitment tx on the new scheme (or whatever equivalent in the transitioned-to mechanism is) would pay for the transitioning transaction, so fees paying for the transitioning transaction can still be adjusted at the transitioned-to updatable mechanism.
This probably assumes that the transaction package relay problem is fixed at the base layer though.
>
> > This has the advantage of maintaining the historical longevity of the channel.
> > Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability,
>
> Maybe that's a good reason for routing nodes to do shadow channels as
> a matter of course -- call the currently established channel between
> Alice and Bob "C1", and leave it as bolt#3 based, but establish a new
> taproot based channel C2 also between Alice and Bob. Don't advertise C2
> (making it a shadow channel), just say that C1 now supports PTLCs, but
> secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx
> is buried enough, start advertising C2 instead taking advantage of its
> now sufficiently buried funding transaction, and convert C1 to a shadow
> channel instead.
>
> In particular, that setup allows you to splice funds into or out of the
> shadow channel while retaining the positive longevity heuristics of the
> public channel.
Requires two UTXOs, though, I think?
How about just adding a gossip message "this new short-channel-id is the same as this old short-channel-id, use the new-short-channel-id to validate it but treat the age as that of the old short-channel-id"?
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:04:07
in reply to nevent1q…wznj
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:04:07Event JSON
{
"id": "763af3c056cd2f62565729e65e4597ccb5881bcf852e3a3ee69fe57f294cb35b",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315847,
"kind": 1,
"tags": [
[
"e",
"bfc4ed728b228b9341f3493f5bd7d935423e85bd9d039717f691001784a42238",
"",
"root"
],
[
"e",
"8d1bee7d75a0eae36af5ff826831ddad5fd8ce3d531199875e351dbd7ffa0f6f",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2021-10-08\n📝 Original message:\nGood morning aj,\n\n\u003e On Sat, Oct 09, 2021 at 01:49:38AM +0000, ZmnSCPxj wrote:\n\u003e\n\u003e \u003e A transaction is required, but I believe it is not necessary to put it onchain (at the cost of implementation complexity in the drop-onchain case).\n\u003e\n\u003e The trick with that is that if you don't put it on chain, you need\n\u003e to calculate the fees for it in advance so that they'll be sufficient\n\u003e when you do want to put it on chain, and you can't update it without\n\u003e going onchain, because there's no way to revoke old off-chain funding\n\u003e transactions.\n\nYes, onchain fees, right?\n\n*Assuming* CPFP is acceptable, then fees for the commitment tx on the new scheme (or whatever equivalent in the transitioned-to mechanism is) would pay for the transitioning transaction, so fees paying for the transitioning transaction can still be adjusted at the transitioned-to updatable mechanism.\nThis probably assumes that the transaction package relay problem is fixed at the base layer though.\n\n\u003e\n\u003e \u003e This has the advantage of maintaining the historical longevity of the channel.\n\u003e \u003e Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability,\n\u003e\n\u003e Maybe that's a good reason for routing nodes to do shadow channels as\n\u003e a matter of course -- call the currently established channel between\n\u003e Alice and Bob \"C1\", and leave it as bolt#3 based, but establish a new\n\u003e taproot based channel C2 also between Alice and Bob. Don't advertise C2\n\u003e (making it a shadow channel), just say that C1 now supports PTLCs, but\n\u003e secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx\n\u003e is buried enough, start advertising C2 instead taking advantage of its\n\u003e now sufficiently buried funding transaction, and convert C1 to a shadow\n\u003e channel instead.\n\u003e\n\u003e In particular, that setup allows you to splice funds into or out of the\n\u003e shadow channel while retaining the positive longevity heuristics of the\n\u003e public channel.\n\nRequires two UTXOs, though, I think?\n\nHow about just adding a gossip message \"this new short-channel-id is the same as this old short-channel-id, use the new-short-channel-id to validate it but treat the age as that of the old short-channel-id\"?\n\nRegards,\nZmnSCPxj",
"sig": "715e091dd19ba4d5970116e316c176fa5f924de51221e1bcf8385b0b3b72f2bf46eef979d3e05d7f3822b685d0f5d4cc4f3f94dc31d2652fb94908404c393350"
}