Topic: Steem pyramid scheme revealed - page 59. (Read 107064 times)

watching this

I couldn't join Steem because I need radical changes to it before I could in good conscience throw all my effort into it.

There are so many of its features that I feel have to be totally changed. For one, I think whales should not have any more voting power (on content) than a dolphin does. My design accomplishes this.

I am radically changing what they have. I wouldn't have been able to work with them. I did consider it, then I realized it would be impossible. Just so you know, I want to work with others, but I have to believe in what I am working on.

Investors should not be curators! That is bullshit. Yes they have a vested interest to want good content, but that doesn't mean they are expert curators. Maximum divison-of-labor is inexorable. (Imagine if my gf and her friends have absolutely nothing in common with the 50 whales of Steem)

Also every elephant unintentionally kills things it steps on. Ditto Godzilla when he gingering tries to walk between buildings.

Common sense shit like that is why I don't work with whackos.

Neither.

I think it is becoming somewhat difficult for a direct competitor to overcome the first-mover advantage, especially given that no direct competitors are even ready yet, Steem is still growing quickly, and the platform is improving at a reasonable pace.

But I wouldn't say impossible or even highly improbable. (I would say, though, that, for any particular competitor identified in advance, it is reasonably improbable.)

If growth stalls then the odds shift significantly.


I agree with that and I think I said so earlier in this thread in words similar to these: Most new ventures fail. Most cryptocoins fail. The odds for Steem (or anything else), in absolute terms, are probably not that good. Don't put all your eggs in one basket.


Correct.

It is not clear from your comments in this thread whether you believe it is impossible or highly improbable for a competitor to Steem to be viable.

What I am trying to explain is that the chance of Steem succeeding to become a very successful social network is very improbable. So having more experiments (especially if they are not exact copies of Steem and attempt to diverge greatly from Steem) is the best chance we have of actually hitting a homerun with one of them.

