EOS - Asynchronous Smart Contract Platform - (Dan Larimer of Bitshares/Steem)

[Hyperme.sh]

Steemit’s DPoS was offline for over an hour before I slept. And when I awoke it has still been down several hours later. The DPoS centralized ledger design is not robust enough to scale out to the world. It works for some small shit like Steemit sometimes.

Only the web site was down not the DPoS. Other websites accessing the same blockchain or users/services accessing the blockchain directly with a node were still up.

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

Again I repeat that I visited busy.org several times and it refused to load any data from the blockchain. I even tried loading from different IP addresses through a VPN after it was not loading from my IP address.

I also checked steemd.com and it said “reloading the Node”.

I know because I was trying to get a url from one of my Steemit blogs and so I was trying to find any way to access the blockchain data and thus I tried every way I know of (as I do not actually run a Steem full node).

How can you refute those events? Where is your proof?

[1713431951]

1713431951

[smooth]

I edited above that both busy.org and steemit.com were DDoS attacked, but some other sites worked and services using nodes directly such as exchanges were up.

steemd.com has been intermittently unreliable for months. Not related.

How can you refute those events? Where is your proof?

I can't really provide any except that I'm running a node and the logs show no interruption, and some people reported using chainbb.com. Possibly if there is a working chain explorer you can see blocks and transactions during that period although the timestamps aren't necessarily trustworthy in hindsight.

[Hyperme.sh]

I edited above that both busy.org and steemit.com were DDoS attacked, but some other sites worked and services using nodes directly such as exchanges were up.

Are you telling me the design of these sites is loading data from the blockchain by way of passing through the centralized website instead of directly to the client via a WebSocket?

That does not make any sense!

The website for busy.org was loading just fine. It was the user data from the blockchain that was not working (meaning I saw busy indicators in the iframes where it was waiting to load the data from the blockchain). Thus I logically concluded that the blockchain nodes which serve data were DDoSed.

Are you saying that there is centralized caching of the data? So that would be design a flaw.

You guys do not forget I am a programmer and you can not get away with BS. The FUDsters/shills here will try to fool the n00bs with personal attacks against me I am sure. That is the one of the tactics that scammers use to keep the FOMO lies alive.

[smooth]

I edited above that both busy.org and steemit.com were DDoS attacked, but some other sites worked and services using nodes directly such as exchanges were up.

Are you telling me the design of these sites is loading data from the blockchain by way of passing through the centralized website instead of directly to the client via a WebSocket?

That does not make any sense!

The website for busy.org was loading just fine. It was the user data from the blockchain that was not working. Thus I logically concluded that the blockchain nodes which serve data were DDoSed.

Are you saying that there is centralized caching of the data? So that would be design flaw.

websockets connect to a web server (a websocket server is a web server, by definition).

That is the point where it gets DDoSed. The static web content (javascript code, etc.) is much harder easier to serve up and harder to DDoS.

There's no 'centralized' caching of data in the sense that anyone can run their own web server and a node and it doesn't rely on any other.

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

[Hyperme.sh]

I edited above that both busy.org and steemit.com were DDoS attacked, but some other sites worked and services using nodes directly such as exchanges were up.

Are you telling me the design of these sites is loading data from the blockchain by way of passing through the centralized website instead of directly to the client via a WebSocket?

That does not make any sense!

The website for busy.org was loading just fine. It was the user data from the blockchain that was not working. Thus I logically concluded that the blockchain nodes which serve data were DDoSed.

Are you saying that there is centralized caching of the data? So that would be design flaw.

websockets connect to a web server (a websocket server is a web server, by definition).

Full nodes and servers, effectively same thing if we want them to be.

The point is having lots of them (and having asymmetrical costs[1] anti-DDoS in the design), so that access isn’t centralized.

That is the point where it gets DDoSed. The static web content (javascript code, etc.) is much harder easier to serve up and harder to DDoS.

