Bitcoin Forum
May 07, 2024, 05:45:34 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How to Solve the Non-Mining Node issue and Increase Real Scalability  (Read 222 times)
Khaos77 (OP)
Member
**
Offline Offline

Activity: 200
Merit: 73

Flag Day ☺


View Profile
June 07, 2019, 09:22:33 PM
 #1

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://bitcointalk.org/index.php?topic=4792622.msg51376928#msg51376928
Quote from: Khaos77
Here is a thought experiment for you.
Bitcoin Devs refused to increase blocksize because of the excuse non-mining nodes would fail to keep up,
even thru block time is only 10 minutes.
 
Quote from: franky1
love it. i can just imagine that conversation

bitcoin dev salaried by corporation:
     'bitcoin cant scale because you cant receive, validate and broadcast 3000 tx in 10 minutes'
bitcoin dev salaried by corporation:
     'LN is where wveryone should be because you cant recieve, validate and broadcast thousands/unlimited tx in seconds'
community:
     'why cant bitcoin?'
bitcoin dev salaried by corporation:
     'coz hardware'
community:(in sarcastic tone)
     'ohhh the same hardware LN needs to receive, validate, sign, revoke old sig and broadcast thousands tx in seconds'

Also even the dimmest among us , realize that LN Fees will exceed many Altcoins.
Quote from: Wind_Fury
I believe if Lightning is used in a massive scale, its fees will be higher than most 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.
1715060734
Hero Member
*
Offline Offline

Posts: 1715060734

View Profile Personal Message (Offline)

Ignore
1715060734
Reply with quote  #2

1715060734
Report to moderator
"In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715060734
Hero Member
*
Offline Offline

Posts: 1715060734

View Profile Personal Message (Offline)

Ignore
1715060734
Reply with quote  #2

1715060734
Report to moderator
bones261
Legendary
*
Offline Offline

Activity: 1806
Merit: 1827



View Profile
June 07, 2019, 10:19:21 PM
Last edit: June 07, 2019, 10:49:57 PM by bones261
 #2

   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.
Taras
Legendary
*
Offline Offline

Activity: 1386
Merit: 1053


Please do not PM me loan requests!


View Profile WWW
June 07, 2019, 11:24:13 PM
Merited by bones261 (2), ABCbits (1)
 #3

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.
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.
Taras
Legendary
*
Offline Offline

Activity: 1386
Merit: 1053


Please do not PM me loan requests!


View Profile WWW
June 09, 2019, 01:21:16 AM
Merited by ABCbits (1)
 #4

Running LN hub isn't even profitable even if you're "giant" hub, because
1. LN client will automatically find best route (shortest hop / cheapest routing fees)
2. If you set high fees on your hub, some people would rather open new channel or use altcoin
3. Cost to open & close channel, unless you make user pay for it

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.

Sounds simple, but the biggest question is "How to verify LN hubs run true full nodes"?

Send hash of all blocks?
Send all block headers?
Ask random "old" blocks?
Ask random "old" transaction (assuming txindex enabled)?

Make the code verify the blockchain is stored on the hub ,
then have it verify the Genesis Block and then verify the last block synced is within an hour.

There are probably 10 completely different ways to accomplish it.
It is up for the programmers to write the code, I'll let them choose,
unless you want to say the core devs are too incompetent to carry out such a simple task.
So is that what you are saying?

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!