Topic: How to Solve the Non-Mining Node issue and Increase Real Scalability (Read 238 times)

So you are also saying the Core Devs are too incompetent to make it happen.

That seems to be the problem with the core devs and their supporters,
hardware not good enough, programming unable to accomplish simple tasks.

So be it,
bitcoin lack of full nodes are on your incompetent heads.

Locking thread because according to the above users, btc core devs are just too incompetent to require a full node running with an LN hub.

Good Day.

Next question, "How do you verify LN hub actually store whole blockchain and not obtain part of it from blockchain explorer API or another full nodes when needed?"

Well, what stops a LN user from just removing the extra requirements from their client? It's open source after all. That doesn't sound like it would make them incompatible with the network.

That doesn't make the solution simple, that makes it impossible. How do you force LN hubs to run a full node? Where do we draw the line between hub and not hub? Do all participants draw that line differently? If you could, as a network, choose not to do business with a node with a large number of channels unless they can also verify it is running on a full node, somehow, what does that do? The hub could divide its channels across several of its own nodes, keeping under the threshold to be considered a "hub". I think this idea is either virtually impossible or useless.

   Why on Earth should someone be required to run a full node just to transact?  Especially transact on the LN, which is a second layer solution. If the developers of LN went that route, an alternative second layer solution would be offered. After all, the original white paper already laid the ground work for SPV nodes. People should not be required to run a full node unless they want to. Furthermore, the problem is not keeping up, it is trying to catch up if you have to start from scratch. It already takes most people who run a home node several hours, if not days to complete the verification if the have to start from scratch. If I were a potential new user and wanted to try out the LN to buy a cup of coffee, I would probably lose my patience in several seconds. Not many are going to be willing to wait several hours or days to explore this payment option.
   I suppose that a blocksize increase to 8 mb with a 3% increase per year is okay. However, good luck getting anywhere near a consensus on that proposal.

How to Solve the Non-Mining Node issue and Increase Real Scalability while keeping fees from skyrocketing.

Issues on Non-mining Nodes, are that their won't be enough due to ever increasing hardware costs.
Two very observable facts have come to light after reading BTC topics.

1. A Large Group believes upgrading hardware to give more transactions per 10 minute onchain blocks is inconceivable.
2. While the very same Group believes that upgrading hardware to process thousands of transactions per second on Lightning network hubs is a non-issue.

---

IE: https://bitcointalksearch.org/topic/m.51376928
 

Also even the dimmest among us , realize that LN Fees will exceed many Altcoins.
(It is really because of the current block size limits.)

---

So knowing the above , the solution becomes apparent.

Since no one worries about the hardware requirements of LN hubs since they are a for-profit venture.

The solution is simple,
Bitcoin needs to make a code change that requires all LN Hubs to run a FULL NODE.
Not the scaled down nodes, like many use, but True FULL nodes with the Full Blockchain stored and letting new users sync the entire blockchain from them.

Considering LN Hubs locking bitcoin take direct advantage of Bitcoin,
LN Hubs should have to give back to the community thru the support of maintaining FULL Nodes.

Once this is accomplished , we can stop the petty infighting over blocksize and hardware performance.

The next step after is to set a blocksize increase to 8MB per block
(This is the maximum size, not every block will be this size for years to come, as the blocksize will only fill to meet the needed transactions.)
In addition, a 3% yearly blocksize increase will be included with the 8MB code change, to offset future growth.
Hardware performance grows faster than 3% a year, so this is a non-issue.

Doing the above will solve Bitcoin Scaling issues for years to come and with a small ever increasing %,
help keep transaction fees affordable for the majority of the world's users.

Doing nothing however,
forces users to use LN or the cheaper Altcoins as onchain bitcoin fees will become a deterrent to future growth.

For the price & value of bitcoin to truly grow requires that bitcoin onchain performance actually increase, not remain stagnant.

FYI:
LN which many thought would solve bitcoin scaling issues, is becoming apparent ,
that LN is doing nothing more than OFFLOADING transactions from the BTC onchain network,
If not used correctly LN actually decreases usable onchain scaling instead of increasing it.
LN is a Niche market service that really only helps users transacting with a singular entity on a multiple basis,
which this is totally useless for the majority as they transact with multiple entities on usually a monthly or weekly basis
at most.