Topic: Why can Core not Scale at a 0.X% for blocksize in the S-Curve f(X) - page 2. (Read 1126 times)

You have talked about how we need 100 tps right now or in the near future, which would require a blocksize increase, even mentioned blocktime modifications and other things which require a hard fork.

You still have not explained how the hard fork is done without causing a big mess with different factions dumping tons of coins into each other after the split.

And you are assuming that if Core (by Core, I guess we understand the most known developers?) agreed with a blocksize increase then we would have a smooth sailing to a 2MB hard fork or something which seems delusional to me.

@amishmanish

More people have correctly reminded me of political obstacles rather than technical ones unlike what you suggest. I've been around for a while. I understand who is who in bitcoin and which frontiers worth fighting.

Buterin's trilemma is one example and Core exaggerations about the fragility and sensitivity of bitcoin protocol/software that prohibits any "reckless' manipulation is another example. We should get rid of such superstitious pretexts to have a fresh and dynamic development environment because we need contribution.

I'm not slandering anybody. It would be a sign of arrogance for these guys if they take my criticism as an offense.

They are great developers, I admit. I find @gmaxwell's technical assessments always very useful and inspiring but to have this guy focused on the technical problem under consideration, you have to convince him to put his pretexts and prejudgments away, at least for a moment and remain open to new ideas and proposals.

Protesting against extreme conservatism and asking for a more open minded team in charge of bitcoin development is not a crime. Nor being against the idea of leaving bitcoin unchanged and sticking with 2nd layer projects should be considered an act of slandering.

You don't have to fall to the levels of slandering to make your point.

On one hand, your ideas on "winner takes all" vs "shared effort" sound reasonable while on the other hand, you seem to be a big fan of the conspiracy theories. Why can't you understand that this is basically a difference of ideology-driven vs business-driven thinking??
More than enough people have suggested you above to focus on the merits of your argument rather than trying to make unnecessary accusations on core devs. There have been enough people and their alts doing that on the forum. Why'd you want the system to be a running experiment for your ideas? You should probably see that this can be done a lot less belligerently and a lot more collaboratively.

Why don't you implement a testnet for your ideas. People will notice. If you have put up code results at IRC or some other place with suitable peers, a link would be welcome.

Easy ... heh?
Don't touch 'the base' just build services on top of it!

Everybody would be happy, bitcoin remains solid and people have their services.
Sounds familiar ...

Spreading FUD about  mysterious huge risks of 'breaking' the network because of improvement and evolution is an important part of the Core's strategy. In block-size debate they played this card extensively and unjustifiably and they keep using it ever and ever.

According to you and Core (and Vitalik Buterin) bitcoin has reached its limits so any attempt to make it better specially in terms of performance, will put it in danger. Proposals regarding such improvements face a dozen of accusations of being reckless, insecure, ... and weakening decentralization, of course.

This situation is unacceptable.
An idea in its first stages needs support and help to become more stronger and sophisticated, to mature. Instead what we have is an anti-evolutionary atmosphere with harsh and aggressive attitude biased against any form of change in the name of conservatism.

It is what I've labeled as bitcoin ice age and we are in its midst.

I agree with you, and I believe the Core developers also agree. There is no hurry. Why pressure the developers to make a dangerous hard fork to bigger blocks, or your proposal of reducing block times?


Apples and oranges if used an example for Bitcoin.


Yes, who's in a hurry? The Core developers are very conservative and they are also taking their time to not break anything.


Yes, why are we arguing? Hahaha.


Or a reliable layered protocol capable of off-chain transactions. Why not? It maintains security and decentralization at the base.


What are they? Can your crystal ball see 20 years into the future?


But meanwhile the developers should be very careful not to break the network.

One can always suggest that performance of a consensus based decentralized system is limited compared to a foolish centralized TP. Not a big discovery. Decentralization makes it a bottleneck to synchronize the ledger.

Satoshi Nakamoto by inventing and introducing bitcoin implicitly claimed the feasibility of a system acceptable in both decentralization and performance measures and it had proven to be right until congestions and transaction backlog in late 2017, what is presumed imprecisely as a scaling crisis.

The main factor behind that crisis was the pointless block size debate that in spite of obvious growth in market demand delayed activation of SegWit which was efficiently capable of improving the performance up to 2.5 times without putting any thing in danger.

