<unnamed>

Public Key

npub1gqdch553m0nqcg47xullf030qfnlyrm9pmneyxkdgexv4mmkclrqhgnzxe

Profile Code

nprofile1qqsyqxut62gahesvy2lrw0l5hchsyeljpajsaeujrtx5vnx2aamv03sprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvsqqt5a

Publishing to

relay.snort.social

Last Notes

2023-06-09 15:12:25 CEST

- reply

📅 Original date posted:2023-01-03
🗒️ Summary of this message: A proposal suggests using a swap-in-potentiam address to draw upon liquidity when making LN payments without waiting for an on-chain transaction. This can work in reverse to increase inbound liquidity on-demand. The proposal offers advantages such as allowing the LN wallet to remain offline and being easier to implement.
📝 Original message:
Hi David,
Consider a scenario where Alice receives on-chain funds while her mobile
wallet
app is not running. The app can't perform a splice-in until it is opened.
Let's
say she doesn't open the app until she is ready to buy her coffee with an LN
payment, and there's not sufficient outbound liquidity in the channel to
make
the payment. At that point, it's inconvenient for Alice to have to wait for
an
on-chain splice-in to confirm before she can buy her coffee.
However, if she received on-chain funds with a swap-in-potentiam address,
the
app can draw upon the liquidity when the LN payment needs to be made without
having to wait for an on-chain transaction. Furthermore, Alice can defer her
decision about whether she wants to pay the fees to increase her outbound
liquidity until she needs the liquidity.
Similarly, this process can work in reverse, such that she can increase her
inbound liquidity in the channel, and pay for it, on-demand when the
liquidity
is needed and not before.
All the best,
Jesse
On Tue, Jan 3, 2023 at 10:36 AM David A. Harding <dave at dtrt.org> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230103/8ef5ad59/attachment.html>