David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-03 📝 Original message: On 2023-01-03 03:57, ...
📅 Original date posted:2023-01-03
📝 Original message:
On 2023-01-03 03:57, ZmnSCPxj via Lightning-dev wrote:
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
> [...]
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
Good morning Jesse and ZmnSCPxj,
Is the following an accurate summary of the proposal's benefits and
costs? At some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob. At any
time, with Bob's cooperation, she can send an onchain transaction. Or,
after the contract protocol deposit transaction gets x confirmations,
Alice can instantly fund a fully initialized LN channel with Bob's
cooperation, from which she can immediately send LN payments.
If the above is accurate, how does that compare to splice outs? For
example: at some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob by opening
an LN channel. At any time, with Bob's cooperation, she can send an
onchain transaction using a splice out. Or, after the contract protocol
(LN) deposit transaction gets x confirmations, Alice now has a funded
fully initialized LN channel with Bob's participation as counterparty,
from which she can immediately send LN payments.
If the value for x blocks is the same in both cases, those two scenarios
look very similar to me.
The only advantages I see of your proposal are:
1. It allows Alice's LN wallet to remain offline indefinitely---but only
if Alice doesn't have any other funds in open channels.
2. It's easier to implement than splice-outs (I would guess)---but it
also only provides the benefits of sending onchain payments at the time
before the first LN transaction is made, whereas actual splice out can
be used any time in a channel's lifetime to immediately send onchain
payments.
Am I missing something?
-Dave
📝 Original message:
On 2023-01-03 03:57, ZmnSCPxj via Lightning-dev wrote:
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
> [...]
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
Good morning Jesse and ZmnSCPxj,
Is the following an accurate summary of the proposal's benefits and
costs? At some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob. At any
time, with Bob's cooperation, she can send an onchain transaction. Or,
after the contract protocol deposit transaction gets x confirmations,
Alice can instantly fund a fully initialized LN channel with Bob's
cooperation, from which she can immediately send LN payments.
If the above is accurate, how does that compare to splice outs? For
example: at some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob by opening
an LN channel. At any time, with Bob's cooperation, she can send an
onchain transaction using a splice out. Or, after the contract protocol
(LN) deposit transaction gets x confirmations, Alice now has a funded
fully initialized LN channel with Bob's participation as counterparty,
from which she can immediately send LN payments.
If the value for x blocks is the same in both cases, those two scenarios
look very similar to me.
The only advantages I see of your proposal are:
1. It allows Alice's LN wallet to remain offline indefinitely---but only
if Alice doesn't have any other funds in open channels.
2. It's easier to implement than splice-outs (I would guess)---but it
also only provides the benefits of sending onchain payments at the time
before the first LN transaction is made, whereas actual splice out can
be used any time in a channel's lifetime to immediately send onchain
payments.
Am I missing something?
-Dave