A moderate increase in block size or decrease in block-time was capable of improving the performance as well, again, without any bad side effects on decentralization or security, unlike what Core guys insist to maintain.

After BIP 152 and recently FIBRE and other dedicated network relay protocols and services, a very wide range of opportunities for both fine tuning operational parameters and the protocol itself are in the horizon.

Combined with communication and processing technologies the above opportunities would help improving to like 10 times better in terms of performance, again without any bad side effect on decentralization or security of the network, if the governance problems do not lead us to the same misery as the infamous block size debate.

Up to here, performance is guaranteed for like 50 tps and suffices for us to relax and decently investigate even more radical approaches like sharding proposals and define another 2-4 times improvement in next couple of years, passing 100 tps which I believe is enough for the current state of the market demand and technology development, both.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


I admit that my personal judgment regarding block size debate is somehow biased in favor of big blockers rather than Core but not truly a big blocker  

First of all I recommend block time decrease instead of block size increase and secondly I don't believe either approaches may be considered a scaling solution. just a moderate temporary improvement which is infeasible to be repeated recklessly because of centralization and security consequences (Vitalik made his trilemma joke about such naive proposals for scaling, I suppose).

Specially, Core agenda, projecting performance problem to off-chain and 2nd layer services like LN is what I'm strongly against. It is the most dangerous threat for bitcoin imo, because a team in charge of maintaining the network is giving up with improving the protocol and focused on semi-centralized 2nd layer solutions.


As of centralization of mining, I have recently published a complete proposal and an independent analysis of pooling pressure in bitcoin. You are welcome to check both:

An analysis of Mining Variance and Proximity Premium flaws in Bitcoin

Getting rid of pools: Proof of Collaborative Work

The above argument for scaling illustrates the basic difference in the approach for Big blocks vs Small Blocks. Big blockers seem to view bitcoin's demand growth as the basic motive. They want to ensure that any foreseeable demand is immediately filled by a step -wise increase of blocksize, even though it'd need a hardfork and even though there'll be a lot of unknowns.

This seems to ignore the basic ideal of keeping bitcoin within reach. Nobody should be able to takeover bitcoin sheerly by the amount of resources they can put into it. @ali mentioned in one of his opening argument about the small miner with a 200K investment versus the big data center with upwards of a million dollars in investment.

There is surely a point of exit for the enthusiast between this 200K and 1 Million, where he'll no longer be able to afford running a mining node. Apart from the hardware cost, access to crazy fast internet that will be needed for, say, a 32 MB blocksize syncing, further shrinks the set of people who can contribute meaningful hashing power.  For bitcoin to remain in the domain of the enthusiast and to remain usable for everyone, block size is probably the only thing that is under this community's control. Once that increases without an upper bound, it'd still function but the number of people who can still afford it will drastically reduce.

Maybe it is time we had a proper study on this. Is it possible to check the details of who is connected to a pool and respective hashpowers of such connections? We have some 9500 nodes live as of now. How many of them are mining nodes and what percentage of them are at the enthusiast level?

Then why is it hard for Bitcoin to scale while trying to maintain security and decentralization at the same time as the means for censorship resistance?

Did Dogecoin already solve the scaling problem? Did Litecoin?

I see both you and @Doomad are very interested in refuting Buterin's claim. I understand, I feel offended too  

First of all I have to maintain that it is on him to prove such a hypothetical trilemma exists either mathematically or experimentally.

Obviously, Buterin is not much of a proof boy and we are dealing with an intuitive argument inspired by:
-a Japanese maxim which states: everything comes with a price!
- the famous ideal gas rule in thermodynamics PV/T = constant
- recent congestion and performance problems in bitcoin and ethereum networks.

Yet and in spite of its  journalistic nature, this garbage and the magical key word, trilemma, is occasionally used to get rid of any serious discussion about improving cryptocurrencies or to make weird claims about impossibility of such improvements.

Some people go that far to use this fallacy (we will prove it being a fallacy) as a supporting assertion for their strategic interpretation of what bitcoin is or is not.

So, let's do it ... proving wrong an unproven, journalistic, ridiculous claim about block chain design being an engineering trade-off between security, decentralization and performance, made by Ethereum idol, Vitalik Buterin  