There's no 'centralized' caching of data in the sense that anyone can run their own web server and a node and it doesn't rely on any other.

From the users’ perspective that is centralization. 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.

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

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?

The point is that the system is not permissionless for nodes as is the case for proof-of-work. You depend on whales and their secrets. If whales start fighting each other or get attacked by a powerful entity personally, the system is not real-time resilient. It may or may not be resilient after there is a vote. It can actually go into complete stall (as all Byzantine agreement systems do, including Byteball) if no grouping has 51% of the voting power and the liveness threshold is not met. (I am aware that one can vote for more than one delegate witness at a time)

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.

[1] Bandwidth attacks are asymmetrical in favor of verifying nodes because said nodes do not pay for incoming data. So I am referring to the cost of verifying the signatures, which in the case of elliptic curve cryptography is asymmetrically in favor of the attacker so it is better to turn this into a bandwidth attack (for the attacker to send more data at his cost than the cost of verifying the signature, but what if the attacker has botnets and does not pay hardly anything for bandwidth). And Hashcash-style proof-of-work as anti-DDoS is not viable because it is asymmetric in favor of the attacker versus the legitimate users. Throttling by IP may be ineffective as IPv6 is adopted. Fast signature verification becomes very important in the future (unless the economic size of the system dwarfs botnet bandwidth value) and DPoS’ centralization remains a separate problem.

[chryspano]

You guys do not forget I am a programmer and you can not get away with BS.

You are mostly a FUDster, does this make you a dual class or a multi class?

Btw are you geting paid per hour or per post?

If it is per post I believe that you are cheating!

[smooth]

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.

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.

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. If the bulk of the block producers are taken down, the network will grind to a halt. 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.

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.

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.

[Hyperme.sh]

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.

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.

We’re 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.

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.

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

Scalability:

Increasingly, we require that our systems be scalable, designed not just for today’s 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.

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.

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

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.

You’re 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..

I’m 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?

[smooth]

I’m 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.

You're overgeneralizing. I'm responding to your narrow point about the DPoS being down. That didn't happen, which isn't even to say that it can't happen, but it hasn't yet (except as I noted earlier by bugs in the first few months of deployment).

I'm pretty skeptical about Steem/it (or EOS) ever becoming a decentralized permissionless system. It's at best semi-centralized in practice certainly and by design to some extent too.

Block producers have to take incoming data from the outside thus they must be contactable from the outside.

No, they do not have to be contactable. They only need to be connected in some manner to the p2p network. That can be through a combination of known and unknown nodes. It could be by passively listening to a broadcast signal and transmitting their signed blocks by (fast) carrier pigeon. The asymmetry favors the defender here because an attacker has to cut off all communication (and to effectively attack the  network has to do this to most of the block producers), the defender only needs to maintain some minimum communication. Even then if the node is completely cut off, the defender can switch to a completely different node. I don't see the resulting whack a mole as a serious threat, more of an annoyance.

[Hyperme.sh]

I’m 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?technological mind.

You're overgeneralizing. I'm responding to your narrow point about the DPoS being down. That didn't happen, which isn't even to say that it can't happen, but it hasn't yet (except as I noted earlier by bugs in the first few months of deployment).

I'm pretty skeptical about Steem/it (or EOS) ever becoming a decentralized permissionless system. It's at best semi-centralized in practice certainly and by design to some extent too.

Okay thanks for the clarification. Note I had been editing that part while you were writing, so it is good to see I was just misinterpreting your intent and we are on the roughly the same page w.r.t. to that narrow point (not all my comments).

I’m happy that I do not have to conclude that @smooth lost his objectivity, because now I know you did not. I was feeling queasy (as if I had entered The Twilight Zone) if you have gone to the darkside of money over truth.

EDIT: but as of yet no one has shown how to design a permissionless consensus system that does not end up necessarily centralized unless it remains highly inflationary (specifically this research link).

Block producers have to take incoming data from the outside thus they must be contactable from the outside.

