Is the Lightning Network centralized?

[crea8ivemoiz]

Instead of broadcasting each transaction on blockchain, you can create a private LN channel with your friend, exchange funds inside the channel for many times without paying any fees, and finally close your channel by broadcasting the final state (balances) on the blockchain. So with LN you need to pay onchain transaction fees only 2 times.

[1714177159]

1714177159

[1714177159]

1714177159

[1714177159]

1714177159

[1714177159]

1714177159

[1714177159]

1714177159

[DooMAD]

Magic numbers are hard coded numbers with no proper reason - like the 1 MB hard cap - this should be rather time adjusted param like you have in the halving process.

Except that no fork, to my knowledge, has implemented it in that way.  If it was algorithmically adjusted in the code, like the halving process is, you wouldn't need to hardfork every time you change the size of the blocks.  Every single fork out there in the market right now has a "magic number" (some of them just happen to be larger integers) and will need to fork again in future to change the cap on the size of blocks that are permitted.  It's effectively an endless necessity for hardforks.  That fits the criteria of "needless complexity" in my book.  The code for it might look simple, but the logistics are far more complex.  You have to get everyone to agree where the cap should be at any given moment in time.  As soon as people don't agree, your coin fractures into two and there's suddenly yet another fork for people to argue about which one is closer to Satoshi's vision.

In comparison, BTC is implementing things that should alleviate demand on the blockchain.  If Lightning can handle some of the load and other improvements can make transaction sizes smaller, this delays the need for any hardforks.  So far, that approach appears to be working.  I certainly hope that when the time does eventually come for a hardfork, we seriously consider an algorithmic method that would help negate the need for any future hardforks.  But, chances are, we're still a long way off having that discussion.

Lightning is more decentralised because you're giving users greater choice and self-determination by having the option of transacting off-chain if they choose to (or even atomic-swapping to another blockchain when that becomes more commonplace), rather than forcing all traffic down the same road with no other options and placing all of the resource burdens on the full nodes.  The market will decide how Lightning is going to grow and evolve, purely based on how people use it.  Unlike choosing a blocksize every time you start to approach full capacity, there's no central planning involved in how much or how little people choose to use Lightning.  

Ultimately, it's going to be a natural evolution based on the daily choices each user makes, rather than an evolution led by a group of developers picking an arbitrary number from thin-air and then seeing which developers people follow and which ones fracture into ever smaller groups, all solely fixated on their fixed integers.   

But fair enough if you think that's all too complex or it doesn't appeal to your preferences.  That's why the other forks exist.  Everyone gets to follow the route they think will work out best.

[hv_]

In comparison, BTC is implementing things that should alleviate demand on the blockchain.  If Lightning can handle some of the load and other improvements can make transaction sizes smaller, this delays the need for any hardforks.  So far, that approach appears to be working.  I certainly hope that when the time does eventually come for a hardfork, we seriously consider an algorithmic method that would help negate the need for any future hardforks.  But, chances are, we're still a long way off having that discussion.

The approach appears to be working in such that 'No HF' of some software has lead always to community HFs and diluting the crypoverse - but maybe we all had to learn that lesson.

For the future, I'd prefer the other way around , and even HFs and job rotations / elections  in the dev team section.

[franky1]

at current coding. core and cash accepts anything below consensus.h limit.. and then core freely allows the mining pool to make the blocks bigger than policy which will still be acceptable to core as long as the new blocksize stays under consensus (meaning to non-mining nodes) policy is meaningless to core users as its something pools decide solely by themselves

Maybe I misunderstood but how would it be "meaningless" if it is enforced to stay under a limit even if pools can decide but only if up to that limit?

meaningless to non-mining nodes
EG imagine a law that says its illegal accept 2000 banana and another law that says its illegal to GROW more than 1000 bananas.

growers(miners) follow the do not grow more then 1000 law AND if anyone passed them 2000 banana batch. they would rject that too..
howevr CUSTOMERS(non-miners/nongrowers) do not grow banana's so they dont need to worry about the 1000 banana growth rule. they only follow the 2000 acceptance rule

however take bitcoin unlimiteds proposal a few years back (core rejected it) where by the policy.h becomes somthing non-mining nodes vote on by having s a value in their node identity and then mining pools only move forward making bigger blocks if a high percentage of nodes wave a flag to say its ok to do so.. they said it was a bad voting mechanism

kind of funny that devs that said no to it.. becasue it was them same devs that actually then went on to beg users to put "nosegwitx2" or "yesUASF"  in their identifier to see how many people wanted the core roadmap. they even promoted people put it into thier twitter usernames and other non-code social stuff such as 'buy a UASF hat and take a picture on social media and get people to share it'.. (facepalm)

Yes it is very bad because it would be open to Sybil attacks. It would be easy for some group of people to set up and run nodes in Alibaba cloud service.