What is this trilemma of Buterin?
It is how Buterin and his proponents in Ethereum community present the trilemma: re-defining decentralization, scalability and security such that one might be convinced they are mutually incompatible or something!

What does decentralization mean in cryptocurrency?
Buterin suggests it is totally impractical to have a decentralized p2p network and we have always a degree of centralization. It is essential for his ridiculous trilemma: You got a distribution of votes not being homogenous? You are somewhat centralized!

Decentralization, the way bitcoin has established it is not such a naive concept. It is about Byzantine Fault Tolerance:
A cryptocurrency p2p network is supposed to be decentralized to resist against collusion between a majority of participants weighed by their power, for this to be achieved a network should be capable of maintaining a distribution of participants/voters being both divergent and granular enough.  

Although enough sounds to be relativistic, it is not. An adversary has always the option to consume enough resources to compromise the security of a network (Note for Buterin: regardless of how scalable it is ). He just doesn't commit such an attack because of the game theory analysis that shows him how irrational would be such an option.

No matter how granular or distributed are the participants, there is always a choice to locate them, bribe them and commit such a conspiracy against the network, it is just about the costs and the incentives involved.

So, a network is safe in terms of decentralization as long as collusion is much more costly to achieve than the rewards.

Although it is possible to imagine a hypothetical function taking a range of parameters and giving us some quantitative index for decentralization, that function by no means would be such a stupid linear relation with the total network resources: O(c). This kid is obsessed with computational theory's O function. He thinks it is very prestigious to use O(something) whenever you have no clue of the actual behavior of a variable.

Decentralization is a sophisticated property for a p2p network and the only legitimate framework to make an assessment regarding it, is game theory. There exists no linear, simple function that can be used to give a practical index of how decentralized a given distribution of resources and votes in a network is.

Plus and more importantly, there is a gap between a protocol (or an improvement  proposal for a protocol) and the way the resources are distributed in the real network. A protocol can encourage/discourage a distribution pattern but is not able to actually impose it!

Suppose we have this protocol freshly started with a very limited hashpower, if for some reason its coin gets unpredictably more attention from the market, no matter what the protocol is or how it encourages the distribution of resources, it will become radically centralized in few days and there is nothing the protocol can do about it as long as it is supposed to be public and permissionless.

What does scalability mean in cryptocurrency?

The way Buterin puts it, scalability is another impractical agenda for cryptocurrency. Actually it is impractical for any computing system.

Any educated, experienced software engineer is aware of the limitations in how scalable would be his design. Simply asking for O(N) > O(c) as a measure of scalability is nothing more than a joke (again using the infamous O function ). In software engineering we always need a criteria for designing a system to be scalable within. Once the requirements grow higher than the boundaries, you have to reconsider the design properly and you may have to do it from scratch.

When in crypto ecosystem we talk about scalability we are not looking for a solution to compete with a stupid centralized data center like what Visa runs. Who put this in front of us as a challenge and why?

we don't need tens of thousands tps now and in near future. We are speaking of tens up to few hundreds tps for now and next few years. Neither bitcoin nor any other crypto coin is supposed to replace fiat currencies in like 5 years. Neither fucking Ethereum universal machine is going to be used as an alternative legal system for resolving day-to-day contracts between people.

Why people are screaming scalability or making fantasies about it? what's the catch? Making an embarrassment out of it for the community? For what? Selling their own shitcoin?

Although we are always dreaming of such days, they are not gonna happen right now and we have to worry about real problems with real performance bottlenecks at this very moment.

Scalability for crypto currencies should be considered as:
The capability of a network to  process transactions without unexpected delay or costs if the projected numbers and indexes of popularity and usage growth happened to become real or exceeded their initial values moderately.

For bitcoin, I suggest 100 tps is more than enough for next 4 years. So, we just need like 10-15 times better utilization of resources and technologies available nowadays.

What happens next, when network grows even larger and demand gets meaningfully higher?
Nothing! We make more assessments based on more data we would already have, and try to utilize more advanced technologies and sophisticated protocol enhancements to make the network even more efficient.

Next?
We don't know! We should wait for more improvements and more technological opportunities, may be?

