Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?
Good morning Rusty. To add to roasbeef's point, I don't think lightningpowerusers.com is a good indicator for market tolerance for higher fees either. It's highly connected and does a lot of routing because Pierre has on boarded many users through the node launcher. That means most of these users aren't power users and therefore aren't technically skilled enough or aware of how to find a cheaper route. I agree with the sentiment that the network is still too young to derive any meaningful observations around a routing fee market. This will become clearer though as more routing tools and analytics are created for routing node operators as well wallet users. On Fri, Oct 11, 2019 at 6:34 PM Olaoluwa Osuntokun wrote: > Hi Rusty, > > I think this change may be a bit misguided, and we should be careful about > making sweeping changes to default values like this such as fees. I'm > worried that this post (and the subsequent LGTMs by some developers) > promotes the notion that somehow in Lightning, developers decide on fees > (fees are too low, let's raise them!). > > IMO, there're a number of flaws in the reasoning behind this proposal: > > > defaults actually indicate lower reliability, and routing gets tarpitted > > trying them all > > Defaults don't necessarily indicate higher/lower reliability. Issuing a > single CLI command to raise/lower the fees on one's node doesn't magically > make the owner of said node a _better_ routing node operator. If a node has > many channels, with all of them poorly managed, then path finding > algorithms > can move extrapolate the overall reliability of a node based on failures of > a sample of channels connected to that node. We've start to experiment with > such an approach here, so far the results are promising[1]. > > > There's no meaningful market signal in fees, since you can't drop much > > below 1ppm. > > The market signal one should be extracting from the current state is: a > true > market hasn't yet emerged as routing node operators are mostly hands off > (as > they're used to being with their exiting bitcoin node) and have yet to > begin > to factor in the various costs of operating a node into their fees > schedule. > Only a handful of routing node operators have started to experiment with > distinct fee settings in an attempt to feel out the level of elasticity in > the forwarding market today (if I double by fees, by how much do my daily > forwards and fee revenue drop off?). > > Ken Sedgwick had a pretty good talk on this topic as the most recent SF > Lightning Devs meet up[2]. The talk itself unfortunately wasn't recorded, > but there're a ton of cool graphs really digging into the various > parameters > in the current market. He draws a similar conclusion stating that: "Many > current lightning channels are not charging enough fees to cover on-chain > replacement". > > Developers raising the default fees (on their various implementations) > won't > address this as it shows that the majority of participants today (routing > node operators) aren't yet thinking about their break even costs. IMO > generally this is due to a lack of education, which we're working to > address > with our blog post series (eventually to be a fully fledged standalone > guide) on routing node operation[3]. Tooling also needs to improve to give > routing node operators better insight into their current level of > performance and efficacy of their capital allocation decisions. > > > Compare lightningpowerusers.com which charges (1 msat + 5000 ppm), > > and seems to have significant usage, so there clearly is market tolerance > > for higher fees. > > IIRC, the fees on that node are only that high due to user error by the > operator when setting their fees. `lnd` exposes fees on the command line > using the fixed point numerator which some find confusing. We'll likely add > another argument that allows users to specify their fees using their basis > points (bps) or a plain old percentage. > > Independent of that, I don't think you can draw the conclusion that they > have "significant" usage, based on solely the number of channels they have. > That node has many channels due to the operator campaigning for users to > open channels with them on Twitter, as they provided an easy way to package > lnd for desktop users. A node having numerous channels doesn't necessarily > mean that they have significant usage, as it's easy to "paint the tape" > with > on-chain transactions. What really matters is how effectively the node is > managed. > > In terms of market signals, IMO the gradual rise of fees _above_ the > current > widely used default is a strong signal as it will indicate a level of > maturation in the market. Preemptively raising defaults only adds noise as > then the advertised fees are less indicative of the actual market > conditions. Instead, we should (to promote a healthier network) educate > prospective routing node operators on best practices, provide analysis > tools t >
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. > > > >
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
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 w
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
[Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices
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