you do realise the events of august.
you do realise that the pools that waved the versionbit to say yes to segwit were not even running nodes that were actually fully segwit ready.
even now today BTCC the biggest suporting pool for segwit still is not using segwit addresss for their coinbase rewards
https://www.blockchain.com/btc/block/000000000000000000251e0ea67c4fa7998df7e024d35dbadb25f943cbda2beb
13TEThZNnKPk34HYAuo1QqYMwDdjF3qeHx
try looking for BTCC using a bc1q address
then go look at bob lee and samson mow with their silly UASF hats and endless promotion since end of 2015 that "segwit is great"... its funny. that they are now too scared to even use segwit for thier own pool rewards.

nearly a year later and they stil havnt vetted their own code to have a strong enough belief its safe to use segwit themselves. but were happy to simply change the versionbits in their block sybil ID and to wear silly hats on social media

all they had to do is use whatever client(yep even old client) and just FLAG a version number.. without actually having the code in place. oh and wear the hat..

this is why the whole mandatory bilateral split was so controversial. core only had ~35% vote from november 2016-spring 2017.
so at that point core should have backed off and went back to the drawing board to find a alternative compromis the community using consensus would accept..
but instead then it was just a flagging event or threat to be pushed off th network. and done th 3card trick
that there is what even you should realise it waa a sybil attack performed to get segwit activated.

also check the block number of august first. you will see core nodes shiftd first. and it was the non core nodes that didnt move off to an altcoin until HOURS later

devs love their social drama campaigns but try to avoid code voting (avoided consensus upgrade and done the 3shell trick of a MANDATORY bilateral split) which they thought was OK because all the social media and social identifiers said it was ok (facepalm)

The Core developers should not be pressured by fraudsters like Roger Ver, Craig Wright, or the mining cartels. Do you agree or disagree?

the core developers should not pressure the community by calling anyone else the opposition/attackers/invaders/REKTers.. core should realise that its a decentralised network and if core dont get thier way using consensus, then they should have AVOIDED sybil and mandatory crap.. and instead gone back to the drawing board and they actually use thier ears to listen to the community wherby an agreement that meets the communities desires is met.

or.. if you wish to stick to the mindset that btc is core.. then stop cryng when people call it bitcoin core.
if you want the network to be core controlled then actually man up and be happy to call it bitcoin core.

you cant keep pretending its decentralised whel also campaigning anything not core should be treated as invaders..
stop flip flopping.. have a cup of coffee.. sit back and spend some time truly thinking about what you care most about
bitcoin decentralisation and consensus of multiple teams on one network. all on a level playing field of no control
or
bitcoin core centralisation with user distribution of core nodes that use mandatory upgrades

you cant have it both ways

P.S
what your stil not realising.. is.. if you stop reading reddit.. you will realise that vr, wright are not code developers. so while you point fingers at SOCIAL drama you avoiding what actually occured at code level.

whats next. wil you blame oj simpson(losely linked to th kardashian social drama)
yes ver and craig are drama queens.. but your just bleting lik a shep at faces of distraction. all whil bitcoin CODE is bing changed without consensus and into a direction that the dvs are litrally shouting "bitcoins blockchain is dead, it cant scale. so instead lock your funds into LN fortknox, and play around with unaudited/unconfirmed tranactions with hub bank managrs authorisating every pyment you want to make

LN is not a freedom of PUSH payments
LN is not a sole custody system
LN is not a guaranteed payment system

[franky1]

Magic numbers are hard coded numbers with no proper reason - like the 1 MB hard cap - this should be rather time adjusted param like you have in the halving process.

Except that no fork, to my knowledge, has implemented it in that way.  If it was algorithmically adjusted in the code, like the halving process is, you wouldn't need to hardfork every time you change the size of the blocks.  Every single fork out there in the market right now has a "magic number" (some of them just happen to be larger integers) and will need to fork again in future to change the cap on the size of blocks that are permitted.  It's effectively an endless necessity for hardforks.  

difference being.
if core done things as a consensus, and didnt delay for YEARS (even satoshi in 2010 mentioned raising it.) it could be done where the hard cap is 32mb and then the non-mining nodes algorythmacally have policy rule where the non mining nodes treat the policy as something they should consider. which then moves algorythmaccilly(without download requirement) up by 0.25mb small increments once XXX blocks are 90% near the policy limit. and so then the hard limit of 32mb changes in the background when blocks are 50% at that limit. thus giving plenty of time for people to naturally upgrade their nodes before the actual time where blocks actually reach 32mb

thus it never even gets to hit a wall and then never gets these debates occuring.
EG
imagine a 32mb consensus 2mb policy.
2018 q4: policy moves to 2.25mb without users needing to physically upgrade the nodes. as it moves algorithmically
2019 q2: policy moves to 2.5mb without users needing to physically upgrade the nodes. as it moves algorithmically

