Thanks for explaining it, it helps get a sense of how things work.
What about increasing the typical RC costs during normal traffic times? What effect would it have on potential attackers if any transaction costs much more RC, even during normal times? In regards to regular genuine users, if they are delegated sufficient RC allowing them to perform the normal amount of activities a regular user does, it shouldn't make any difference to them. But would it make it far more difficult for an attacker to make a flood attack if even regular transactions cost much more RC?
Of course increasing RC costs would make the flood attack harder, but first and foremost would also make a lot of users dependent on delegations. Increasing RC costs would be like making one of the damages of successful flood attack the reality without any attack occurring.
I'm on a position that even free users should have enough of their own RC to do basic transactions (free users are not actually free, since there is fee or massive RC cost for the creator). They absolutely must be able to make authority updates, but they should also be able to use all their allotted daily votes or write an article of reasonable length (the only way to acquire stake without buying). Current RC costs are almost too high for that. If the typical traffic on Hive increased to the point when witnesses would decide to increase max block size, we are going to need to work on issue #679 - I've actually did most of the work already, except the actual values of scaled parameters, because it requires very long test runs to observe how RC costs are changing with different params and traffic levels (and yes, the solution allows witnesses to keep high RC costs despite allowing bigger blocks, but they'd also need to keep in mind that budgets meant for partially filled 64kB blocks only allow for 10 hours of saturated traffic on 2MB blocks and then all the RC in the system is consumed, you need to be blocktrades to do a transaction at that point).
I guess you are concerned about making users dependent on RC delegations. Why do you think that would be a problem? It seems that the rest of the network would be very heavily interested in making sure genuine users have enough RC to use the network. My concern is that with RC costs being too low, we are seeing massive spam, so for very little cost anyone can bloat the storage - this type of attack seems very feasible. If someone wanted to spam the network all day every day and massively grow the needed storage, they could do it for very little cost, no?
There is no massive spam. All the transactions Hive handles on daily basis only use like 15% of the capacity of the smallest allowed blocks (64kB), so even if they were all garbage, it would be nothing to worry about on technical level. I know you are concerned that the blockchain will be filled mostly by worthless data, however the relevance of almost everything that we store diminishes with time, some data is just worthless from the start, but in the long run its existence in the blockchain changes very little. Storage is cheap and gets cheaper, computers are also faster every year, so we won't suddenly find ourselves having to replay for weeks. The only problem I currently see is that full stack requires a lot of fast storage, but that can be addressed with smart pruning, database segmentation etc. - it just needs development. It is not an accident that despite tens of millions of new blocks the recommended size of SHM did not change upward.
I thing that in the future Hive will be processed not as one-server-handles-all, but each application will have their own servers that only need to process their relevant data and nothing else, so the load on servers will only increase with popularity of specific application. We just need to make it easier to handle the data that way. Also a lot is going to be handled outside of main chain if the idea behind lite-accounts is used fully.
The RC costs are too high for the abysmal level of traffic that we currently have. I'm concerned that if the traffic rose as little as to actually use allotted budgets, the RC costs would remove free users from the network. F.e. my article cost was almost 12B RC - that is over twice the full manabar of a typical free user.
Soon I will be doing formal tests for the purpose of RC scaling issue, so I should have data on how the costs change over time with different levels of traffic. It will take time though, because I'll need to produce like 1M blocks at least for each test :o) (which would normally take a month, thankfully we already have tools to squeeze that into more normal time frame).
Thanks for addressing these. Yeah, such modularity of databases seems like the way to go about things. But with
hived, we have all data chained together (maybe in the future that will change but it seems speculative to rely on that for making current irreversible design decisions). My main concern is the replay time, which actually for me was already like 1-2 weeks since I used a mini PC at home. If we keep things as is, especially if the chain gets some more popularity, we can get to months of replay time for this kind of hardware.So then the solution becomes to go for higher-spec'd servers, but requiring that means less people able to afford to run one. It also means we are using hardware and energy consumption for completely pointless activities, such as allowing operators of thousands of accounts to spam the chain (doesn't all this bot posting, worth millions of comments, equate to mass spam?).
The other concern is that all app development becomes that much more time-consuming since you have to spend time very carefully pruning (which in itself requires good overall Hive blockchain knowledge, i.e. an impediment to new devs) to get to just the data you need, otherwise your db has too many records and you hit performance issues that in themself take a lot of dev time to address.