[Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

Mon Sep 9 20:11:52 UTC 2019

We went ahead with this idea and implemented it in muun wallet as an
experiment: you can scan an invoice, and if there isn't a route with enough
capacity to the destination node, we'll open a channel directly and, once
it's locked, fulfill the payment using that channel.

The initial idea was to improve the UX of not being able to route a
payment. However, since we have to wait until the channel is locked to make
the final hop of the payment, the full process might take about an hour,
depending on the block times. That generates a couple of UX challenges:
* The user is expecting lightning payments to be completed instantly, so it
might be preferable to fail the payment rather than locking it for an hour
until the channel is opened.
* Most invoices in the wild have 10/15 minute expirations, so they don't
even qualify for doing something like this.
* Even if the user generates the invoice manually, most interfaces default
to 1 hour expiration, which might be too little time.

Given these constrains, we decided that the best application for this flow
is to top-up your own node. That is, add outbound capacity to your node in
a non-custodial manner. We'd love to hear if you have some idea as to how
to make this use case better, or apply this concept to other use cases.

On Fri, Aug 16, 2019 at 12:58 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> 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 the destination.
>
> This is a good idea, but one with some difficulties in implementation.
>
> * The current onion route format contains the next short-channel-id (and
> in particular not the node-id of the next hop in the route).
>   Indeed, short-channel-ids were invented to reduce the size of the onion
> route format.
>   If a channel used to exist between nodes, then the payer might have
> gotten this short-channel-id in the past via gossip.
>   Then later, if the channel is closed, most implementations will forget
> the short-channel-id (and thus would probably also forget *which* node the
> short-channel-id used to be connected to, so determining the next node for
> the just-in-time channel opening would be difficult).
>   * C-Lightning retains this information for some blocks but will forget
> it at some point.
>   * Implementations that do this "just-in-time" channel-opening will need
> to remember this short-channel-id for longer.
> * The final HTLC going to the payee has the tightest time schedule.
>   If this HTLC has a timeout that is too near, the payee will reject the
> payment.
>   Since channel opening requires blocks to pass in order to confirm the
> funding transaction, by the time the HTLC reaches the payee, the timeout
> might now be judged too near and the payee will reject the payment anyway.
>   * The spec itself recommends the use of "shadow routing".
>     Briefly, the payer obscures who the payee is by adding a greater
> timeout to the payee than the minimum required by the payee.
>     (since timeouts decrease at each hop, an intermediate node can guess
> who the payee is by determining how small the remaining timeout looks.)
>     This can mitigate the above effect.
>     C-Lightning implements shadow routing.
>
> However, this same idea would be greatly helped by trampoline routing:
>
> * The planned trampoline routing indicates the node id of the next
> trampoline hop, thus not requiring implementations to remember who a closed
> short-channel-id used to be connected to.
> * Trampoline nodes will generally require a much larger fee and timelock
> budget, because they also have to build routes.
>   If the fee and timelock budgets are big enough, then the trampoline node
> might decide to open a direct channel to the next trampoline node
> "just-in-time" for the next trampoline hop.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Wed, Aug 14, 2019 at 8:42 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > > 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.
> > >
> > > Further, `push_msat` has the drawback of not providing
> proof-of-payment, thus an intermediate hop node may be unable to claim
> funds.
> > > (I believe `push_msat` was a mistake: you should simply make a normal
> HTLC payment (that provides proof-of-payment) after the channel is deeply
> confirmed, and `push_msat`, if you read lightning-rfc, does have this
> warning that you cannot trust money you receive that way until the channel
> is deeply confirmed.)
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Thursday, August 15, 2019 2:05 AM, ecurrencyhodler <
> ecurrencyhodler at gmail.com> wrote:
> > >
> > > > >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. Bob -> Me
> > > >
> > > > Scenario 1
> > > > If Bob pays the invoice and the routing node opens a payment channel
> and pushes sats to me, you could stipulate that the routing node isn't able
> to fully take ownership of the sats until 6 confirmations potentially via
> Hodl Invoices (by the time the routing nodes channel with pushed payments
> confirms with mine).  But I could still make LN payments instantly through
> the routing node because the routing node just needs to wait until the 6
> confirmations and settle all accounts after the fact.
> > > >
> > > > Scenario 2
> > > > Bob and I know each other so if channel disappears, it's basically
> the same situation with Thor's instant channel.  But we could completely
> remove scenario 2 and only allow routing nodes to open channels to me as
> long as Bob makes the payment.
> > > >
> > > > On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> > > >
> > > > > 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 product until the channel is deeply confirmed to be opened.
> > > > > At least this way, you can perform the preparation in parallel to
> your other startup operations for starting your business before actual
> launch of your merchant website.
> > > > >
> > > > > >
> > > > > > >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 disadvantages do you see over this proposal and say
> something like autopilot?  Or do you just prefer manual channel management
> overall?
> > > > >
> > > > > This should eventually be implementable by some kind of
> auto-system.
> > > > > It is still early days and a lot of infrastructure is yet to be
> written.
> > > > >
> > > > > Regards,
> > > > > ZmnSCPxj
> > > > >
> > > > > >
> > > > > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj <
> ZmnSCPxj at protonmail.com> wrote:
> > > > > >
> > > > > > > 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 reuse the same onchain funds over and over to
> make more liquidity until the submarine swap provider runs out of onchain
> funds or you have sufficient liquidity or your money has been drained by
> the fees involved.
> > > > > > >
> > > > > > > While this requires onchain funds, presumably as a new
> business or merchant you will have capital in some form before starting
> your business.
> > > > > > > The most sensible way to store and transport financial capital
> is, of course, Bitcoin, thus you already have what is needed to start this,
> you simply have to do it before you perform other operations.
> > > > > > > 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.
> > > > > > >
> > > > > > > Regards,
> > > > > > > ZmnSCPxj
> > > > > > >
> > > > > > > Sent with ProtonMail Secure Email.
> > > > > > >
> > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler
> Blockchains <ecurrencyhodler at gmail.com> wrote:
> > > > > > >
> > > > > > > > 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 it's limited to just one Lightning wallet.
> > > > > > > >
> > > > > > > > Proposal: Automated Inbound Liquidity With Invoices
> > > > > > > >
> > > > > > > > For Who: Full Lightning Network nodes
> > > > > > > >
> > > > > > > > Problem: Waiting for inbound liquidity as channel
> establishes when you first come online and want to receive a LN payment.
> > > > > > > >
> > > > > > > > Solution: Embedding the node uri of the invoice creator,
> along with amount to be routed.
> > > > > > > >
> > > > > > > > Scenario:
> > > > > > > >
> > > > > > > > 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.  Bob’s wallet sees an invoice + uri.  Maybe even tries to
> route.  When it doesn’t see anything, it auto opens a channel + pushes
> 100,000 sat payment.
> > > > > > > > 5.  I now own and can spend 100,000 sats instantly.
> > > > > > > >
> > > > > > > > Considerations:
> > > > > > > >
> > > > > > > > -   This auto establishing of channels and pushing payments
> isn’t for all LN nodes.  Just routing nodes.
> > > > > > > > -   Bob doesn’t need to be the one to establish the
> channel.  He can push the information down the line until a node dedicated
> to routing is found.  The routing node can then be the one to establish the
> channel with me.
> > > > > > > > -   Certain specifics need to be flushed out such as the
> size of Bob’s channel.  Right now I think Bob can manually set the size of
> the channels to be established on his end.  Should be smaller channels at
> first.  If the person gets paid again, just establish another channel
> towards the same node if there isn't enough capacity.
> > > > > > > > -   Routing nodes who provide this service can charge a
> premium.
> > > > > > > > -   Bob, as a liquidity provider, won't cheat against
> himself so I can make LN payments instantly.
> > > > > > > > -   The beauty behind this proposal is that I can receive a
> payment instantly, I can send payments instantly, and that it hides
> everything from me as an end user.
> > > > > > > > -   Can possibly be extended to neutrino LN wallets if they
> are public.
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190909/ef59424f/attachment-0001.html>