54 policy algorithm changes later (many years)
policy moves to 16mb without users needing to physically upgrade the nodes. as it moves algorithmically
the devs then release a node version where consensus.h is now 64mb. but that is still another 64 policy algorythm changes(0.25mb changes) away from users even needing to physically upgrade a node bcause theres still years between 16mb and 32mb

imagine it like 64mb consensus.h becomes hard coded in ALL future versions of core from 2024 but the blocks dont reach 32mb until 2036  thus anyone using a downloaded version from 2025-2036+ will be already set and they wont even realise it.. yes anyone in 2036 using an old 2024 version will get told their node is no longer supported.. but being 12 years out of date, its expected.. id say users of bitcoin from 2025-2036 would have upgraded before 2036 anyway. thus they would not hit a wall/debate like what happened in 2015, as it would all be pre-planned, pre implemented years before its needed

analolgy
to PC gamers.. its as simple as
if a PC game says it needs 1gb of ram do you just buy a PC with a motherboard thats max cap was 2gb.. or buy a PC with 32GB upgrad capacity and then has more than 2gb instslled or knowing you can put more ram in without needing a whol new system as and when needed.. knowing by the time a game says it needs 16gb. you can still have freedom of choice to kp on incrementing up the ram or start saving up for a MOBO that can handl 64gb ram+ knowing its years befor getting to 32mb limit

[franky1]

In comparison, BTC is implementing things that should alleviate demand on the blockchain.  If Lightning can handle some of the load and other improvements can make transaction sizes smaller, this delays the need for any hardforks.  So far, that approach appears to be working.  I certainly hope that when the time does eventually come for a hardfork, we seriously consider an algorithmic method that would help negate the need for any future hardforks.  But, chances are, we're still a long way off having that discussion.

in comparison LN.. a separate network or any coin.. is implementing things that could alleviate demand on btc blockchain.. however BTC is implemnting bad code to cause strain on the blockchain to promote LN

the need of certain things to make btc work on LN actually caused BTC to need to hard fork to allow LN features. at the time of the august hard fork. devs should have rationally thought.. "hmm seeing as there is a hard fork we are mandating for august lets do the things that can only be done at a hardfork. like logical growth onchain for legacy"

i really do laugh they say they needed to avoid a hard fork.. but then went on and actually caused one, but only for the benefit of pushing LN forward. whil ignoring what the comunity wanted for btc's blockchain

[Chaelbrin]

have been perusing and concentrate a great deal about this thing. Lightning system execution sounds a smart thought to everybody as it can spare high exchange charges. Yet, since the two gatherings straightforwardly execute with each other then I can state that it is an incorporated in that way. There are still inquiries that are flying up in my mind like there are as yet expected weaknesses that may understanding, at that point how might we settle that issue.

[Wind_FURY]

That I will not deny, but tell me which other group of developers are as good as Core?

Given we only talk about the pure protocol level and that I can only answer for myself here -

my conclusion was that a perfect protocol is as tiny as possible and does not contain any magical numbers and does not need other layers on top

Ok but you know I would disagree and ask what "magical numbers" are you talking about? Are you insinuating that the Core developers are using "magic computer science" to maintain Bitcoin?

for its most attractive and basic function (exchange money for nearly free or fees < 1cent ) it cannot be the core that came after Gavin.

There will always come an external cost on any system. Internalize on that very deeply.

So I fell back to check, what Satoshi really did / plan and I decided that BCH is the better implementation- and btw one big feature from Satoshi was, that real ppl do not matter at all - Satoshi's Bitcoin is anti-fragile to that, so no need at all to check / qualify any individuals.

Then we should follow Satoshi like a high priest of a religion? Is that how the community should decide what is and what is not Bitcoin?

Plus you did not answer which group of developers are as good as the Core developers.

Magic numbers are hard coded numbers with no proper reason - like the 1 MB hard cap - this should be rather time adjusted param like you have in the halving process.

Maybe, but at the same time that would open the network to node centralization like Ethereum, assuming you propose the block size to double every 4 or more years.

I believe it is better to regulate the block size for now and let the network have the opportunity to scale up.

And no, I m not religious, but it's always good if you back loop your thinking to sources where the success happened and why. Esp in times when things become messy and you need to distill the root protocol in order to scale that in best practice industrial manners.

But is it in your opinion that Bitcoin today is "messy"? You don't believe that it is the most robust and well-coded decentralized, cryprocurrency network?

If not, then who should take over as the "Core developers"?

And yes, no individual can decide what the best globally used Bitcoin implementation of the Satoshi protocol is, but mass adoption needs simple cheap secure on-chain TX. They will decide that for us - that is called just Bitcoin then.