No, they do not have to be contactable. They only need to be connected in some manner to the p2p network. That can be through a combination of known and unknown nodes. It could be by passively listening to a broadcast signal and transmitting their signed blocks by (fast) carrier pigeon. The asymmetry favors the defender here because an attacker has to cut off all communication (and to effectively attack the  network has to do this to most of the block producers), the defender only needs to maintain some minimum communication. Even then if the node is completely cut off, the defender can switch to a completely different node. I don't see the resulting whack a mole as a serious threat, more of an annoyance.

I did not write anything otherwise! I said the perimeter keeps the IP addresses of the block producers secret. You’re going in circles in your argumentation.

You seem to think I was implying the block producers/generators could be attacked directly but I never wrote that.

My point is that the (webserving portion of some portion of the) P2P perimeter went down. And it ostensibly did. I consider that part of the blockchain system, from the perspective of the “bringing it to the masses goal”.

I also made the separate point that the block producing nodes and the secrecy of their connections to the others (surely not pigeons if we want fast transactions) can be threatened as the economic value of the system grows.

Also there is the point that the delegate block producers operating independently (i.e. so they do not need to connect to many other nodes) is only possible because as Vitalik pointed out, there is no verifiable objectivity in the consensus. It is all trust based shit. Which means indistinguishable from attack when the block producers start fighting each other one day.

Really DPoS is all about obfuscating what it really is. We might as well just ask Visa to provide servers and be done with it. Why obfuscate it what it really is in the end game? (Oh so we can shill some FOMO bags to n00bs)

Permissionless, decentralized, scalable consensus algorithms are an extremely difficult problem to solve. Vitalik and separately myself (and others) have been working on this problem nonstop for the past years. DPoS is a very simplistic way to cut corners and not actually solve the problem at all.

DPoS was an expedient semi-centralized solution for scaling and proving a use case like Steem. For that reason, I supported it. But then when that same centralized ledger technology is repackaged and resold in a $200+ million “no rights token” sale, I realized there is no intention of actually solving the most difficult and fundamental technological problems. They presumably have enough money already and in my ethics they could have spent that first on research before entering the market to take more money from n00bs.

I wanted to see that money from Steem go to a solid technological research effort. It’s a shame that so much resources are being presumably squandered on who knows what. All I see is he realized there was all this n00b ETH for the taking. Speculation focus, not technology focus. Turns me off. And ditto on the user adoption marketing and business model development as well. Instead of focusing on that hard work, appears to me the focus is on selling FOMO bags.

[XbladeX]

***
I’m happy that I do not have to conclude that @smooth lost his objectivity, because now I know you did not. I was feeling queasy (as if I had entered The Twilight Zone) if you have gone to the darkside of money over truth.

Such DDOS have cost - probably there is no sence for anyone to attack steem... there is no ads  revenue that they take from any bigger company like youtube.
Sure there is some trafic but this is not big deal that is why noone realy wants to attack it.
What will attacker gain ? hmm... Does steem have any competitrs ? I don't see anything in crypto there are some centralized platforms but steem is far away from thread to them.
EOS may be : ) if it will grow as platform attackes will have motivation to hit it and pump its coin to get at that lvl you need to be 1:1 with ETH market share then some people will
focus on EOS and try to attack that network.
Do you see that BTC / BCH attack with EDA ? You need competitor to hit and then you stirke here can be same but EOS need higer weight to deal with it.

[smooth]

(surely not pigeons if we want fast transactions)

I qualified it as "fast" pigeons. Genetic engineering will help.

The point being there just needs to be some means of communication and it is a lot harder for someone to cut off all of those than to, for example, go after the the web UI.

Clearly Vitalik is wrong about Steem not being worth attacking. There have been several attacks including the DDoS against the web layer, spam attacks (which revealed some flaws in the bandwidth allocation, which were fixed), the key-stealing vulnerability in the JavaScript and I think a few others.

