Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-08 📝 Original message: On Sat, Oct 09, 2021 at ...
📅 Original date posted:2021-10-08
📝 Original message:
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.
> 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.
Cheers,
aj
📝 Original message:
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.
> 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.
Cheers,
aj