Good morning Dario,
> Having said that, if the usability of the scheme "open channel, wait until
> it's locked, then send HTLC payment" were deemed good enough, then routing
> nodes could implement this idea to route payments "just in time", even if
> there aren't any pre-existing routes to
Hello Ecurrencyhodler,
We've been considering this flow for muun wallet, which has native
submarine swap functionality, so it wouldn't be too difficult to implement.
However, there's some problems with the idea:
* As ZmnSCPxj notes, the push_msat functionality doesn't work for
non-custodial
Good morning Ecurrencyhodler,
It seems to me a trusted model then.
Regardless of who makes the channel (the payee cannot determine who the payer
is anyway) the payee cannot trustlessly release the product until the channel
is deeply confirmed, else your security is only 0-conf, not off-chain.
>So would `push_msat`; until confirmed deeply the channel opening can still
be cancelled by double-spending and it would be foolhardy to deliver the
product until the channel is deeply confirmed to be opened.
Okay so there's 2 situations here I'd like to explore:
1. Bob -> routing node -> Me
2.
Good morning Ecurrencyhodler,
> Hi ZmnSCPxj!
>
> Submarine swaps are a great current solution, but we still have to wait for
> confirmations.
So would `push_msat`; until confirmed deeply the channel opening can still be
cancelled by double-spending and it would be foolhardy to deliver the
Hi ZmnSCPxj!
Submarine swaps are a great current solution, but we still have to wait for
confirmations.
>Further, while it involves fees, it does give you control over what nodes
you make channels with, and would be a good investment in your future
accessibility over the Lightning Network.
What
Good morning Ecurrencyhodler,
A current and practical way to set up incoming liquidity would be to take some
onchain funds, create a channel to a high-uptime node on the network (just run
an autopilot), then use a submarine swap (i.e. pay offchain funds to buy
onchain funds).
Then you can
Hi Hampus!
>It won't work out in the long run because if you connect say mobile
wallets this way, one mobile could be offline, which locks the funds for
the other part.
Hmm I didn't consider mobile wallets being offline for a long period of
time. That's a good point. But if smaller channels are
Hey Rusty. Thanks for your feedback.
>If you publish your node address, Bob can already get this from the
gossip network, or the DNS seed as a last resort (and I expect
implementations to start doing this: I did it manually to buy a
thelightningconference.com ticket recently, for example).
This
While I do agree that this is a problem that we needs to be addressed
somehow, I don't agree on your proposal because I don't think we should
connect two end-users this way. It won't work out in the long run because
if you connect say mobile wallets this way, one mobile could be offline,
which
Ecurrencyhodler Blockchains writes:
>1. Bob wants to send me 100,000 sats.
>2. My node just came online and has 0 inbound liquidity.
>3. I create an invoice for 100,000 sats. My LN node recognizes I have 0
>inbound liquidity so my wallet also embeds my URI in the invoice.
>4.
Hi. I'd like to propose a way for instant inbound liquidity to be automated
via invoices and would appreciate your feedback. It's similar to Thor's
instant channel but this proposal would only be valuable if it becomes a
standard across all lightning implementations and wallets. It won't work
if
12 matches
Mail list logo