Attackers will go after the most vulnerable portions first. Attacking the block producers is way down on the list, and I continue to believe that block producers have very strong defenses, such as changing apparent network location regularly.

@XbladeX I don't know why people are attacking it, but they are.

[Hyperme.sh]

(surely not pigeons if we want fast transactions)

I qualified it as "fast" pigeons. Genetic engineering will help.

You’re notorious (at least with me) for that pigeon comment which dates back to (2014?) discussions of offchain versus Cryptonote onchain anonymity. Recently I had tried to find your original comment but I could not. Did you delete it? Or was it in a private message only?

Now your upgrading the technology of your metaphorical pigeons.  

Attackers will go after the most vulnerable portions first. Attacking the block producers is way down on the list, and I continue to believe that block producers have very strong defenses, such as changing apparent network location regularly.

You’re still arguing the network access attack on block producers, which is not my point.

My economic point remains that the block producers will attack each other or be attacked by non-network-access means if ever a DPoS chain reaches $1 trillion mcap which I pointed out in my prior post. Actually @r0ach was the first person to make that prediction in 2015 or 2016 afair.

You’re 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..

Also there is the point that the delegate block producers operating independently (i.e. so they do not need to connect to many other nodes) is only possible because as Vitalik pointed out, there is no verifiable objectivity in the consensus. It is all trust based shit. Which means indistinguishable from attack when the block producers start fighting each other one day.

(Note I finished editing my prior comment.)

@XbladeX I don't know why people are attacking it, but they are.

Somebody is upset that Dan has been combing his hair forward to cover up his receding hairline.

(I have nothing against Dan personally, just the $200 million token sale and the lack of focus on technology first)

[Morguk]

My friend has some EOS, such a bad investment, just keeps going down and down. Luckily he didn't put much into it but still a waste.

[Hyperme.sh]

My friend has some EOS, such a bad investment, just keeps going down and down. Luckily he didn't put much into it but still a waste.

Personally I hope it crashes and burns, so there are many pissed off investors complaining to securities regulators in their nations. To punish so perhaps our ecosystem might become more focused on real technological and business model innovation.

Unfortunately (or fortunately if you’re one of the bag holders) it probably will not. FOMO is a powerful psychological and economic phenomenon.

Had they raised $10 million, I would be much less vocal. Maybe said nothing in that case. Give the benefit of the doubt about what Dan might do with $10 million to make an important breakthrough. But $200 million is … not justifiable (if they did in fact raise that much, might just be buying from themselves).

Well a more open-minded viewpoint is that the free market destroys the capital of those who misallocate it. So perhaps it is all meant to be. It is the process. See ya…

Interesting point below about how it is not due to stupidity but rather selfishness/avarice that drives us away from valiant pack behavior towards self-destructive flock behavior:

Sheep Logic - This Is The Age Of The High-Functioning Sociopath

The determination to pursue any behavior that meets Hallmark #1 and #2 to absurd ends, even unto death. My worst sheep suicide story? The first year we kept sheep, we thought it would make sense to set up a hay net in their pen, which keeps the hay off the ground and lets the sheep feed themselves by pulling hay through the very loose loops of the net. Turned out, though, that the loops were so loose that a determined sheep could put her entire head inside the net, and if one sheep could do that, then two sheep could do that. And given how the hay net was hung and how these sheep were sensing each other, they started to move clockwise in unison, each trying to get an advantage over the other, still with their heads stuck in the net. At which point the net starts to tighten. And tighten. And tighten. My daughter found them the next morning, having strangled each other to death, unable to stop gorging themselves or seeking an advantage from the behavior of others. The other sheep were crowded around, stepping around the dead bodies, pulling hay for themselves out of the net. That was a bad day.

In both markets and in politics, our human intelligences are being trained to be sheep intelligences. That doesn’t make us sheep in the modern vernacular.

We are not becoming docile, stupid, and blindly obedient. On the contrary, we are becoming sheep as the Old Stories understood sheep … intensely selfish, intensely intelligent (but only in an other-regarding way) and intensely dogmatic, willing to pursue a myopic behavior even unto death.

