Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
Good morning Ecurrencyhodler, > Hi ZmnSCPxj! > > Submarine swaps are a great current solution, but we still have to wait for > confirmations. So would `push_msat`; until confirmed deeply the channel opening can still be cancelled by double-spending and it would be foolhardy to deliver the product until the channel is deeply confirmed to be opened. At least this way, you can perform the preparation in parallel to your other startup operations for starting your business before actual launch of your merchant website. > > >Further, while it involves fees, it does give you control over what nodes > >you make channels with, and would be a good investment in your future > >accessibility over the Lightning Network. > > What disadvantages do you see over this proposal and say something like > autopilot? Or do you just prefer manual channel management overall? This should eventually be implementable by some kind of auto-system. It is still early days and a lot of infrastructure is yet to be written. Regards, ZmnSCPxj > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj wrote: > > > Good morning Ecurrencyhodler, > > > > A current and practical way to set up incoming liquidity would be to take > > some onchain funds, create a channel to a high-uptime node on the network > > (just run an autopilot), then use a submarine swap (i.e. pay offchain funds > > to buy onchain funds). > > Then you can reuse the same onchain funds over and over to make more > > liquidity until the submarine swap provider runs out of onchain funds or > > you have sufficient liquidity or your money has been drained by the fees > > involved. > > > > While this requires onchain funds, presumably as a new business or merchant > > you will have capital in some form before starting your business. > > The most sensible way to store and transport financial capital is, of > > course, Bitcoin, thus you already have what is needed to start this, you > > simply have to do it before you perform other operations. > > Further, while it involves fees, it does give you control over what nodes > > you make channels with, and would be a good investment in your future > > accessibility over the Lightning Network. > > > > Regards, > > ZmnSCPxj > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler Blockchains > > wrote: > > > > > Hi. I'd like to propose a way for instant inbound liquidity to be > > > automated via invoices and would appreciate your feedback. It's similar > > > to Thor's instant channel but this proposal would only be valuable if it > > > becomes a standard across all lightning implementations and wallets. It > > > won't work if it's limited to just one Lightning wallet. > > > > > > Proposal: Automated Inbound Liquidity With Invoices > > > > > > For Who: Full Lightning Network nodes > > > > > > Problem: Waiting for inbound liquidity as channel establishes when you > > > first come online and want to receive a LN payment. > > > > > > Solution: Embedding the node uri of the invoice creator, along with > > > amount to be routed. > > > > > > Scenario: > > > > > > 1. Bob wants to send me 100,000 sats. > > > 2. My node just came online and has 0 inbound liquidity. > > > 3. I create an invoice for 100,000 sats. My LN node recognizes I have 0 > > > inbound liquidity so my wallet also embeds my URI in the invoice. > > > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route. When > > > it doesn’t see anything, it auto opens a channel + pushes 100,000 sat > > > payment. > > > 5. I now own and can spend 100,000 sats instantly. > > > > > > Considerations: > > > > > > - This auto establishing of channels and pushing payments isn’t for all > > > LN nodes. Just routing nodes. > > > - Bob doesn’t need to be the one to establish the channel. He can push > > > the information down the line until a node dedicated to routing is found. > > > The routing node can then be the one to establish the channel with me. > > > - Certain specifics need to be flushed out such as the size of Bob’s > > > channel. Right now I think Bob can manually set the size of the channels > > > to be established on his end. Should be smaller channels at first. If > > > the person gets paid again, just establish another channel towards the > > > same node if there isn't enough capacity. > > > - Routing nodes who provide this service can charge a premium. > > > - Bob, as a liquidity provider, won't cheat against himself so I can > > > make LN payments instantly. > > > - The beauty behind this proposal is that I can receive a payment > > > instantly, I can send payments instantly, and that it hides everything > > > from me as an end user. > > > - Can possibly be extended to neutrino LN wallets if they are public. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://
Re: [Lightning-dev] Paper - Modeling a Steady-State Lightning Network Economy
On August 13, 2019 6:23:31 AM GMT+02:00, ZmnSCPxj
wrote:
>Good morning Gregorio,
>
>
>> We argue that in such scenario, in a network of n connected nodes,
>there is a tendency towards a state where exactly n-1 channels have
>perfectly balanced flows in the two directions ("self-balancing"
>channels), while all other channels are either unused, or have a
>permanent tendency towards imbalance: the channel balance accumulates
>at one end and the channel is only intermittently available in one
>direction ("stuttering" channels). We note that the "self-balancing"
>channels form a spanning tree of the network graph, which we call the
>"core spanning tree" of the payment network.
>
>I have observed this as well in my armchair.
>Indeed, the worst-case scenario for this would be a single central hub
>with n-1 channels to n-1 client nodes, with the hub itself as the nth
>node.
>
>Fortunately, it seems to me that such a steady state will mildly shift
>and additional channels will still be used intermittently.
>(I have not read your paper in completeness yet, only the abstract
>above, so if my ramblings have already been considered in your paper,
>do feel free to ignore me).
Indeed even in the abstract steady-state scenario described in the paper, more
than n-1 channels are expected to be used (although intermittently).
But the more general point, anyway, is that no steady state will ever exist in
practice. Thinking in terms of black and white in this case helped to clarify
my thoughts around the problem (and makes for more elegant math :) ), and as
sometimes happens it lets some useful knowledge emerge: this is in the end the
spirit of the paper. I would say that your intuition about the continuously
shifting equilibrium is in line with mine.
>For instance, consider a world where Lamborghini production experiences
>a paradigm shift that massively reduces the cost of production while
>increase quality.
>Inevitably, Lambo prices in terms of Bitcoin will decline, as a
>consequence of this improvement.
>Thus, capacity in channels going Lamborghini producers becomes
>underutilized as demand for the product saturates while supply
>increases.
>
> [...]
>
>Thus, I think that the minimum of n-1 channels would not remain stable
>for long, given an actual real-world where change *is* the
>steady-state.
>Assuming a continuously thriving and innovating global economy, we will
>expect that there will be transient situations where demand and supply
>for various products changes wildly.
>In such situations, any "extra, unneeded" channels would end up
>catching the additional capacity need as various innovations and
>improvements in the economy occur and create change in demand and
>supply.
>I believe the overall steady state will have c*n channels rather than
>merely n-1, where c is some constant greater than 1, due to various
>local transient demand/supply shocks.
I would put it simply in this way: the always-shifting patterns of demand and
supply in a dense web of channels will naturally cause agents to add traffic to
channels that were previously not used, and remove traffic from channels
previously used, resulting in a continuous shift in equilibrium.
In this case I would not say it is a matter of "additional capacity needs",
though. I think it could be misleading... a hypothetical Lambo dealer could
have just one channel used for inflows/outflows of funds, and immediately send
back through the channel all the received income (to buy some store of value).
In such case the capacity would not matter much even with a big shift in demand.
(... and not included in the paper are a whole bunch of considerations about
how having many channels helps the general resilience and flexibility of the
network, but those should also be kept in mind.)
Thanks for the feedback!
Regards,
Gregorio
>Regards,
>ZmnSCPxj
___
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
>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 rout
Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
Good morning Ecurrencyhodler, It seems to me a trusted model then. Regardless of who makes the channel (the payee cannot determine who the payer is anyway) the payee cannot trustlessly release the product until the channel is deeply confirmed, else your security is only 0-conf, not off-chain. Further, `push_msat` has the drawback of not providing proof-of-payment, thus an intermediate hop node may be unable to claim funds. (I believe `push_msat` was a mistake: you should simply make a normal HTLC payment (that provides proof-of-payment) after the channel is deeply confirmed, and `push_msat`, if you read lightning-rfc, does have this warning that you cannot trust money you receive that way until the channel is deeply confirmed.) Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, August 15, 2019 2:05 AM, ecurrencyhodler wrote: > >So would `push_msat`; until confirmed deeply the channel opening can still > >be cancelled by double-spending and it would be foolhardy to deliver the > >product until the channel is deeply confirmed to be opened. > > Okay so there's 2 situations here I'd like to explore: > > 1. Bob -> routing node -> Me > > 2. Bob -> Me > > Scenario 1 > If Bob pays the invoice and the routing node opens a payment channel and > pushes sats to me, you could stipulate that the routing node isn't able to > fully take ownership of the sats until 6 confirmations potentially via Hodl > Invoices (by the time the routing nodes channel with pushed payments confirms > with mine). But I could still make LN payments instantly through the routing > node because the routing node just needs to wait until the 6 confirmations > and settle all accounts after the fact. > > Scenario 2 > Bob and I know each other so if channel disappears, it's basically the same > situation with Thor's instant channel. But we could completely remove > scenario 2 and only allow routing nodes to open channels to me as long as Bob > makes the payment. > > On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj wrote: > > > Good morning Ecurrencyhodler, > > > > > Hi ZmnSCPxj! > > > > > > Submarine swaps are a great current solution, but we still have to wait > > > for confirmations. > > > > So would `push_msat`; until confirmed deeply the channel opening can still > > be cancelled by double-spending and it would be foolhardy to deliver the > > product until the channel is deeply confirmed to be opened. > > At least this way, you can perform the preparation in parallel to your > > other startup operations for starting your business before actual launch of > > your merchant website. > > > > > > > > >Further, while it involves fees, it does give you control over what > > > >nodes you make channels with, and would be a good investment in your > > > >future accessibility over the Lightning Network. > > > > > > What disadvantages do you see over this proposal and say something like > > > autopilot? Or do you just prefer manual channel management overall? > > > > This should eventually be implementable by some kind of auto-system. > > It is still early days and a lot of infrastructure is yet to be written. > > > > Regards, > > ZmnSCPxj > > > > > > > > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj wrote: > > > > > > > Good morning Ecurrencyhodler, > > > > > > > > A current and practical way to set up incoming liquidity would be to > > > > take some onchain funds, create a channel to a high-uptime node on the > > > > network (just run an autopilot), then use a submarine swap (i.e. pay > > > > offchain funds to buy onchain funds). > > > > Then you can reuse the same onchain funds over and over to make more > > > > liquidity until the submarine swap provider runs out of onchain funds > > > > or you have sufficient liquidity or your money has been drained by the > > > > fees involved. > > > > > > > > While this requires onchain funds, presumably as a new business or > > > > merchant you will have capital in some form before starting your > > > > business. > > > > The most sensible way to store and transport financial capital is, of > > > > course, Bitcoin, thus you already have what is needed to start this, > > > > you simply have to do it before you perform other operations. > > > > Further, while it involves fees, it does give you control over what > > > > nodes you make channels with, and would be a good investment in your > > > > future accessibility over the Lightning Network. > > > > > > > > Regards, > > > > ZmnSCPxj > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler Blockchains > > > > wrote: > > > > > > > > > Hi. I'd like to propose a way for instant inbound liquidity to be > > > > > automated via invoices and would appreciate your feedback. It's > > > > > similar to Thor's instant channel but this proposal would only be > > > > > valuable if it beco
