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