Topic: Lightning Network Discussion Thread - page 14. (Read 29773 times)

To run what I consider a nice VPS is ~$60 per month.
So just to break even means for the VPS cost only, $60 /30 days = $2 per day
If I get
1000 transactions per day, meaning I have to charge $0.002 per transaction  (30000 transactions per month)
100 transactions per day, meaning I have to charge $0.02 per transaction   (3000 transactions per month)
10 transactions per day, meaning I have to charge $0.20 per transaction     (300 transactions per month)
1 transaction per day , meaning I have to charge $2 per transaction            (30 transactions per month)
1 transaction per every 5 days, meaning I have to charge $10 per transaction (6 transactions per month)

Looking at the above rates gives me a basis line for the competition of small hubs.

But let say I want to make a profit and am not working just to break even
To make a profit I charge based on the LN transaction volume , since small nodes can't go lower than breaking even
1000 transactions per day at $0.02 per transaction  (30000 transactions per month)
100 transactions per day at $0.20 per transaction (3000 transactions per month)
10 transactions per day at $2 per transaction (300 transactions per month)
The above all give me $20 per day or $600 per month or $7200 per year

$7200 is not really a high enough wage to support a family, still below the poverty line.

so to make a living wage in California  
1000 transactions per day at $0.20 per transaction  (30000 transactions per month)
100 transactions per day at $2 per transaction (3000 transactions per month)  
10 transactions per day at $20 per transaction (300 transactions per month)

The above all give me $200 per day or $6000 per month or $72000 per year
LN could support someone quite nicely , but only at $2 per transaction and if they can get ~3000 transactions every month.

So from the above the people working for free with small hubs will
break even charging between $0.02 & $2 per transaction.
While Large Hubs with 1000 transaction per day
can charge $0.20 per transactions and make a living for their owner.

Even considering 3rd world people running LN nodes and being happy with the $7200 only per year due to exchange rates.
It means that once the people get tired of just working for free,
that the bare minimum fees per LN transaction will be between $0.20 & $2 per hub.

Not the super low costs that were predicted, and still higher than many altcoins, including litecoin onchain which was ~2 to 5 cents per transaction last I looked.

Now a Mega Hub /Bank
that process 1 million transactions per day at $0.20 each transaction would earn their corporation $200000 per day or $6 Million Dollars per month
(Most channels & Users would centralize to this Mega Hub as to avoid additional fees further choking out the smaller players.)

If you can not see than LN was designed to be Banking 2.0 after reading the above, you were not paying attention to who can really profit from it at lower fees.  

FYI:  https://cryptoslate.com/bitcoin-lightning-capacity-rises-68-in-1-month-progress-in-scaling-and-micropayments/

Nodes operated at a loss would depend upon charity and altruism in the community. I think it is reasonable to assume that nodes will only be run at a profit. But I think it is also correct to expect that routing will still be extremely cheap even if it is done at a price on the margin of satisfactory levels of profitability for node operators. Essentially you are just going to be paying somewhere between one and two hundred percent of the average cost of a node to a node operator divided by the number of transactions that he forwards. That should be minuscule. Something like 1/1,000th to 1/1,000,000th of the cost of operating a server.

But was the Lightning network really designed with having the nodes earn "profit"? Did the developers not say that Lightning will have "unfairly cheap fees"?

Why are the layered protocol deniers changing their debate from, "Lightning nodes are there to exploit users by charging high fees", to, "Why would anyone run a Lightning node if you can't earn enough from fees"?

Not in this for the profit at the moment.

It's just a really neato technology to help cultivate right now.

Sorta how like when I got into Bitcoin mining back in the day. I never imagined it would have paid off how it ultimately did. Was "operating at a loss" for years.

Same thing here.

In it for the technology and intellectual stimulation right now.

If it pays off, great. If not, no big loss, ultimately, but I had a lot of fun and learned a lot of new things in the process.

Question for anyone running a Lightning hub.

Currently transaction fess are so low , no one is making a profit and everyone is losing money.
When you add in your input costs such as maintaining a node and personal effort maintaining your node, you are at a monetary loss.

So how do you see yourself turning that into a profit.

Do you see yourself charging higher fees or do you expect the volume to increase to such a point it allows you to make a profit?

If so , please list your expected daily volume and price per transaction where you actually make a profit enough to exceed your input costs,
ie: maintain a node, electricity, internet bandwidth, and anything else required

Thanks.

Day 17.

Nothing significant to report.

Lowered fees from default levels of 1000 / 10 to 975 / 5.

Total node liquidity provided approximately 2 BTC. Staying firm at committing to at least 0.01 BTC per established channel.

    "num_pending_channels": 1,
    "num_active_channels": 172,
    "num_peers": 176,

---

    "day_fee_sum": "0",
    "week_fee_sum": "8",
    "month_fee_sum": "15"

---

  "version": 160100,
  "subversion": "/Satoshi:0.16.1/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 150

