ecurrencyhodler [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-14 📝 Original message: >So would `push_msat`; ...
📅 Original date posted:2019-08-14
📝 Original message:
>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 <ZmnSCPxj at 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 <ZmnSCPxj at 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 <
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190814/fff0674c/attachment.html>;
📝 Original message:
>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 <ZmnSCPxj at 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 <ZmnSCPxj at 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 <
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190814/fff0674c/attachment.html>;