I'd give Steem (the source code, not Steemit, Inc nor the current STEEM tokens) better odds had the blockchain also been forkable. Because more groups would be able to compete sooner. But actually it is good for me the blockchain is not forkable. Gives me more time. And good for you too perhaps, as it gives you more time to cash out of your lucky mine (although you are giving mixed signals having stated upthread that rebalancing your portfolio is logical but then today saying you'd consider buying SP). I can't imagine what it is like to be in your position with such a large stake in a project that attempts to turn blockchains into a corporation. I realize now you are more agnostic than I originally thought. Which is good in a way. But I don't think I would see the point of doing a blockchain that 40 - 80% owned by a corporation. Might as well just run a corporate database and dispense with all the bullshit obfuscation. In other words, my bullshit meter wouldn't make me feel very proud if I was in your shoes. Okay I realize the plan is to give it all away to free signups, but  there was another way to do that without any "pre"-mining of the tokens that will be given away where we have to trust Steemit's promise and follow through (and trust that the abandonment rate of those tokens isn't significant since we are told that is what will dilute the few insiders who go the rest of the lucky mine). I mean the decentralization is all an obfuscation any way.

Altcoins are wild speculations. That is why not having a medium-term investment option for Steem is such a critical error.

Unless you state otherwise, I am assuming that your stance is driven much by disbelief in words/plans and strong affinity to shipping projects. If so, I'd agree.

I'm not sure what Parker's servers are. Google suggested it has something to do with Minecraft, which I've never followed. Maybe you can elaborate and we can consider what lessons might be learned. We talked a bit about the issue of attacks against witnesses within the past few pages.


I have been buying ETC for a week as part of rebalancing my crypto holdings. I might be done buying it for now, even though it still has potentially significant upside.

I did see your post yesterday about it, and I agreed with it, but most of my position was already established.

Well fuck those who bought ETC when I said to yesterday, are up 36% in 36 hours. And those who sold STEEM as I said to are down -20% at least. Those who followed me and sold STEEM and bought ETC have more than 50% advantage over those that didn't.

But what the fuck do I know. You all better join smooth and power up.

Wait for it

https://www.google.com/trends/explore#q=Reddit%2C%20Instagram%2C%20Snapchat%2C%20whatsapp%2C%20twitter&cmpt=q&tz=Etc%2FGMT-8

https://steemit.com/steemit/@generalizethis/why-steemit-may-fail

*adjusted title to be more palatable

Steem is getting rogered here, and on bittrex at least I am only seeing sell orders at the moment. Think the market will keep sliding from here. What surprises me is that synereo (as the alternative) hasn't really risen

Since afaik, they haven't published the data in an easily accessible format, I have no way to confirm nor refute unpublished benchmarks.

But I note you refer to "transactions", and I am referring to edits of blogs and comments. They may have simulated adding these at 100X current rate, but perhaps not random editing of content updates to the blockchain data, i.e. random writes (and then random requests for data to the web server). Since random edits can be so much more costly (and also require a less optimal database design), they can have a big impact even if they are not the most numerous case.

Note I presume they can scale any design with enough capital to spend on infrastructure and engineering. But if this is a significant cost (and maybe it is not, I dunno), it will come out of the pockets of the users one way or the other. For example, it is not unfathomable that it might possibly cause a problem in that user's stake becomes insufficient over time and users have to buy stake to continue, but instead users might leave for the more efficient system that doesn't need to charge them.

When I refer to scaling, I don't mean that it is physically implausible to scale it. I am referring to how the cost and complexity grow through scaling (i.e. big O notation), and potential impacts thereof.


Thanks for sharing that.

Note this is also a weakness of DPoS. If witnesses were instead fungible amongst all nodes, then it doesn't matter when a database is corrupted on any subset of witnesses.

Here is my response to smooth's Alexa point:

https://steemit.com/steem/@anonymint/steemit-s-skyrocketing-alexa-rank-on-the-road-to-world-domination

The performance of the above post will be yet another indicator of where Steem is good at displaying relevant blog posts or whether there is controlling hand that prevents objective criticism/questions. The fact that already one user commented that he didn't even know about Ello, indicates this is a very relevant blog for that audience. As for new audiences, well Steemit has to gain a lot wider usership before we can write to them. As the cosplayer girl discovered, her cosplaying audience was too small on Steemit at this time.

Also note this:

https://www.thesaleslion.com/numbers-rankings-alexa-waste-time-stupid/

*fixed

As far as the witnesses go, is that equivalent to Parker's servers? Or can they adapt in crisis?

SteemServices is not "official" it is a consortium of a few whales (not me) who do marketing and provide other supporting services for the platform. That's a pretty good number of followers for them at half the official twitter. I doubt they literally bought them but they may have run some sort of promotion to encourage it, I don't remember.

As far as interest versus numbers, does anyone have any numbers for Linkedin and twitter? These could give you a gauge into media and corporate interest. I'll put the current numbers here in case there is no alexa-like stat-machine:

(assuming these pages are official)

https://www.linkedin.com/company/steemit -- 115 (followers)

https://twitter.com/Steemit -- 1570 (seem to remember this a few hundred lower a week or so ago, but memory is well-known as a flawed content aggregate....)

I'm not. They ran the ordinary node which writes to a database. Real world load patterns are of course unknowable and I don't know how realistic any of these tests were but there is also a pretty (or very) wide margin between running on ordinary cheap unoptimized hardware and something actually optimized to host a database.

I'm pretty sure ability to handle only the computational load is much, much higher, but that is completely unrealistic, so pointless to even quote those "Wow!" numbers.

There is a deployment scaling issue in that the database not fully ACID and recovery from corruption is slow (more precisely will become slow if the tx volume increases; currently it isn't too bad). The only way to deal with that currently is with redundant systems and trailing backups. It is a pain in the ass, but workable.


Bitcoin transaction volume has steadily increased. It may have finally gotten to the point where recent blocks just can't be indexed on cheap hard drives any more (using Bitcoin Core). i don't know what happened with the mouse and keyboard being dead though.

Note by transaction rate tests you mention, I presume they are referring to computational load and not database load (since for one reason I doubt they even could simulate the real world data load patterns a priori). I am suspecting (not confirmed, as I didn't study the code) they may not be prepared for database load (this is usually the myopia of every blockchain upstart, even Monero went through this learning experience).

As for computational and network load issues, I think the issue is likely only if we want decentralization and performance.

Since I apparently realized upthread how the 19 witnesses can thwart DDoS using disposable IP addresses, it doesn't appear that the a priori round-robin attribute of DPoS is a blockchain DDoS vulnerability. As for reliability, if we assume the 19 witnesses are 100% loyal and have invested significantly in infrastructure, then reliability should be robust. All of this seems to require some coordination, so this is more or less a very centralized blockchain in terms of control. And it requires there not be disagreement. When disagreement comes, and the proof-of-stake is not 50% controlled by a few whales or the control of the whales diverges from the desires of the majority of users/investors (not a majority by stake due to power-law distribution), then chaos could result. But again that is not a near-term issue but I am not confident it is an anti-fragile design.

Afaics, the speed of transactions probably can't improve much lower than the current 3 seconds with DPoS, but that won't matter near-term.

I'm glad you brought this up.  A couple days ago I was syncing up a Bitcoin Core full wallet via USB3 to external USB3 mechanical hard drive.  The chain was already something like 95% done beforehand and I had synced it the same way many times before, but this time after like 10 minutes of going at it with the crunching sound you hear when doing intensive hard drive stuff, a Bitcoin QT has stopped responding message pops up and the drive just stops as every USB port on the computer also stops working (mouse and keyboard dead).  

After reboot, everything works perfectly fine again.  I have never once seen anything like this occur before in Bitcoin, but I often hear people bring up wild claims about Monero doing stuff like this.  The mechanical hard drive wasn't even hot or anything, but it seems like it could not handle the load from the Bitcoin wallet somehow.

Okay I misunderstood then. FWIW. LMDB does do most writing to the end of the file, not randomly. Of course any database must some point do some random writes, but it is minimized. I think the main reason for Monero having a high user-perceived impact is just that it is optimized to do a lot of precessing in a short term. When you take the sync time from several days down to an hour and do the same work, the intensity is obviously vastly increased. Probably some work is needed on backgrounding and throttling it better (i.e. take two hours on the same equipment at least while the computer is otherwise in use, but in a less annoying way)

I don't know the details of the database in Steem/Graphine but several different people have said they've tested it at 100x the current transaction volume of Steem and had no problems with ordinary hardware. That takes daily active users to about 4 million, or higher with better hardware.

I replied saying that I personally know people who've told me their laptop becomes unusable while syncing Monero, which I consider to be 'slamming'.

I remember his reply indicating that my points were valid and mentioning some of the ways to tackle those points. I had basically said need to always write to the end of the file and never insert data at random locations into a file. His stance was coming more from how to deal with databases that must do random writing. My stance was coming from eliminating random writing as a design goal. So perhaps you misunderstood my context (and I wasn't eager to point that out to him, since he reply went off on issues about random access databases which wasn't even my focus at all and didn't see any point in wasting my time). Paradigm-shifts can pull the rug out from under an expert.

Feel free to point us back to the post you have in my mind (it is in the Monero Technical thread afair), in case my recollection is different from what you think was discussed.

Btw, 'slam' is not referring to John Conner's accusation that Monero kills every SSD (or what ever he wrote). But it is true that with excessive random writing, the MTBF of the SSD will drop due to several factors of the way an SSD operates at the low-level.

Maybe I shouldn't give away so much information for free (versus being cryptic and having people underestimate me, which has its trade-offs), but as long as I am getting back information then it is worth it.