Is the Lightning Network centralized?

[iotarocket]

I think in these debates there will always be disagreement on terms such as centralized and decentralized, because they may be defined differently and some may view certain types of centralization more dangerous than others. I think there will be some centralization as the LN gets developed, but the blockchain itself will remain decentralized.

[1714137621]

1714137621

[1714137621]

1714137621

[1714137621]

1714137621

[d5000]

And take into account the fees credit card companies charge ... they're often higher than Bitcoin transaction fees (and LN fees).

maybe in usd or euro but for other currencies visa is cheaper.

Well, at least where I know about, Visa charges 1,5 to 4% of the payment depending on the merchant service provider. This may be cheaper than Bitcoin in the case of micropayments, but currently already a $10 purchase is more expensive with Visa. I know that wasn't always so - we had minimum fees of ~$3 (on weekends) or so in January, but this was because nobody was using Segwit then, so a giant backlog formed. And the likely spam attacks ...

The difference may be that Visa charges the fee to the merchant and not to the customer, while with Bitcoin, the buyer has to decide the transaction fee - but merchants (if there are no legal restrictions) can give discounts to Bitcoin payers (as some give discounts when using cash).

[Wind_FURY]

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.

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?

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

[Zaibraid]

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.

[hv_]

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.

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?

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


 

[vual]

 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.

[Wind_FURY]

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?

[necessary]

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?

[franky1]

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

[franky1]

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)

[hv_]

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

Yes, thx good summary.

The peer to peer trustless Bitcoin character is removed. Congrats


You could only do peer to peer with your existing, frequently used peers, simple netting application. But actually, no such complex LN needed for that.

[CCF_news]

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

[Wind_FURY]

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?

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.

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?

[hv_]

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

[Tronx]

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?

I think Lightning network is decentralized. 

[spadaccino]

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 ?

[Wind_FURY]

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?

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?

[hv_]

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.

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

[hv_]

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.


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.