Pages:
Author

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

hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 17, 2018, 08:13:44 AM


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.
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
July 17, 2018, 06:44:44 AM
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.
member
Activity: 231
Merit: 16
July 17, 2018, 03:37:15 AM
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.
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 17, 2018, 03:27:12 AM

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?

Quote
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.

Quote
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.


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.

 

legendary
Activity: 2898
Merit: 1823
July 17, 2018, 03:00:31 AM

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?

Quote
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.

Quote
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.
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 16, 2018, 06:37:33 AM

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
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.

legendary
Activity: 2898
Merit: 1823
July 16, 2018, 04:57:14 AM


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


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

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?

Quote
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 ).

That I will not deny, but tell me which other group of developers are as good as Core?
jr. member
Activity: 183
Merit: 2
July 16, 2018, 03:05:55 AM
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 ?
member
Activity: 61
Merit: 12
July 16, 2018, 02:52:38 AM
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? Huh

I think Lightning network is decentralized. 
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 16, 2018, 02:48:47 AM


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


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 ).
legendary
Activity: 2898
Merit: 1823
July 16, 2018, 01:29:18 AM

i actually bothered to read the bitcoin cash codebase.. and actually. if you read the code. the 32mb is known as a consensus limit.. but they also have a "regulated" limit of 2mb called the policy limit
https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/policy/policy.h#L19

this is the same as what bitcoin core had  before 2013.. 1mb consensus limit but 0.5mb "regulated limit" (in policy.h)which then went up to 0.75mb
and then in around 2015 went up to 1mb.. all without needing to fork or have big discussions because the policy was a flexcap limit

check it out consensus.h vs policy..h


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?

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?

Quote
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.

Quote
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?
newbie
Activity: 88
Merit: 0
July 15, 2018, 09:55:27 AM
After implementing the Lightning Network, the Ethereum network will remain decentralized. All the rumors about the centralization of this technology are a lie.
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 15, 2018, 09:37:59 AM
legendary
Activity: 4214
Merit: 4458
July 15, 2018, 06:40:45 AM

i actually bothered to read the bitcoin cash codebase.. and actually. if you read the code. the 32mb is known as a consensus limit.. but they also have a "regulated" limit of 2mb called the policy limit
https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/policy/policy.h#L19

this is the same as what bitcoin core had  before 2013.. 1mb consensus limit but 0.5mb "regulated limit" (in policy.h)which then went up to 0.75mb
and then in around 2015 went up to 1mb.. all without needing to fork or have big discussions because the policy was a flexcap limit

check it out consensus.h vs policy..h


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?

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)
legendary
Activity: 4214
Merit: 4458
July 15, 2018, 06:27:06 AM
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?

"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
newbie
Activity: 27
Merit: 0
July 15, 2018, 05:00:03 AM
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?
legendary
Activity: 2898
Merit: 1823
July 13, 2018, 02:36:45 AM

i actually bothered to read the bitcoin cash codebase.. and actually. if you read the code. the 32mb is known as a consensus limit.. but they also have a "regulated" limit of 2mb called the policy limit
https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/policy/policy.h#L19

this is the same as what bitcoin core had  before 2013.. 1mb consensus limit but 0.5mb "regulated limit" (in policy.h)which then went up to 0.75mb
and then in around 2015 went up to 1mb.. all without needing to fork or have big discussions because the policy was a flexcap limit

check it out consensus.h vs policy..h


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?
hero member
Activity: 714
Merit: 500
July 12, 2018, 12:31:37 PM
 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.
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
July 12, 2018, 04:06:39 AM
There is only one proper proposal for a working Bitcoin scaling concept, that also keeps the SEC out of it.

It is real industrial style on-chain scaling. Sorry to say that, but I fear this guy here, Joannes Vermorel is absolutely right.

There is no time any more left for romantic experimentation with Bitcoin and some fancy unsolved SEC layer stuff around.

Listen around 1:25

https://memo.cash/post/f3cba7ea021820b07435eba96c209609b643ca81cf4f9db60b87546f52a9ea19
But why do these millions transactions per second need to be validated and stored by every full node, forever?

Even if we discarded LN (for whatever reason), I think solutions like sidechains, pegged alt-chains of various types (e.g. the Basecoin style or the BitUSD/Dai style), child chains and sharding do make much more sense than massive, monolithic blocks. All of these solutions are based on the on-chain transaction paradigm and so are not in danger of being restricted by the SEC or other organisms.

(And no, a IoT nanopayment network based on the Bitcoin technology and on-chain transactions is totally crazy. I think 100K to 1 million transactions per second are totally OK for a global currency. 23K/sec already enable to make every household in the world to make 1 transaction per day, which in most cases is sufficient.)


I'm very convinced of that real open markets and open protocols will solve that by alligned incentives.
If you want Bitcoin to be big world wide, think big and do not try to dictate how ppl should use Bitcoin.

The reason why the blocks are regulated to 1mb is to make the network scale up. That means the network should keep growing in terms of number of nodes as the hardware becomes cheaper and the bandwidth becomes faster. What many people have failed to know is bandwidth grows slower and slower as the years pass by, and network latency slower still.

Quote
We might agree on a truth: If you try to scale up a system (like a internet protocol), the base parts of it must be as simple as possible, that attracts all sorts of builders. Side chains included, sure.

You talk like Segwit is very complicated. It is a simple malleability fix. The block size increase is a side effect. Plus you talk of side chains, then why not a 2nd offchain layer?

Quote
> keep the Bitcoin consensus protocol as clean and minimal as possible, so decentralization comes in with world wide use and growth.  

It is, and Bitcoin's regulated block size to 1mb will scale the network up. A good example of centralization and its network designed scaled down is Ethereum. Their blockchain is 1tb large and increasing, and an increasing number of nodes cannot keep up with the network.

Consider that their miners, who control the gas limit, which also control the block size are playing nice by regulating the blocks.

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.


 
member
Activity: 420
Merit: 10
July 12, 2018, 03:17:40 AM
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.
Pages:
Jump to: