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

So, no Moore Bound problem, ok?

Bitcoin relay network is consisted of two different class of full nodes: non mining nodes (wallets, browsers, etc.) and mining related nodes.

By mining related I mean full nodes that are directly connected to a mining facility(pools, farms, etc.). Currently with pools dominating the mining scene I believe the number of mining nodes is extremely low (below 2k probably). Most of this nodes belong to farms/pools, centers with hundreds of thousands up to millions of dollars investment which have incentives and strengths to do anything they found necessary for optimizing their presence on the network.

IOW, having a very compact graph of mining full nodes with a 4 hopes diameter in the current bitcoin situation with pools, seems to be a trivial job. Actually it is already done by miners using simple strategies like deliberately choosing each other as peers or more effectively by joining FIBRE and alike.

But my target is more ambitious: I wanna set free miners from pool slavery by neutralizing pooling pressure. So I have to solve a much more difficult problem for a network with a minimum of like 100,000 mining nodes constrained by the same 4 hopes diameter condition.

For this, we would need some minor improvements in the networking module of bitcoin on one hand and promoting independent relay networks like FIBRE that provide a backbone service for instantaneous message relay, on the other hand. I think we don't have to be worried about centralization or trust problems with such networks because nodes always have legacy bitcoin relay network as backup and as a reference witness to evaluate the service both in terms of validity and speed and can easily abandon unfaithful services.

I don't think Chord protocol is necessary here just imagine we have a handful of commercial services each consisted of complete graphs of 20-50 non-mining full nodes trusting each other and optimized to handle hundreds of connected full nodes. Miners would pay for the service and besides bitcoin legacy p2p network, they join to such services probably through a load balancing mechanism ...

Apart from block-size and block-time changes, your other proposition (from another thread) is a radical change to PoW algorithm. I am not someone who understands the game-theory, the graph theory and associated higher mathematics to judge on decentralization aspects of a mining algorithm. After much reading and thought, I came to an understanding that PoW works. The history of its development shows that various such ideas of "Proof-of-X" were tried but failed to pass the trustlessness criterion. This made me decide that bitcoin is my best bet. I am sure that the whales invested in this are also aiming for stability and not radical experimentation.

If the obstacle is not technical but political then you need to generate enough information to help people make a decision as to why a change in algorithm or block times can be feasible. This needs code, testing and evidence. Hence, a testnet. It will be far more easier to convince people that way. Or maybe if you could point us to a peer-reviewed discussion on these topics.

As i admitted above, there are technical aspects I don't understand yet. What I do understand is that Bitcoin's PoW works and has been working through the past decade. What i know is that a whole hardware manufacturing industry supports it with increasing hashpower and that hashpower is what keeps it valuable. I understand that mining has a centralization aspect but I also know that the entities involved will be wary of risking a self-goal by targeting the very thing that keeps them rich. As a believer in bitcoin's ideals, I hope and cheer for news that mining hardware may soon see entry of other major players leading to some resolution of the issue that you wish to address.

Changing the mining algorithm so as to wreck uncertainty on the miners worldwide would be a bad-disruptive thing to do, not the good-disruptive. How disruptive changing network specifications would be, like you propose here, should be demonstrable on a test net..

A lot of people including Greg Maxwell have pointed out that any technical discussion here at BCT has lost significance because of the way it quickly gets personal/ political. Here's what you said in your post:
In my opinion, accusing someone of spreading FUD as part of their 'strategy' is not technical criticism. (which you should focus on and which no doubt will be welcomed). You cannot hope to call them FUDDers, Dogma-ridden and expect them not to think that you have an ulterior agenda..There have been too many of those out here..¯\_(ツ)_/¯

Many people don't view it as extreme conservatism. Its accepting that you don't know what you don't know. There are enough examples of lower blocktimes, bigger block-sizes and there is nothing to suggest that they won't ever face bottlenecks. There is the Github way to do it and it says it well.
With that, I'll bow out of this discussion and leave you to point us to information on why what you say should work. Maybe some of that material you have been promising for a while. It will be good learning for us.

You must first prove empirically that your ideas will not result in a clusterfuck when put in practice. You need somehow a test model to try how it would work and get the data. At least in BCash, Craig Wright, Rizun and co seems to be spending resources trying to run models in which they can gather data to see how massive blocksizes would look like.

