Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-09-09 Thread ZmnSCPxj via Lightning-dev
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  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 
> > >  wrote:
> > >
> > > > Good morning 

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-15 Thread ZmnSCPxj via Lightning-dev
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

2019-08-15 Thread Dario Sneidermanis
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

2019-08-14 Thread ZmnSCPxj via Lightning-dev
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

2019-08-14 Thread ecurrencyhodler
>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

2019-08-14 Thread ZmnSCPxj via Lightning-dev
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

2019-08-13 Thread ecurrencyhodler
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

2019-08-13 Thread ZmnSCPxj via Lightning-dev
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

2019-08-13 Thread ecurrencyhodler
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

2019-08-13 Thread ecurrencyhodler
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

2019-08-13 Thread Hampus Sjöberg
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

2019-08-13 Thread Rusty Russell
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