Simply, we should improve and evolve gradually to keep the network efficient in the criteria that is dictated by the market.

What does security mean in cryptocurrency?

I don't understand WTF Viralik means by 'attacker with O(n) resources' but in crypto we have two important security measures:

1- Being resilient against double spend attack by 50%-1 resources.
2- Utilizing network resources fair enough to keep the above index in the same level by avoiding orphan blocks.
With orphan blocks and unintentional forks, we will have parts of the resources wasted making it possible for the adversary with less resources to commit double spend attack.

A protocol is considered to be safe if its consensus mechanism is solidly supporting the first property and other implementation and operation parameters
do not put the network in the second danger.

Now, suppose we have our coin designed (for some reason) in a way that a relative number of stall blocks or unintentional forks happen more often than a coin like bitcoin. What happens?

Firstly the adversary may find it practical to fork intentionally for a double spend attack using his hashpower which is  considerably less than 50% with a good chance of winning the competition because the network's honest majority of hashpower is already splitted between other competing, unintentional forks.  

Then what? a double spend has been made and somebody has lost his funds/assets.
But wait ... The loss should be considerably high like a very large transaction of coins? Shouldn't it? And why a user dealing with our coin shouldn't wait for more confirmations before releasing his $$ assets? Of course he should and he would wait for that.

The point is, even with not being fully obsessed with preventing unintentional forks, this network should be considered safe as long as it supports the more crucial 50%-1 attack resistance, deep in its protocol and thus resists long range attacks properly.


Conclusive remarks:
This is why I call this hypothetical trilemma, pure garbage. It is nothing more than a naive fallacy, a strawman flavor of fallacy to be exact:
The kid is trying to convince us we are not capable of keeping our promise for a p2p, decentralized, secure and adoptable electronic cash system because of some magical contradictions between features nobody have promised.


Vitalik Buterin is now an adult and has rights to attack our axioms but it should be clearly understood as an attack from outside of the cryptocurrency discourse .
All this thing is about weakening bitcoin/cryptocurrency agenda: building a better world by inventing a better monetary system.
He deliberately suggests/forges impractical and void definitions of basic features and says it is impossible to achieve the design goals of interest.

Why? Because he is a trojan horse. He says:

And I'm like

You are sidestepping the debate. I want to hear from you why you believe that increasing scalability will not affect security and decentralization if applied on the blockchain by increasing the blocks, or by your idea of decreasing the time between blocks. I want to know why you believe saying that there will be tradeoffs is "garbage".

Bitcoin is not a democracy where 1 person = 1 vote... as far as im concerned, in Bitcoin you matter depending on the amount of Bitcoin you hold basically. So when there is a fork, you "vote with your coins", as you receive coins in both chains. If I support the original Bitcoin, I will dump on the other chain. If I don't, I will dump on the legacy chain. The conclusion as far as I can tell, is that whales sit at the top of the hierarchy since depending on what they do on this situation they will incentive miners to mine whatever chain whales are supporting. Of course whales aren't %100 controlling Bitcoin, but the point is, you better have as many whales on your side when attempting a hardfork.

If a whale has 100000 BTC, then that's 100000 votes so to speak.

So aliashraf, if you want your hard fork improvement proposals to be considered, you must go convince as many whales as possible, and other people that have a big stake in Bitcoin (miners etc).

Of course, the more peer reviewed your code gets between different experts on the field the better, so you must discuss with coders too.

@Doomad, @cellard

Understanding Bitcoin as an electronic, p2p cash system (sounds familiar?) is constitutional and axiomatic. It is not up to anybody to vote for crypto geeks whether they have right or not to establish, maintain or improve such a system to fulfil its constitutional design targets.

Vitalik, the trojan horse, suggests our axioms are not consistent and there will be no p2p decentralized, secure cash system ever because of a ridiculous hypothesis he has forged by copycatting from preliminary thermodynamics.

If he is right then people like me and Satoshi Nakamoto and many other crypto enthusiasts are idiots, otherwise he and people who think he is really a genius are fools. No negotiations, no voting, no consensus ever.

A system, computerized or not, is not complete from the first day, bitcoin not an  exception.

