Topic: Is the Lightning Network centralized? - page 6. (Read 1981 times)

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.

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.

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.

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.


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.

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.

 

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?


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


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.

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

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.

Yes but the question was should the Core developers be pressured and follow the agenda of the fraudsters like Roger Ver, Craig Wright, and the mining cartel?


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

Not at all my friend !
As you already have watched all the videos related, it's a technology under ( or upper ) the blockchain itself that can contain micro transiction waiting to be confirmed so you do not have to spend a fee to regulate a fraction if BTC that can cost you more than transaction itself.

Understood ?

I think Lightning network is decentralized. 

In the entire open source bitcoin world there will be pressure on everybody with real skin in the game.

You are on the right track, you re identifying Bitcoin's SPOFs (single point of failures) - as you put down here, core is one - and so will mostly fail ( or did ).

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?


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.


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

After implementing the Lightning Network, the Ethereum network will remain decentralized. All the rumors about the centralization of this technology are a lie.

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

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)

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)

"just route it around"
thats called broadcasting to mainnet to get your funds out of the channel you have with the hub.
you[$30-$30]hub[$30-30]destination                          mainnet: you[$0]
you[settledmainnet]hub[$30-30]destination                 mainnet: you[$30]

and then making another mainnet tx to put funds into a new channel with another party to hop your payments without a hub involved

you[$0-$30]hop[$30-30]hop[$30-$30]destination         mainnet: you[$30]
you[$30-$30]hop[$30-30]hop[$30-$30]destination         mainnet: you[$0]

and ofcourse.. hope the HOP your now channeled to also are not upto the same hijynx as the hub was

anyway moving forward a few concepts..
new invention.  factory.. lets call it LN fortknox.. (idea is to put funds into factories so you dont ned to settle to mainnet because your initial funding channel funding is not from your own mainnet tx. but from your mainnet funding going to fortknox an they pay your channel partner who then pays you)

you put funds into LNfortknox. and lock it up for 2 years. you then set up a channel with a well funded hub whereby you dont put funds in. and fortknox then routes a payment to the hub via their relationship and the hub sets up the initial TX to give you part of their funds
EG
instead of
you[$30 - $30]hub where that $30 is your own value you lockd in from your own mainnet tx..
its like this
you[$0 - $60]hub[$0 - $30]FK where the $30in in FK is your own value you locked into fortknox. the hubs $60 is the hbs UTXO (that he will have to settle)
and then this happens
you[$0 - $60]hub[$30 - $0]FK
you[$30 - $30]hub[$30 - $0]FK

now you have $30. but its not using your own initial UTXO you owned locked into the hub chnnel. the funds are a share of hubs initial $60 UTXO
your UTXO is locked in fortknox(factory)

moving on say your sick of hub and you want to move funds to hub2. and your new id Utu(you2)
.. now to get out of a channel you can do it without caring about rbroadcasting to mainnet. you make a payment back to fortknox and tell fortknox where you want to put that payment. so lts start with how it looks befor you dcid to leave the channel

you[$30 - $30]hub[$30 - $0]FK[$30 - $0]hub2[$60 - $0]Uto
so
you[$0 - $60]hub[$30 - $0]FK[$30 - $0]hub2[$60 - $0]Uto
you[$0 - $60]hub[$0 - $30]FK[$30 - $0]hub2[$60 - $0]Uto
you[$0 - $60]hub[$0 - $30]FK[$0 - $30]hub2[$60 - $0]Uto
you[$0 - $60]hub[$0 - $30]FK[$0 - $30]hub2[$30 - $30]Uto

now you have your funds in a new channel and dont care about the old channel bcause your mainnet UTXO is not lockd to that initial hub channel. so  you can forget about it and leave the hub with the problem of settling out their balance

but.. heres the rub, although you think you have less worry about closing a channel becaus your iinitial UTXO is not locke to that hub...you still have to get the hub to agree to pass the $30 out. meaning
at the state
you[$30 - $30]hub[$30 - $0]FK[$30 - $0]hub2[$60 - $0]Uto

if they are playing hijinks they can still hold funds to ransom. by refusing to sign your $30 back out of channel
also.. hub can spend the $30 the hub has with fortknox.. meaning the hub then has no value left in hub-fk to then pay to fortknox to then allow you get fortknox to rout your $30 to a new channel all offchain EG
you[$30 - $30]hub[$0 - $30]FK[$30 - $0]hub2[$60 - $0]Uto
as you can see hub spend it for hubs coffee. but now even if you give hub the $30 in you-hub..  hub cant then give another $30 to FK because hub-FK has $0 hub balance to do so

meeaning your again stuck with having to broadcast out the you-hub tx to mainnet. which hub could treat as an unsanctioned event and invoke a punishment

in short. if hijinks is occuring and even if you think using a factory will help reduce the amount of times you need to close a channel via mainnet settlemnt.. the end result is your still at the same risk of needing to settle to mainnet to get your $30 out of a hub is upto hijinks.

P.S there are far more vulnerabilities/ransoms/blackmail/hijinks risks that i can describe. but yea tryin to close a channel is not just a easy ok, done in 0.002 seconds no issues. the reason, even with factories.. well thats simple. DUAL AUTHORISATION RQUIRED every time. LN is not a simple single party push payment system so if the other party messes around. your stuck and may end up paying the cost of their hijinks

If a hub in the central network and talk of LN channels is known as a problem then people can start routing around it. And a bad actor performing a center is very limited in what kind of hijinks they can perpetrate anyway. Network deployment is really a good idea for everyone because it can save on high transaction costs. There are still questions that arise in my mind as there are still shortcomings expected to be encountered, So how can we solve that problem?

I want to get back to this, and I am embrassed to say that I am not sure how that works. Who decides when to increase the "flex cap" limit? Is it the miners only, or does it have to be in consensus with the non-mining full nodes?

 It isn't centralized in a significant feeling. If your center within the hub-and-spoke system associated with LN stations actually gets referred to as an issue after that everybody can begin redirecting close to this. As long as blockchain costs for any solitary TX aren't excessive there is very little "locking" anybody into utilizing an issue center. Along with a poor acting professional working, the center is extremely restricted within what forms of hi jinks they are able to perpetrate anyhow.

So your arguments getting weaker... or malleability ? ETH (apples - oranges) ?  

I leave it up to you to draw the final picture of BTC future, where you surely hope many small ppl are STILL happily running cheap relay nodes - connected to a few monster nodes from mining pools etc ,  never ever will be able to pay for a safe on-chain settlement for all their fancy un-secure TXs (any interface and off-chain tx / storage / ...  IS by orders of magnitude more un-secure than on-chain)  - because that secure on-chain settlement will exceed the cost of running their cheap on-chain settlement nodes by orders of magnitude....  so why running them ?
 Only for 'decentralization'?  How much is needed really ?

I rather will go with that picture Joannes Vermorel was drawing, where manny of the solvent corps with proper business cases and risk managements behind will run the expensive shit for all the other ppl in the world for good. Still that many, that we have enough decentralization at work, because we all (should) know that Bitcoin has good game theoretical / economical alignments at work from the very beginning (a variant  of the Nash Equilibrium)!  So I m really not concerned about any 'too high un-decentralization' - you can have 'decentralization' at any scale -> what makes Bitcoin a fractal like structure.


 

In my opinion, it is more decentralized. Because if the centralization system is not clear who is the official party. Indeed if Lightning Network run then will only be played by people who have large capital and rich. A mediocre person like me can not follow this ecosystem because honestly I am a person who barely has the capital to join the circle. Only people who have the wealth and strength that can survive and play in this ecosystem. It may be my little view of Lightning Network.