Maybe if I said it this way. If a farmer is “lucky” enough to get a coin for that GET, it does not change the chance that a dev will get a coin. And if I am wrong then I am sure digipl will jump in and correct us both.
By a very small amount.
Well initially the network is small, only 10% of coins have been given, the dynamic formula produces the certain rates which happen to be whats been quoted. But as the dynamics change so do the results from the maths.
This is still be coded as far as I know and may change depending of issues that may arise. Need to fully read the RFC again because it may have changed already and I was basing my understanding on a few posts around this where David mentioned a few of these things.
Overall I think gaming the system will be too easy, I think it’s clear from this discussion, and I’d request those defending the rules on behalf on MaidSafe to disclose conflicts of interest–what do you stand to gain from these rules (i.e., what apps will be cash cows for you under these rules)?
Architecture and design of apps from the ground up will revolve around maximizing Gets. Think of how apps were designed back in the 80s. Lean on memory, everything very efficient. As computing resources increased so too did memory and CPU req’s of apps, naturally. Now consider how apps would have evolved if by using more memory and CPU the apps made more money.
And consider also the massive bloat in every web page today strictly to serve ads.
No one cares about bloat. Developers are fine with it when it makes development easier, and they’ll especially love it if it makes them money. Users won’t care.
I worry this will steadily erode the reputation of the currency and the network.
From what I could see there was some very good points raised from many directions.
We may have to see results from the test systems which we’ll be able to install in a few weeks. Caching will have a large effect on the effectiveness over excessive stuffing.
Also if we see “status” programs that indicate the amount of GETs/PUTs (plus other goodies), which incidentally people check their phones when they are using very limited/expensive mobile data, then the opportunity for overly stuffed APPs maybe limited.
Caching will be very important, and a method to monitor client/app would help determine how this would pan out.
A wise attacker will wait for production Safecoin before he unleashes his strategy, which is why it is important how testing will be conducted.
How likely is it that testing with fake coins would give us an order of magnitude precision?
and I was basing my understanding on a few posts around this where David mentioned a few of these things.