Quote from: smooth on September 09, 2015, 10:46:08 PM

My suggestion is to lock the thread and bump it when you have substantive updates.

I thought I didn't have the lock topic button, as I tried to find it earlier and didn't see it. Now I see it very small at the very bottommost left of the thread. I will lock if there is another raging (unintentional) thread jack spawning.

Again I did write in the opening post that I might eventually delete posts and resummarize them into the one condensed post or into the opening post, if I have time to do so.

I do understand the extreme curiosity and interest in discussing such an important topic about how to improve upon consensus attributes such as scalability. I tried to entertain that curiosity by revealing some of the basic principles I've used to solve that design issue without revealing the specific inventions that make such a holistic design conform to those principles. So I did provide some substantive response to FUD and myopia, but it is also true that it will just cause more confusion because obviously if they can't see the entire solution in detail, their misconceptions of issues are what are preventing them from inventing the solution in the first place. So it is best to just not discuss it at all, if we are not going to reveal all the details. This was my intent from the opening post, but I again I tried to appease the curiosity somewhat, but it is just not going to work. We have to shutdown the discussion on the consensus design until our implementation is near finished and we are ready to publish the white paper.

Interestingly bytemaster (Bitshare's Daniel Larimer) discusses the Vitalik white paper I mentioned upthread pertaining to scalability of the transaction rate at the 33 min point of this audio interview:

https://beyondbitcoin.org/bitshares-dev-hangout-bytemaster-stealth-confidential-transactions/

Notice how at the 35:25 min point, Daniel quickly glosses over the issue that the network bandwidth and latency are the actual limiting factor because if you want decentralization then you have to allow for great disparity in ISP connections around the world and also be tolerant to network fragmentation and degradation scenarios. Then he admits at 36:45 min that actual measured maximums are in the 40 - 500 transactions per second range and the latter figure is only on a idealized testnet so I take that as not representative of the real world networks in harsh environments such as my fabulous 1 Mbps connection here in the Philippines. Another thing he is glossing over is the issue of who is mining and are they full nodes and if not are the relying on pools and what does this do to centralization, hence censorship resistance, etc, etc, etc. Daniel doesn't seem to appreciate that Vitalik's point may be that in order to scale within the context of real world networks, there needs to be a fundamentally different network design. Daniel seems to think the partitioning is only to divide the CPU load up, but that isn't the real bottleneck (as he admitted for 5 seconds and didn't mention again).

This consensus network stuff is very holistically detailed and it can't be well discussed in this format. The white paper is very long for a reason. There are a lot of details that have to be covered. And it needs to be precise.

P.S. Daniel makes a great implied point at the 41:45 min point that decentralized exchanges will require much higher transactions per second throughput (certainly higher than Bitcoin can handle at this time and remain widely decentralized). Daniel claims Bitshares can do it, and I think to the extent this is a true claim and not just a testnet idealization, this might be true only because DPoS (Delegated Proof-of-Stake) isn't really well decentralized, but I need to go study it in more detail before I can make a detailed comparison.