Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 > 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 > > 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 wrote: > > > > > > > Good morning
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 setups, like a submarine swap. It does work for Bitrefill's Thor (ie. turbo channels) because you are trusting them to hold your money until the channel fully confirms. Per the RFC, "push_msat is an amount of initial funds that the sender is *unconditionally* giving to the receiver". * You *can* use an HTLC payment once the channel is deep enough, but you'll have to wait until the channel is locked to receive the money and be able to spend it. While this might be good enough for some use cases, like charging your own node, it doesn't provide the seamless UX for lightning payments you're looking for. 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. 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 > 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 > 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 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 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 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 > > > > 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
>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 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 > 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 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 > > 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 disadvantages do you see over this proposal and say something like autopilot? Or do you just prefer manual channel management overall? On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 preferred and they are charging a premium, I wonder if the opportunity cost here would be worth it. It's also possible to set shorter HTLC's for unilateral closures for these specific channels. >Another approach could be that wallets start using the already existing fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin address. You know I actually really like this feature of LN invoices. It's very practical and a great stop gap. My only gripe is that it keeps the user off the LN and they still would have to wait confirmations in order for their BTC to be "confirmed". Automating inbound liquidity with push payments would make it instant as well as keep users on the LN. >Another way is to set up a "temporary" custodian channel if the receiver doesn't have enough inbound capacity. How it would work is that you have a third party custodian (i.e the wallet provider) receives the money on your behalf. The next time you want to send something, this channel takes top priority. Yea. This is a great suggestion. And probably where things will end up for mobile neutrino Ln wallets in the near future. But the benefits to automating inbound liquidity with invoices is that it would be non-custodial while offering almost the exact same experience. On Tue, Aug 13, 2019 at 6:31 AM Hampus Sjöberg wrote: > 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 locks the funds for the other part. > > Another approach could be that wallets start using the already existing > fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin > address. > This way, the sender could send the funds on-chain should it fail to send > over Lightning. > This however requires the sender to have off-chain funds available which > is probably not the case. What could be done here is a splice out or a > submarine swap, but they are not well established yet unfortunately. > > Another way is to set up a "temporary" custodian channel if the receiver > doesn't have enough inbound capacity. > How it would work is that you have a third party custodian (i.e the wallet > provider) receives the money on your behalf. The next time you want to send > something, this channel takes top priority. > This way the on-boarding process is pretty much solved, if you are OK with > some trust. > > What do you think? > > Cheers > Hampus > > Den mån 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains < > ecurrencyhod...@gmail.com>: > >> 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 is a good point and very cool you were able to do that for the Lightning Conference (hopefully I'll see you there!). Perhaps another condition should be that if I am a public node and already connected to a node, the URI is not embedded in the invoice but instead should be gathered via the gossip network. But keep in mind that the intended goal of this proposal is for the end user to have a completely automated experience from invoice payment to payment reception without having to manage any channels. >So this proposal is mainly useful where you have no channels at all (thus cannot advertize your node), or don't want to publish it generally. And in both those cases, Bob probably doesn't want a channel with you because it wouldn't be useful for paying anyone else. I'm not sure I agree. All nodes who come online for the first time are not connected to any channels. And even if I hand Bob my URI, I still have to wait for the channels to be established before I'm able to receive payment. Bob could open and push a payment to me but this doesn't have to be a requirement. It could be pushed to a routing node Bob is connected to. This would also be helpful for non-technical node managers. Rather than going through the process of finding out a URI and trying to manage their channels constantly by checking for inbound liquidity, they could simply create an invoice. If inbound liquidity is lacking, the problem would be automatically solved for them. This wouldn't be the most efficient way to obtain inbound liquidity, I think that would only really be more important for more advanced LN users. Especially because asking someone to open and commit BTC to you is already a bit of a difficult relationship to negotiate as expected amount of usage will vary. Lastly, routing nodes are financially incentivized to do open a channel with me because they could charge a premium. Thor's instant channel is an example of this. On Tue, Aug 13, 2019 at 3:59 AM Rusty Russell wrote: > 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. 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. > > 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). > > So this proposal is mainly useful where you have no channels at all > (thus cannot advertize your node), or don't want to publish it > generally. And in both those cases, Bob probably doesn't want a channel > with you because it wouldn't be useful for paying anyone else. > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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 locks the funds for the other part. Another approach could be that wallets start using the already existing fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin address. This way, the sender could send the funds on-chain should it fail to send over Lightning. This however requires the sender to have off-chain funds available which is probably not the case. What could be done here is a splice out or a submarine swap, but they are not well established yet unfortunately. Another way is to set up a "temporary" custodian channel if the receiver doesn't have enough inbound capacity. How it would work is that you have a third party custodian (i.e the wallet provider) receives the money on your behalf. The next time you want to send something, this channel takes top priority. This way the on-boarding process is pretty much solved, if you are OK with some trust. What do you think? Cheers Hampus Den mån 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains < ecurrencyhod...@gmail.com>: > 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
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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. 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. 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). So this proposal is mainly useful where you have no channels at all (thus cannot advertize your node), or don't want to publish it generally. And in both those cases, Bob probably doesn't want a channel with you because it wouldn't be useful for paying anyone else. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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