Satoshi is gone and the network has grown without him. I believe we should not use him as a point of reference anymore, or Bitcoin will not continue to develop.

[DooMAD]

however BTC is implemnting bad code to cause strain on the blockchain to promote LN

In your inconsequential, biased and grossly misinformed opinion. 

I'll consider taking your view more seriously in the highly unlikely event you ever manage to say something accurate about Lightning.  Until then, I don't care what a manipulative troll thinks. 

The code clearly can't be that bad if it's supporting the chain that deals with far greater volume than any of the forks that split away from the economic majority. 

[Wind_FURY]

at current coding. core and cash accepts anything below consensus.h limit.. and then core freely allows the mining pool to make the blocks bigger than policy which will still be acceptable to core as long as the new blocksize stays under consensus (meaning to non-mining nodes) policy is meaningless to core users as its something pools decide solely by themselves

Maybe I misunderstood but how would it be "meaningless" if it is enforced to stay under a limit even if pools can decide but only if up to that limit?

meaningless to non-mining nodes
EG imagine a law that says its illegal accept 2000 banana and another law that says its illegal to GROW more than 1000 bananas.

growers(miners) follow the do not grow more then 1000 law AND if anyone passed them 2000 banana batch. they would rject that too..
howevr CUSTOMERS(non-miners/nongrowers) do not grow banana's so they dont need to worry about the 1000 banana growth rule. they only follow the 2000 acceptance rule

Then what is truly meaningful is the 2000 banana limit rule. The growers can grow 1 to 1000 but can increase it to only 2000 as enforced by the non-growers.

We have been going back to that debate many times, Segwit activated, game over. Plus this would be my reply to that, https://bitcointalk.org/index.php?topic=3670474.msg41475309#msg41475309

[zxl912157]

Hopefully my expectations are not like that, because when the Network Lightning centered then it is on the verification that there will be a Monopoly for Bitcoin.

But if only Lightning Lightning is created to accelerate the transaction and ease the transaction costs, then I will support with all my heart.
Because my job is to trade in Bitcoin.

[hoamoclan]

For me, Lightning network is going to be centralized in near future

[bitfocus]

no, Lightning is not centralized.

[fernandoclause]

Some say that the Lightning Network is centralized, but from my point of view, it's still a decentralized solution to scale Bitcoin as anyone would be able to run a Lightning node at will. The huge advantages that it provides for Bitcoin such as dirt-cheap fees, and instant transactions would be too hard to ignore to implement in the future.

However, if the Lightning Network turns out to become a centralized solution for Bitcoin (like many claims it will), then it would be doomed as only those with a lot of wealth and power would be able to participate in this ecosystem.

What are your thoughts about this? Is Lightning really centralized? Or Decentralized?

my opinion is the same as your opinion,
I think this is not fair because only rich people can get this lightning, and I think lightning is centered

[pumbum]

perhaps Lightning will be a temporary solution to speed up transactions and implementation in the usual areas, but this step of centralization is frightening. Perhaps the management of the technology at some point will be closed for editing, so it will repeat the way bitcoin will be decentralized and anonymous

[hv_]

however BTC is implemnting bad code to cause strain on the blockchain to promote LN

In your inconsequential, biased and grossly misinformed opinion. 

I'll consider taking your view more seriously in the highly unlikely event you ever manage to say something accurate about Lightning.  Until then, I don't care what a manipulative troll thinks. 

The code clearly can't be that bad if it's supporting the chain that deals with far greater volume than any of the forks that split away from the economic majority. 

I d say adoption dynamics are much more important than any static snapshots.

[DooMAD]

I d say adoption dynamics are much more important than any static snapshots.

The implication being that you think adoption will start to change and more people will look at altcoins/forks?  I suppose it's good you can hedge your bets, then, right?  One way or another, the market will decide.  We'll just have to wait and see how this all plays out.  But I still think there's still no point in having two chains both trying the same idea.  It makes sense for BTC to attempt a mix of both on and off-chain ideas if other forks are going to keep their focus purely on-chain.  Why put all your eggs in one basket if you don't need to?

[xfaqs01]

people lightning network is not cwntralize, in fact a lot of platforms right now are using it to make transaction faster, litecoin is just one of the few, and i think many will follow and use it somehow in the tokens also. be guided and read more about LN

[Rath_]

It makes sense for BTC to attempt a mix of both on and off-chain ideas if other forks are going to keep their focus purely on-chain.  Why put all your eggs in one basket if you don't need to?

Don't forget that the Lightning Network could be also used for cross-chain atomic swaps. In some cases, it still does not make any sense, but it's a feature that might be used by people who want to avoid using exchanges and escrow. Some people think that Litecoin and the Lightning Network is a perfect combination. Well, payments processors are busy implementing Bitcoin LN payments.

[Hanablue]

Few people saying its centralized and few saying not centralized.