It certainly adds extra work to the development. Seeing as network consensus is a multi-lateral model for lightning (only individual payment paths need a sequence of consensus, the failure of which isn't critical to the overall network), there is no reference implementation like with bitcoin itself, and so lightning development resembles any other protocol development far more than bitcoin does. This makes sense overall; clightning appears to be focusing on the embedded and webstore/server markets (it uses the C language, and so it can be compiled for just about any platform), whereas lnd is targetting mobile, server and desktop (lnd is using rust, which I would assume is unlikely to work well for super simple embedded Point of Sale devices for instance), or Eclair which is mobile only.

This makes sense as a development model in lightning's case, however messy the interoperability issues are. The nuance is that the list of new ideas you mention are originating from the different teams, and they do not necessitate universal implementation. If lnd doesn't want to implement eltoo, there is no problem at the protocol level, they can continue to use the punishment protocol instead. Vice versa if ACINQ (the Eclair team) decides against implementing channel factories, Eclair can still interface with the lightning network at the level of the 1.0 protocol. So once the wrinkles in 1.0 interoperability are ironed out, it will function as a stable base layer in it's own right. Swapping out components of the protocol for enhanced substitutes, or adding additional network layers (e.g. channel factories) shouldn't be too disruptive with a stable base protocol operating (it's very close already).



It was a little overhyped, the supposed attack withdrew much less than half the network liquidity. I think channel factories and/or cyclic node rebalancing techniques will cater for the liquidity of good actors on the network, and (yet another) proposed system for data authentication could be the building blocks to solve the bad actors problem (this would introduce rewards for serving reliable data of any type over lightning, which can be used to give nodes a routing score). There was a suggestion by the author that this could be used to simplify or remove the need for watchtowers altogether, which would be nice (I believe eltoo goes some way in that direction already)

I think we all know that this person did not pull enough liquidity from the system to make it technically impossible to route payments that were not marginally large. It's just that there wasn't sufficient liquidity to overcome the shortcomings of imperfect routing. I'm skeptical that full client side routing may end up not being practical. Perhaps a hybrid system where a satisfactory level of privacy is achieved through onion routing while other hops in the routing are a collaborative effort? Not sure, just thinking out loud.

As I'm not a developer, in layman's terms, how complicated a task is it to mash all the different Lightning ideas together and keep it all compatible, over multiple dev teams with their own implementations?  We've got Channel Factories, Eltoo, Atomic Multi-Path, Atomic Swaps, Watchtowers and probably a few other interesting ideas besides.  I'm amazed by all the ingenuity on display with this stuff.  The only small downside is that every new idea will probably mean it takes that little bit longer to reach the stage where it's all seamlessly integrated and relatively user-friendly.  A price worth paying, for sure, though.

@Xian01 I have found a website which might be better than the in-built autopilot. This service will take into account your existing connections and suggest new ones for better connectivity. It should result in more payments routed by you. Enter your nodeid to see the results.

Yeah, biggest thing to happen in Lightning development since channel factories.


This demonstrates:

1. Lightning isn't perfect as per the 2015 original specification
2. It can be improved, and the developers know what the weaknesses are and are thinking carefully how to redesign optimally

It will take time, but the end product should be easier to use than regular Bitcoin clients. And this will be huge for Bitcoin's competitiveness as a currency, it could be like using gold with a debit card, where the actual bullion is under the complete control of the individual.

A few people on the r/Bitcoin were complaining about unexpected closure of their channels. Some people started to experience problems with payments. See the quote below.


Surprisingly, most of the Lightning Network users were unaffected. If he had kept his node longer, he might have done more damage. None of my payments so far.

Just read this Blockstream blog, and I am excited to see growing research on scaling solution and how things would really different (read awesome) down the line.

eltoo: A Simplified Update Mechanism for Lightning and Off-Chain Contracts

https://blockstream.com/2018/04/30/eltoo-next-lightning.html

Would love to discuss more/ what do you guys think?

How bad were the effects of Andreas Brekken closing his channels? I suppose it was not that bad? There was almost nothing said about it on Twitter or on Reddit, maybe to his disappointment. Hahaha.

My bad. Sorry about that. Didn't see it buried in the hyperlink text, that I obviously did not click on and read  

Morning of Day 15.

Autopilot kinda went nutty on me for a bit late last night but seemed to recover. Funded a couple more manual channels. Closed out two zombie nodes as per advice in BitCryptex's link.

Autopilot has now ended it's latest funding run and node is chugging along. Updated to latest LND via github repo last night.

Tried to work out some issues with Anon136 last night, not being able to get his eclair wallet to connect to my node, to no avail. Proper bits are being advertised on my end. Inexplicable.

Checked out some of the channel funding costs to establish all the routes I have created so far. I'm guestimating total channel fees thus far are approximately 90,000-100,000 sat.

Going to take quite some time to recover those fees.

    "day_fee_sum": "2",
    "week_fee_sum": "9",
    "month_fee_sum": "15"

---

    "num_pending_channels": 7,
    "num_active_channels": 175,
    "num_peers": 209,
    "version": "0.4.2-beta commit=92b0b10dc75de87be3a9f895c8dfc5a84a2aec7a"


EDIT: Installed ntop and starting to keep tabs on bandwidth for the bitcoind/lnd node.

  "version": 160100,
  "subversion": "/Satoshi:0.16.1/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 142

I mentioned this issue yesterday


Lightning Network is still in beta so no wonder why there are issues like that. Fortunately, it can be fixed and not everyone is affected.

https://medium.com/@robban_69827/lightning-network-routing-fud-and-zombies-776b8238e66b

I made a list of lightning nodes by address type, updated daily, here:

https://github.com/dan-da/lightning-nodes

handy for finding tor nodes, ipv6 nodes, etc.

Have you guys seen this service?

https://lightningconductor.net/channels


Haven't tried it yet but it seems pretty cool.

Can I try connecting to your node?