[smooth]

(surely not pigeons if we want fast transactions)

I qualified it as "fast" pigeons. Genetic engineering will help.

You’re notorious (at least with me) for that pigeon comment which dates back to (2014?) discussions of offchain versus Cryptonote onchain anonymity. Recently I had tried to find your original comment but I could not. Did you delete it? Or was it in a private message only?

Have not deleted any comments. Don't remember whether it was PM of posted.

You’re still arguing the network access attack on block producers, which is not my point.

Fair enough, the comment earlier suggested that it was (at least initially).

My economic point remains that the block producers will attack each other or be attacked by non-network-access means if ever a DPoS chain reaches $1 trillion mcap which I pointed out in my prior post. Actually @r0ach was the first person to make that prediction in 2015 or 2016 afair.

I don't know how block producers can attack each other. They don't need to be directly connected to each other. Unlike Dash masternodes they don't need to have any fixed or public location or IP address, just some mechanism to deliver their signed blocks. As far as non-network means, I don't rule that out and in fact find it reasonably likely.

(I have nothing against Dan personally, just the $200 million token sale and the lack of focus on technology first)

Token sale is ongoing daily for several more months. I don't know how much has been raised but I'd guess well over $200 million. Wasn't the first chunk alone $200 million? Maybe buying from themselves is a valid point too. Its all very non-transparent, but probably a lot.

[Hyperme.sh]

Have not deleted any comments. Don't remember whether it was PM or posted.

Grrr (to myself). Remembering some post but I can’t find it. It’s a nerdy form of the dog eating the car keys.

Ditto now on a research paper about trading off safety for liveness which I wanted to add to our discussion. I know I wrote a link to it some where, but even my writings are so voluminous I doubt I can find it if I do not remember the title.

My economic point remains that the block producers will attack each other or be attacked by non-network-access means if ever a DPoS chain reaches $1 trillion mcap which I pointed out in my prior post. Actually @r0ach was the first person to make that prediction in 2015 or 2016 afair.

I don't know how block producers can attack each other. They don't need to be directly connected to each other. Unlike Dash masternodes they don't need to have any fixed or public location or IP address, just some mechanism to deliver their signed blocks. As far as non-network means, I don't rule that out and in fact find it reasonably likely.

By disagreeing on the consensus. They could double-spend transactions or refuse to acknowledge blocks. Requires a vote (or some centralized power) to remove the faulty block producers, but there is even a threshold where the voters can not objectively determine which ones are at fault. This is Byzantine agreement.

The entire point is that in an asynchronous setting, there must be adherence to the liveness and consensus thresholds, else nothing at all is objectively observable.

Perhaps it would fork or stall in chaos or the strongest centralized power would take control (if there is one that is much stronger than the rest). Also afaik DPoS is not a formal Byzantine agreement protocol and there’s just an assumption of trust and correct synchronous ordering of block production, but afaik no actual protocol mechanism between the block producers to enforce it? I have never seen a formal specification of the DPoS protocol that block producers follow. IOHK’s provably correct Ouroboros’ PoS protocol can be delegated, so DPoS could be changed to that to get a more formal result and then from there we could analyse the dependencies that are just undeclared and adhoc in DPoS.

There is an Issues thread some where on Github where we delved into this last year and even Dan came in there. But I don’t remember where that thread is. Perhaps it was in Cosmos’ issue tracker.

The problem is that n00bs have no comprehension of this. They see Steemit and think “wow it works!”.

[Futureblnr]

Cappasity's ARToken chose an EOS platform to "ensure a robust transaction flow,... capable of withstanding up to millions transaction per second."

Do u support them or not in their choice?

[autada]

EOS is a scam and their ICO time is too long, this will be dumped to 0.3 usd, maybe, let us see.

[Dorky]

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

But isn't there some major limitations with PoW as well? Which is what PoS is actually trying to solve?