"t0 2.5 min then at t1 90s" sounds a bit reckless.

Richard Heart explains here why touching blocktime may not be a good idea:

https://www.youtube.com/watch?time_continue=2940&v=iFJ2MZ3KciQ

Again, you will need a lot more to convince people to hardfork.

Sure, when you scale up the number of connections each node has to have, you can always ensure very low hop counts.
Clearly, this doesn't apply for random graphs (as we have in Bitcoin) so you would need some kind of fancy management overhead that constructs those special graphs in some decentralized way. Also, you would have to check what effects those 100+ node connections actually have: are there any new attack surfaces regarding DOS, net split? Are slow nodes doomed to fail because they suddenly have to process and rebroadcast all that crap from the other 100 nodes.

I am sure it is doable somehow, but whoever tried to implement a proper, resilient Chord P2P network probably figured out quickly that it's virtually impossible to properly handle all the different side cases. For this type of graph, I bet it the task would be even harder. Probably, the graph structure maintaining overhead would become the limiting factor at some point.

But I am very interested in hearing your ideas, if you have some cool solution to such issues. I could never figure it out.

Actually, Moore Bound is the maximum number of vertices for a given diameter (maximum distance) and degree which is proved to be:

For a degree (d) of 100 (100 peers) to have a 4 hops diameter (k), the upper bound is 100,000,000 vertices!

Of course to fit so many nodes in such a network we would  need very restricted topology which is infeasible for a permissionless network. But the point is  possibilities are wide enough. For instance I could imagine high speed relay only loops of nodes with a cumulative number of tens of thousand peers that compensate for topological imperfectness.

That 4 hop idea won't work! Given a degree (maximum connections) d, and a maximum diameter (hop count) k, the construction of a graph (of maximum size) that matches these properties is called the "degree diameter problem" and has been around for ages. Funnily enough, research has shown that such graphs have an upper bound for the number of vertices (nodes) called the "Moore-Bound".

Either you restrict the Bitcoin Network to a small number of participants (less than the Moore Bound) or you accept the fact, that the diameter in a scalable peer to peer network (that is, without infinitely long routing tables or connections) will always depend on the number of nodes itself - increasing as the network grows.

Then prove your theories by running a test net as said by amishmanish.

How many minutes between blocks does Dogecoin have? I believe it is close to your 2.5 minute target. Do you believe it solved Bitcoin's scaling problem?


Ok. I cannot comment, but I hope someone will in connection to "Step 3".


You "think" it will happen that way in theory, but everyone does not have access to the same speed of bandwidth.


Have you made a proposal or is it possible for you to tell everyone in the Bitcoin mailing list?

@cellard

No block size increase is required or recommended for 100 tps:

Step 1: Decrease block time immediately to 2.5 minutes.  
It gives us a rough 60 tps throughput with considerable positive decentralization consequences without any security draw backs (unlike what Buterin claims with his stupid trilemma).

Step 2: Improve relay network.  A greater support should be available for advanced communication features like unsolicited push messages. Full nodes connected to mining facilities should have access to parallel dedicated channels to push/pull critical messages with fewest hops. The possibility of merging protocols like FIBRE should be studied.

Step 3: Decrease block time even more, down to 90 seconds and touch 100 tps record.
The main challenge would be centralized situation with pools that potentially lets them to commit selfish-mining-like misbehaviors. To mitigate this, non-mining honest full nodes should participate in maintaining a back-up channel on which they push critical unsolicited new_block_found messages as soon as they found the block header valid.
I think a clean implementation can keep propagation delay below 2 seconds and the longest distance below 4 hops. It yields a worst case progress around 6 seconds.



As of your eternal concerns about community consensu about change:

This discussion is about how feasible is improving bitcoin throughput without putting the network in danger of centralization or security risks, unlike what PoW/cryptocurrency opponents along with off-chain/second layer proponents claim.

For a real practical plan, I'd start with PoCW and eliminating pools in the first place.
I'm not personally recommending any such optimizations in the current framework of bitcoin PoW that is based on winner-takes-all approach. So, my plan includes eliminating pools from the ecosystem as well as optimizing performance.

So, my agenda is more sophisticated than just a few performance optimizations and harder to accomplish, a completely off-topic subject.