Decentralization+Scalability+Security  is vital to bitcoin because they are constitutional. Both three features have to be implemented and maintained simultaneously and to the maximum extent. Idiots think it is impossible? Let them ruin their ecosystem with Proof of Sh*t. Cowards think it is hard to achieve? They better retire and watch the show. Whales are worried about their $$ deposits being at price fluctuation risk? They better cash out.

There is no option other than reviewing and summarizing the past decade of experiment with (beta version of) bitcoin we have, fixing centralization and scalability and security shortcomings and starting a refined more finalized bitcoin perhaps for next decade.

I'm committed to such an evolutionary vision with our without any support. Axioms are not decidable

In your opinion, perhaps.  But for most people, they simply aren't voicing those concerns.  If the majority want change, change will happen.  What's proven on each and every day that no change occurs, is that the majority want it to remain exactly as it is.



It's on you to justify why you think change is needed.  No one seems conviced thus far.  Avoiding Wind_FURY's question probably isn't helping with that.  It's clear to me why they're asking you to provide an answer to that question.  If it isn't clear to you, maybe you need to come back once you've figured it out.

But the problem is once again, doing the actual hardfork in a clean way. You need to convince many people, some will oppose. What are you going to do about it?

Im always up for debating these things, but actually making it happen is different story. Satoshi knew super majority in Bitcoin was insanely difficult to reach. He may also have considered an scenario where when Bitcoin gets past a small project, it would basically be increasingly difficult to hardfork up to a point where it becomes practically impossible.

SegWit was added because it was a soft fork, otherwise it would have never happened. And it didn't came without massive controversy and struggle. Up to this day some say eventually miners will cartel against SegWit to steal funds.

It is not on me to reject every single ridiculous  claim Vitalik Buterin makes (believe me there is a lot), you better ask him to prove it. I mean a mathematical proof.

Actually the whole cryptocurrency movement (for which Buterin is just like a trojan) is based on axioms that guarantee  the feasibility of a secure, decentralized and fast p2p electronic cash system, check with Satoshi Nakamoto.

SegWit is not enough and took too long.

Satoshi lacked the statistics and data for proper tuning of parameters so he rationally chose the most conservative ones, after 10 years with Moor's law in action and the huge amount of data available, it is time to have block time and block size proposals being discussed and evaluated both with more courage and less skepticism, imo.

You know that your proposal will never be accepted in Bitcoin. I suggest you should do the next best option, fork Bitcoin and put every rule you want in there.


The Bitcoin Core developers are among the smartest people in the cryptocurrency world. If they made you look stupid, do not take it personally and move on.


But for Bitcoin, I believe the technically safer way forward is better. Let others dominate in market cap. Bitcoin will outlive them all.


Please explain how decreasing or increasing one trait will not affect the traits of one of the other two. Security, decentralization, and scalability.

You state this as if the capacity wasn't recently roughly _doubled_, overshooting demand and knocking fees down to low levels...

Although @gmaxwell in the above post is basically correct and there are always non-linearities  involved, we should take care not to have bitcoin frozen like in its ice age,  in the name of conservatism or decentralization.

Extremism doesn't help either way. I do agree blindly and radically playing with critical parameters like block size or block time is not rational and puts network in danger. But by no means it is acceptable to condemn any re-adjustment proposal. It is 10 years and we can
have some adjustments due to technology developments.

Vitalik Buterin trilemma is pure garbage. I think the kid has recently read something about  ideal gas law (PV/T= C) and is childishly making an analogy.

I totally agree, but i've mentioned about research/test about block size/weight limit increase on testnet/segnet in past. Unfortunately, majority on this forum (https://bitcointalksearch.org/topic/dont-we-need-to-increase-block-weightsize-2753289) disagree with my idea.


True, but besides Schnorr Signature/Signature aggregation. There are few technology such as MAST and BLS and Bulletproof. However BLS most likely won't be used.
I just know about Channel factories though.


Actually no, since that depends what kind of transaction/script in a block. We'd see 4MB block size on very specific cases and usually we'd see about 2.3 on normal cases.
Besides, block weight limit uses weight as it's limit, not byte, and it's limited to 4 kWu.

More info : https://en.bitcoin.it/wiki/Weight_units


Actually he's not wrong. Hardware such as HDD & RAM (with low capacity) can't keep up when the TPS is very high, Ethereum is the prime example.