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 <[email protected]> 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 > > > <[email protected]> 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 > > > > <[email protected]> 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 <[email protected]> > > > > > 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 > > > > > > > <[email protected]> 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 <[email protected]> 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 > > > > [email protected] > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
