Good morning Dario,

> 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.

Indeed, this is why I did not consider this at all for payments: there is the 
atrocious slow time for opening a channel.

> * 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.

C-Lightning now defaults to one week, though wallets on top of it might 
override it with their own defaults.

>
> 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.

Yes, this is the same use case that onchain-to-offchain/onchain-to-onchain 
swaps (submarine swaps, Lightning Loops, whatever the cool kids call it these 
days) targets.

Though note that, if you have some onchain funds and what to have *outbound* 
capacity to the network, you can non-custodially do this, probably cheaper, by 
just making an outgoing channel yourself with your own onchain funds.

Regards,
ZmnSCPxj

>
> On Fri, Aug 16, 2019 at 12:58 AM ZmnSCPxj <zmnsc...@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@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 
> > > > <ecurrencyhod...@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 <zmnsc...@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 
> > > > > > > <zmnsc...@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 <ecurrencyhod...@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@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to