From ecurrencyhodler at gmail.com Wed Aug 14 18:05:26 2019 From: ecurrencyhodler at gmail.com (ecurrencyhodler) Date: Wed, 14 Aug 2019 11:05:26 -0700 Subject: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices In-Reply-To: References: <66xm9Qi-Jii7D9LVQPbarN7T8-nvdcgbntkKs4RvPlsNaGBWGJGRJW71cMR_kelfHTaBCZEnMX221numjzjwarrCUHAEEwNTF6bhAu0it6E=@protonmail.com> Message-ID: >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 < > ecurrencyhodler at gmail.com> wrote: > > > > > > > Hi. I'd like to propose a way for instant inbound liquidity to be > automated via invoices and would appreciate your feedback. It's similar to > Thor's instant channel but this proposal would only be valuable if it > becomes a standard across all lightning implementations and wallets. It > won't work if it's limited to just one Lightning wallet. > > > > > > > > Proposal: Automated Inbound Liquidity With Invoices > > > > > > > > For Who: Full Lightning Network nodes > > > > > > > > Problem: Waiting for inbound liquidity as channel establishes when > you first come online and want to receive a LN payment. > > > > > > > > Solution: Embedding the node uri of the invoice creator, along with > amount to be routed. > > > > > > > > Scenario: > > > > > > > > 1. Bob wants to send me 100,000 sats. > > > > 2. My node just came online and has 0 inbound liquidity. > > > > 3. I create an invoice for 100,000 sats. My LN node recognizes I > have 0 inbound liquidity so my wallet also embeds my URI in the invoice. > > > > 4. Bob?s wallet sees an invoice + uri. Maybe even tries to route. > When it doesn?t see anything, it auto opens a channel + pushes 100,000 sat > payment. > > > > 5. I now own and can spend 100,000 sats instantly. > > > > > > > > Considerations: > > > > > > > > - This auto establishing of channels and pushing payments isn?t > for all LN nodes. Just routing nodes. > > > > - Bob doesn?t need to be the one to establish the channel. He can > push the information down the line until a node dedicated to routing is > found. The routing node can then be the one to establish the channel with > me. > > > > - Certain specifics need to be flushed out such as the size of > Bob?s channel. Right now I think Bob can manually set the size of the > channels to be established on his end. Should be smaller channels at > first. If the person gets paid again, just establish another channel > towards the same node if there isn't enough capacity. > > > > - Routing nodes who provide this service can charge a premium. > > > > - Bob, as a liquidity provider, won't cheat against himself so I > can make LN payments instantly. > > > > - The beauty behind this proposal is that I can receive a payment > instantly, I can send payments instantly, and that it hides everything from > me as an end user. > > > > - Can possibly be extended to neutrino LN wallets if they are > public. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: