Quote from: smooth on October 06, 2017, 08:08:55 PM

Quote from: Hyperme.sh on October 06, 2017, 07:57:22 PM

The users client should be free to select any of a plurality of nodes to grab data from. And the list of nodes should be permissionless.

They can. I'm pretty sure I've seen some of the UI that allowed the user to choose it or enter their own.

Obviously not from the standard JS served from Steemit.com and Busy.org as evident by what happened today.

Maybe other UI does, I dunno.

Quote from: smooth on October 06, 2017, 08:08:55 PM

Quote from: Hyperme.sh on October 06, 2017, 07:57:22 PM

Quote from: smooth on October 06, 2017, 07:46:38 PM

It is also possible to just run a client that doesn't rely on a remote web server for UI although unless you are also running a node you will be relying on a remote web server for the web socket and susceptible to DDoS. Some people have done the former and avoid all interruptions related to web servers and web services, although there isn't any user friendly way to do that (requires installing all of the front and back end software yourself).

Well if you make a popular client that does that, then the attackers will simply attack those full nodes as well. As I said, the only distinction between nodes which are webservers and those which are not, is a matter of choice of the designers of Steemit, busy.org, etc...

Those nodes don't have to be public at all. You can run your own, its just a p2p network like any other blockchain.

They have to be public for users to access them. I am not thinking about my own private network which would be pointless.

Were talking about scaling out to the masses, not how I can hide my own full nodes for my own private usage. You seem to be entirely missing the point.

Quote from: smooth on October 06, 2017, 08:08:55 PM

Quote from: Hyperme.sh on October 06, 2017, 07:57:22 PM

Quote from: smooth on October 06, 2017, 07:32:06 PM

The Steem DPoS blockchain has never been down since some software bugs crashed it once or twice in the first few months.

Because afaik (I think perhaps you told me) the IP addresses of the DPoS delegate witnesses (i.e. the consensus block generating nodes) are a very tightly held secret amongst the whales. Then there are lots of whale controlled nodes on the perimeter to absorb the DDoS attacks. And the perimeter is what I assume we are talking about right now?

You're confusing block producers and regular nodes.

No I am not. I clearly made the distinction between the block producing/generating nodes and the perimeter nodes around them.

Quote from: smooth on October 06, 2017, 08:08:55 PM

If the bulk of the block producers are taken down, the network will grind to a halt.

If more than 50% are taken down then the consensus is ambiguous. But the entire trust model of DPoS is non-objectively verifiable as Vitalik explained.

Byzantine agreement has a liveness threshold and if it is not met, then the result is indistinguishable from an attack.

The liveness threshold is normally 33%, and a 50% threshold reduces either the safety and/or the fault tolerance, or introduce centralization trust.

The only other way to avoid liveness thresholds is eventual, probabilistic consistency (e.g. proof-of-work and my upcoming design which is something new):

Quote from: https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf#page=9

Scalability:

Increasingly, we require that our systems be scalable, designed not just for todays customers but also for
growth tomorrow. Intuitively, we think of a system as
scalable
if it can grow efficiently, using new resources efficiently
to handle more load. There appear to be inherent trade-offs between scalability and consistency. For example, in order
to efficiently use new resources, there must be coordination among those resources; the consistency required for this
coordination appears subject to the CAP Theorem trade-offs. Studying this question may help to explain why even
within a data center, where there are rarely partitions, it seems difficult to efficiently scale strongly consistent protocols
(like Paxos [20]).

Tolerating attacks:

The CAP Theorem focuses on network partitions: sometimes, some servers cannot communi-
cate reliably. Increasingly, however, we are seeing more severe attacks on networks. For example, denial-of-service
attacks are becoming a near continuous threat to everyday network operations. A denial-of-service attack, however,
cannot simply be modeled as a network partition. Similarly, we are seeing problems with malicious users hacking
servers and otherwise disrupting major internet services. Tolerating these more problematic forms of disruption re-
quires a somewhat different understanding of the fundamental consistency/availability trade-offs.

Quote from: smooth on October 06, 2017, 08:08:55 PM

It is a lot harder to do that for two reasons. One is that the services they provide at the p2p layer are very limited and by design like all p2p layers somewhat difficult to attack (compared to the web service layer which requires higher level operations like "show me all of @user's posts). The other is that the IP addresses are secret. Not even shared with each other, and most of the block producer nodes don't accept incoming connections. Whales don't really have anything to do with this, so I'm not sure where you are getting that from.

Block producers have to take incoming data from the outside thus they must be contactable from the outside. The whale controlled perimeter keeps the IP addresses of the block producers secret.

Quote from: smooth on October 06, 2017, 08:08:55 PM

But for regular nodes (which you might run on your own computer, an exchange or other service might run, etc.), it's just a p2p network. There's never been an inability for any ordinary node to connect to the p2p network afaik (other than implementation bugs, none known to exist right now). In fact I'm not aware of any p2p network that has been successfully DoS attacked on a large scale. It is certainly a lot harder than attacking a few known web servers.

The problem then is the web serving is not a sufficiently diversified P2P network as I stated. Indeed P2P networks are more resilient, but do note the footnote in my prior post. When IPv6 comes, the IP throttling that protects most P2P networks will be useless (not the long-term connection between themselves but the new connections from the outside from users).

Quote from: smooth on October 06, 2017, 08:08:55 PM

Quote from: Hyperme.sh on October 06, 2017, 07:57:22 PM

As Vitalik pointed out, the usage has been quite small. Scale and up then the fireworks are more likely, because the incentives to attack it will be much greater.

I guess it is all relative. It has something like top 3 users and transactions among all blockchains (and on occasion has been #1 in transactions). That may still be considered small in the pig picture.

Youre entirely missing the point. It is an economic point, not a traffic volume nor network-access-attack point. I already explained in my prior post about whale-dependency economics/vulnerabilities. Steem is what a $200 million market cap? If it became a $100 billion market cap, then the economic incentives to attack whales in numerous ways such as lawsuits, nation-state regulators, assassins, etc..

Im very shocked that you as a former supporter of permissionless, proof-of-work, have apparently become hoodwinked and think that (necessarily permissioned) Byzantine agreement is adequate. Must be the lucrative sneakymine that changed your technological mind? Or am I just misinterpreting what you wrote?