PUT price directly controlled by supply and demand

  • Relay nodes will be rate limiting to some extent. They share their bandwidth between clients connecting through them.
  • Caching will mitigate the farming cost
  • @Mendrit mentioned - Real $$$ to the downloader
  • The farmers doing this will not be rewarded since the GETs need to be random to minimise caching effect. So the best they can do is help random other farmers while costing themselves more in lost rewards due to using up their bandwidth. Even downloading requires up bandwidth and the old metrics was that the up bandwidth enabled the down. So if using all the down then you are also using most of the up bandwidth.
  • More safecoin in the market place will reduce the $$$ price thus making the effort to “spam” GETs less profitable to the other farmers.


I think that if pay the developer is implemented there may be incentive for the app developer to spam gets from their app, particularly given that users could be made to bear the cost of downloading.


That only pays the GETs done to load the APP. Not the GETs done by the APP.

Otherwise it would be a gameable way to “print coins” All the APP has to do is GET all the time wouldn’t it and not controllable by the network at all. Also the wallet ID would then tracked by the network in order to reward on GETs done by the APP. Then the network has to know which GETs were done by which APP and the state being kept by the network would be much larger

No its just loading of the APP that get PtD rewards. So all the developer can do is bloat the APP to get more rewards, but then someone will release a slimmed down version and people will use that because it loads quicker etc.


Hmhmm - where is the difference between gets done by the app and ‘loading necessary updates for color schemes and background images in HD quality 24 times a day’ ?


The APP will be stored in a file(s) and have the PtD payment address with it.

Then when the APP is read off the network then the PtD rewards are paid on those GETs for the APP file(s)

So any aux files that are part of the APP then will presumably have the PtD payment address stored in those files.

But when the APP writes files from the user and reads them then those chunks/MDs/files will not have the developers payment address stored since they are stored by the user’s client on behalf of the APP. Thus later reads of that data cannot have PtD rewards. Same if the APP reads files/MDs/chunks written by other users.

And depending on how the APIs are done then even just reading the APP’s files will not cause PtD rewards since its just GETs and not a APP load being done. Otherwise it is just ever so open to abuse that will be done by simply reading chunks that have PtD payment addresses associated with them. Its just logical.


That’s exactly what I meant… Yes

… Well… Then I might bundle with my app a client that performs APP loads instead of simple GETs…?

… I would dare to say ‘anti features don’t work with open source software’



User has to authorise the loads don’t they?

Anyhow since the code for PtD is not written then I am sure this will be taken into account. They are simply too easy to abuse if left as open slather.


Thank you @neo for the answer :slight_smile:

Your argumentation makes sense, selfish farmers dont want to boost everyone’s farming rate with their money. Unless they control a really big portion of the network and want a high safecoin inflation until it gets scarce and expensive.

Once again a good distribution of farming nodes is the key to prevent abuse.


So true.

This is why I believe that the farming rewards will be done in a way that enables the home farmer above the “institutional” farmer. Spare resources costing little to run will be a key factor.


From the trend it seems that storage is almost doubling every year. With something like a decentralised autonomous Internet with data storage becoming popular it might also lead to push for lot quicker breakthroughs and commercialisation of this tech (maybe cheaper Multi terabyte, small sized SSDs etc. I was already surprised by the miniature size of the 1TiB nvme drive that I had when my system got disassembled some weeks back.

Maybe not very relevant but I suspect commercialisation of one tech soon pushes for unexpected ancillary or dormant ones around and overall the entire eco-system benefits.


And before last year SSD drive technology wasn’t much more than faster Flash mem sticks. Then the Nvme drives started to demand fast SSD technology to happen. Also some insider information said that increases in SSD drive sizes of 40x current is being worked on for release this or next year. So expect multiple TB drives to become the norm soon and if the info pans out then maybe 20TB or 30TB SSDs by the end of next year.

SSD tech is going 3D fabrication in a big way so as the cell size reduces then we might see a cubing of sizing rather than the traditional squaring of 2D logic chips.


Doesn’t all of this depend on SC being divisible or not?


I don’t remember all the discussions in this thread anymore :stuck_out_tongue: but in general i agree. Divisibility becomes natural when the value increases a lot. Then you either don’t divide but then same amt of coin gives you proportionally more stuff (which may or may not be desirable for the consumer) or there is a fractional component. The fractional part will ofc make handling of increasing or falling coin prices smoother. More demand and less supply will shoot the coin price and fractions might be necessary at that point. Beyond that i’m interested in this topic myself :smiley: