Or all their devices will have a vault installed to use the free resource and to be able to store all the information in their safe network and the state to have access to it. No local storage, no personal space…
And then the 5 eyes realize this is their dream: strong encryption between people, but government access on demand, with legal “protections” of course . My fear is all of this “hate speech” nonsense and “its to protect the children” speak, regulations could pressure people into one of these buckets. The stuff of nightmares right there
This only shows how little people value freedom - far more important is a nice apartment and a well-paid job. As long as China is well economically and people get a good life there will be no change of government…
with food, comfort, and access to sex, most can’t be bothered to fight on principle.
+1 to that.
I’d like to see a decent bonus (discuss decent) paid to all staff (and past staff who left without rancour) once we reach some threshold (discuss) after launch of Fleming and listing on another couple of exchanges.
EDIT — Ok I wrote this before I read
lots to catch up on in this thread
My feeling is the reason for having a storecost and reward is not clear enough and this is leading to further confusion about other things like initial price for upload and how fast to mint new coins. Once we clarify the reason for storecost and rewards existing in the first place then the rest becomes much simpler.
It seems the current belief is storecost is payment for service and reward is a subsidy on top of that to further motivate farmers (to maximize growth). This approach seems to imply certain properties like: all rewards eventually end up being distributed to users, payments are only distributed to farmers and never return to the network, reward should be issued at some particular rate, payment will go direct to farmers rather than shared etc.
I’m not really in favor of that idea of the economy (I can get behind it but to me it seems illogical).
A brief historical aside: Bitcoin does not use fee as payment for service. And it would be absurd to do that. A tx in block 605 would overall be stored for slightly longer than a tx in block 606, so should the earlier tx pay slightly more? No. This is not just saying ‘bitcoin does not work as fee for service’, it’s saying ‘bitcoin should not work as fee for service’. There is no way to know the future amount of service required to secure that tx so there’s no way to pay now for that future work (a debatable point for sure; to argue against myself we saw in another thread a 10x decrease in storage cost every 10 years means permanent storage always approaches 5x the initial annual cost… so sometimes we actually can estimate the ‘cost forever’ based on the ‘cost now’).
Transaction fees in bitcoin are only used to prioritize which transactions to commit to the network. This prioritization mechanism only gets used when the rate limit is active (ie more than 1 MB of txs per 10 minutes is happening). If there’s no stress and no need for a rate limit then all transactions are accepted.
We can debate why bitcoin may or may not be a good model for our situation, but I think it’s a good example for why tx fees even exist in the first place. Fees are a way to decide how to use limited network resources. Storecost is a prioritization mechanism. I’ve said in the past that storecost is a rate limit, but perhaps it’s more accurate to say storecost is a prioritization mechanism (that operates when a rate limit is active). So storecost should be extremely cheap if the network is not stressed (no need to rate limit or prioritize, let’s maximize growth and accept everything). But when the network becomes stressed then there should be some restrictions until the stress is relieved, and the restriction means there needs to be a way to decide what is accepted to the network and what isn’t. That’s why we have a storecost. It’s not a payment for service.
With that bit of ideology on the table, we can ask ‘why have rewards’? Can we have a successful network without rewards? (Likewise we should ask can we have a successful network without storecost but I think the previous paragraph demonstrates the need for storecost). It feels like we can’t go without rewards because if we have a storecost then we need a way to pay that storecost. The reward is what allows people to pay the storecost.
To me it makes sense that we want as many people to have access to rewards as possible so they can also pay the storecost (and other reasons but I’m just looking at the core of the logical reasons here). Not everyone is in a position to be rewarded early on (didn’t know about it, didn’t have resources available, didn’t understand it, ignored it, hated it, whatever reason). This means that rewards must be spread out over time if reward is going to be useful as a way for many people to pay their storecost. How much time should it be spread over? Hard to say! To argue against myself again, we should also consider there are other ways to get tokens than the reward mechanism (eg exchanges, gifting) so maybe focusing too much on the single core logical reason is not especially helpful?
But the point I’m trying to make is that reward is not an additional subsidy for providing a service. Reward is the way that data flow is opened up and improved. If storecost is a kind of ‘quality assurance process’ then reward acts as a kind of ‘conveyor belt flowing into that QA process’. We can probably simplify and say: rewards enable network growth. The network grows when useful new data arrives (reward facilitates the storecost for new data) and when new farmers arrive (reward motivates participation and permanence). I’ve said in the past that rewards are to ensure permanence, I still think that’s the main purpose of rewards, and treating rewards with that purpose implies something about how fast to issue them (permanence and growth are very closely related imo).
These are what I feel to be concrete aspects that can be taken further into a working mechanism. Measure stress. Respond to increased stress with storecost. Measure participation. Respond to negative changes in participation with rewards.
I feel an economy based on a paradigm of payment for service is too risky, too much safety margin required, too fragile, too rigid.
The priority for network activity might be 1. join/relocation GETs 2. client GETs 3. client PUTs. This is because node membership is critical to network stability and security so must happen first, client GET is the most popular and cheapest and newbie and public-facing and end-goal function of the network (data is only permanent if you can fetch it so fetching is the key function for determining permanence), client PUT is a one-time event so is not as time-critical as the other two and depletes spare resources so is the cause of stress. Storecost as payment for service means farmers would say PUT is the most important operation, which to me seems very backward to the majority of participants on the network.
I haven’t responded directly to any prior posts because I feel the conversation has been based on suboptimal economic assumptions. Just wanted to throw my perhaps minority perhaps unpopular perhaps unwelcome ideas in here because it feels in the spirit of a brainstorm
To be more concrete on what I feel about the rate of new coins arriving, it depends on measuring and responding to participation rates.
To me the best way to do that is using a deterministic cache to measure the degree of redundancy (allowing any amount of redundancy, minimum 8 copies, but no upper limit on cached copies). Set a strict minimum redundancy (eg 8 copies), then target some higher redundancy than that (eg 15 copies) as the point where reward expenditure pays out from network wallets at the same rate that storecost expenditure comes into network wallets. Variation from this break-even point workload leads to higher or lower reward rates.
Yes, that would be wrong indeed. The payment to farmers is really to ensure the network has enough resource to handle the data.
It’s interesting when folk say to us, store data forever, so pay once store forever, you are crazy, but that is exactly what bitcoin does. Still, its data is limited (really) to currency transactions. (there is some space for small bits of data etc.).
So if we take data (and assume we have DBC, so no currency transaction data, except perhaps a spent bank) our storecost is similar to a bitcoin transactin fee. It’s what the network requires you to pay to handle stress (as you say).
Just as higher transactions hopefully encourage more miners to help with bitcoin stress with us the same happens with farmers (earners ). Like bitcoin, we don’t want them to go away too much and we want the resource (hashpower or storage) to continually increase along with the data, over time.
I wonder, perhaps it’s more like a constant balance, it tips both ways to encourage new resource or not encourage it, perhaps even discourage it. That is from an earners perspective, but from a client perspective it’s cheap when not under stress and gets more expensive as it is stressed, so I can see that rate limit from the client side and from the earner side the reward/payment being more a business decision (like miners).
Perhaps it’s increasing rewards enables accelerated network growth but stable payments are a sign of a stable network (slow growth). (taking account of disks being cheaper over time etc.)
I Am not sure @mav if you mean rewards as in the 85% the network has to pay out or the normal client pays → earners get paid reward?
The balance of clients paying for resources is a bit unhinged in early days as the network supplements the client payments. So it looks like you can store say 1Gb for 1safecoin, but you only think that because the network paid an extra 1 safecoin to the earner (from that 85/%), so the balance is wrong there (IMO).
Just to remind you that inflation should not be considered only in the context of 1 closed system. Our Safe Network will exist (most likely) in a world with many Safe Networks that will rely on different economic models to attract earners. Inflation is our tool with which we will be able to compete with other networks on an economic basis.
I find the idea of rapidly dispersing the supply interesting, but I also see that there would be a massive negative reaction from many who have been waiting for launch to see a return on investments that such a change threatens to postpone or erase.
What if the compromise is that a reduced amount of Safe Network Tokens are minted thus countering the effect of the flood? (think of it as a burn… but they never existed)
Does the network really require 4.3 billion tokens?
I think perhaps, just maybe if the correct balance is struck everyone remains happy and the tokens could be set free rapidly without a mob setting off for Scotland.
This is an interesting concept. Here is another interesting concept. The block reward in the Bitcoin network is actually used to pay a racket. Why racketeering? Because the only ones who can attack the Bitcoin network are the farmers, because only they have the equipment for the SHA-256 algorithm.
So if we actually pay for protection, what would be the analogy in the Safe Network? Protection from whom? I think it’s from other Safe networks.
@dirvine Have you considered a network that is greedy with a mind/personality of it’s own? An integral economic player? What I mean is something like this:
- In the beginning the network is a child, it wants to grow as fast as it can. It has a large trust fund given to it by its parents (85% of total supply) to buy resources and stimulate its own growth. For example, it wants to maximize PUTs to get plumped up full of data so keeps the prices low for end-user uploads; at the same time it gives more than adequate rewards to node operators to keep them happy and cooperative with their resource offers to store that data.
- At some point, the network has paid out a large portion of its reserve (~50%-75% of total) and like a drunk college kid on holiday it realizes, " wtf I’m almost out of money!". The difference between PUT costs to end-users and GET rewards to operators begins to balance.
- Next, the Network realizes it’s own mortality. The net payouts from its savings/trust fund have slowed but it is still on track to go bankrupt. It needs to start earning income for itself. It does this by minimizing how much it pays to farmers, but pays them just enough to keep them from leaving. At the same time, it needs to maximize what it charges end-users until the prices just barely begin to impact the rate of uploads or make them leave. Luckily it does so just in time to not go broke, the Network has now paid out 90 to 95% of total supply.
- The effect of step 3 is that the Network is now thinking like a proper adult. It now maintains it’s own income and expenses, it saves where it can and builds up a rainy day fund for life’s unexpected disasters like a solar flare or maybe an EMP that knocks out the northern hemisphere’s electric grid for a year. It also has resources with which it initiate new objectives or projects such as Homomorphic Computation features. The network grows its reserves back to 25% to 50% of total. Since its parents taught it to be fair to humans, it never wants to own more than 51% of total supply.
- Something unexpected happens, the Network has a mid-life crisis and needs to spend a lot of funds, FAST, to survive or maintain its ego. Maybe there is another network on the prowl taking node operators, maybe humans got bored and decide to raise chickens instead of being node operators. Something will always happen, and the Network uses what it has to buy its way out of the predicament.
- The Network is almost broke now (>99% paid out), but it has regained sanity. The humans might have helped it a little by using their funds to manage the situation, maybe not. The humans are fickle so the Network must repeat steps 3 through 6. Maybe it is older and wiser now, perhaps it has a better idea of how to maintain itself further into the future with more stability and grace. Maybe the humans are a little nicer and more pleasant to interact with too… maybe.
We need focus on smooth start and to attract new people as much as possible. Bigger means more safe, more content, better token economy.
To ensure that I think it is worth to consider to maximise reward to 10 or more than each put, so every new user will be able to farm some tokens to play with in few days.( Even when it is risky.)
To compare with Bitcoin, miners got 8 times more for each block than today.
There was concept to use Healty Multiplayer fixed to total tokens already in circulation. Which is going down to 0 when 100% is near. And even 99,999% can be possible.
BTW. who is going to buy Fil to use their network in this early stage? It is quite cheap, but not prooven technology to store there sensitive data.
When I use the word reward as a noun/verb I mean the amount/event that contributes to the earnings of a farmer.
For rfc0057 I consider ‘reward’ to refer to ‘earning 2x storecost triggered by PUT’.
For rfc0012 I consider ‘reward’ to refer to ‘earning X safecoin triggered by GET’.
Always with the unspoken disclaimer ‘portioned by age / work / etc’.
It seems to me this topic is considering cashflow in a fairly direct relation like:
Storecost from uploader → Section elders agree on distribution to nodes → Pay node wallets (recorded now transferred later)
I am hoping for a more indirect way like:
Storecost from uploader → Pay into section wallet → General turbulence over time → Nodes earn from work related events (both upload and non-upload) paid from section wallet (recorded now transferred later).
So I see the section wallet as a kind of ‘buffer zone’ for tokens, sometimes increasing if a lot is uploaded, sometimes decreasing if a lot of new resources are needed. The different incoming and outgoing purposes of the section wallet are certainly related; it feels like in this topic the relation is mainly seen as a direct relation (uploading directly creates a payment to nodes), but in my view it’s better to think of it for the purpose of the thought experiment as an indirect relation (uploading facilitates payment to nodes but not directly from the upload itself).
Why is indirect better? We can make the indirect relation behave in a direct way if it’s appropriate to do that, but we cannot go the other way and make a direct relation behave in an indirect way. I don’t mind if whatever happens ends up looking like a direct payment, but I feel it would be a mistake to deliberately design reward flows in a direct and rigid way if a more flexible way is available. I would not want to do YAGNI (You Ain’t Gonna Need It), but this does not feel like one of those situations to me.
I guess most people would be happy with a single function
distribute_upload_fee_to_adults. I would prefer to see it as two functions
send_reward_from_section_wallet_to_adults. If we end up choosing to trigger the second function at the time of uploading we get the same effect as the single function, and that’s ok. But if we choose to trigger the second function when something else happens, we have an easy way to accommodate that behavior. The quantity for ‘upload fee’ and ‘reward’ is more easily decoupled if we want that (as a single function it’s hard to see it as anything other than closely coupled). My point is the flexibility of two functions seems essential for the thought experiment, even if in code we may not end up using that exact flexible structure.
Looking further at how I conceptualize network stress.
Storecost addresses the immediate symptoms of network stress (reducing upload rate; like taking paracetamol for a headache), reward addresses the longer term underlying solution to network stress (increasing resources; like hydrating, eating healthy food, staying fit, stretching and strengthening etc to prevent future headaches, these take time).
Uploads being the source of reward is contradictory in this way of thinking. Upload is the headache, and reward is the source of sustainability, so to link them with ‘reward on upload’ we kinda say ‘you must have a headache to be sustainable’. Maybe this is our form of hendoku iyaku?
But I want to extend the definition of stress. Stress is currently seen only as ‘too much upload leading to not enough storage space’. But stress could also include ‘too little amount of reward leading to not enough new resources’. If there’s not enough reward then it may be difficult to get more resources when needed, and this adds stress to the network.
If all tokens are in the hands of users it’s up to the uploaders to fix the problem of ‘too little amount of reward’.
If I see the storecost rising I would deduce the network is running low on storage, and I have only two choices, both seem poor:
- reduce or stop uploading while the network recovers from the stress, but that means the nodes are not being rewarded and may leave the network
- continue or increase uploading so the nodes get rewarded and are motivated to remain here but add to the stress
I feel like sections always having some reward on hand is a useful feature for addressing the underlying reason for stress. It’s been said by others that the section having too many tokens is a risk (I agree) but it seems to me there’s also a risk if the section has too few tokens.
I prefer to see storecost used to manage the rate of new data, and rewards used separately to manage the rate of new storage. Using storecost to manage new storage seems strange to me.
I fear if I write too much I will overstate my case. I’m not especially against the rfc0057 type economy with rewards directly connected to PUTs, I think it would work ok. But I do feel it would be a shame to exclude the idea of separating storecost / reward. Separating the two really creates a lot of additional space in the brainstorm.
I always held the impression that the two would be decoupled ( storecost / rewards ).
Not sure why or when I conceived that idea though, its been a long trek.
I think you are correct in thinking they should be separate, even if some is essentially paid out immediately.
It may be seen as a risk having a section with funds , but IMHO if we can’t securely guard those funds, we failed rather spectacularly.
I agree @mav I have 2 overriding things in my mind and current focus.
- SImplicity and data consistency. So initially going for as simple as possible and with as many consistency guarantees as possible.
- Remove networks ability to change anything to do with user data (including wallets etc.).
2 is more subtle, but with users data, we have a strong design I think. So all data mutations are signed by client/owner (we are hopefully removing the word client from our code, it’s just keys.
So kinda like
OwnerAUthority or a policy on the data allows some key(s) to mutate.
NetworkAuthorityis relegated to a notary function only. So it can noterise data changes, but not carry them out. This allows data to be published at any stage and also prevents folk form rewriting their own history (where a client could publish different content to alter history, causing conflicts and all the resolution we would need there).
This is all to let you know where my head is, so not 100% related to this convo but hopefully helps you see where I am coming from. BTW this is a valuable session to have on rewards, much appreciated and I think we can find a great solution.
Is there this still capability style? I hope so because it seemed such a bonus when this shifted and so much of Jim’s excellent UX design followed from this and I think depends on it.
Have any of the recent changes impacted on the capabilities of the Safe capability approach?
No need to go into great detail, just no, or maybe but xyz or, yes and we’re working on doing pqr etc
There is, at least in LSEQ, it’s the policy part. We are looking at Map doing the same now. I have not been so involved in the policy work, @bochaco really lead the way here, but I am 100% behind the capability-based design. At the moment I am trying to clear up Authorities and get that part really concrete. Then getting strong guarnatees on data consistency (that’s going well) and finally the capablitities “model”. The reason for this path (for me) is to ensure we know the “rules” of data changes that are crypto secure and guaranteed consistent. Then we see what we can do with capabliities given those constraints.
I feel that way we don’t fall into traps of “oh this would be nice, oh great let’s add this part, it does not look too complex” etc.
tl-dr Yes capabilities, but my focus is on getting the “rules” of data manipulation very clear to all of us and force us to work within those. So if we need more complexity we need to go back and confirm the new mutation type we want is secure and consistent, if that makes sense?
Long thread, many thoughts…
As was written somewhere above, distributing coins too fast will lead to high inflation, hurt current coin owners and it will lower trust in the project. Distributing coins too slow will slow down growth of the network and posibly create risk of being overtaken by faster growing copy.
I think coin distribution should not be time based. During the years of development, I saw the effort to not have the need of time in the network and think we should follow that also with coin distribution.
When I try to imagine state of the network 1 year or 3 years from launch, it is allmost imposible, but when I try to imagine network with 100000 users or XY PB of data stored, that gives at least somethng to work with.
So my proposal is base the speed of releasing coins on some set of network size rules or milestones. Completely ignore the time factor, because In this equation I feel time is the hardest variable to estimate.
This is very true, it shoudl be based on (if anything) uptake for the network or resource requirements and that is influenced by so many factors. Time is just a kludgy guess at best and ignores (or worse folk think they consider) those factors.
This issue of speed of distribution of the networks wallet is a bit more subtle. So if we imagine there was only tokens in the hands of users then it is simpler. So folk pay, farmers receive etc.That is a demand/supply balance. However the networks bag, upsets that balance in some ways that I feel are not always positive.
There may be a way to consider it a bit different @mav is poking about there are well.
Way back at the start I was planning the network wallet would pay for those who could not afford it. OF course proving that is hard, but things like flattening human equality in terms of ability to pay can be nice. We try with farmers being cheap to run and hopefully earning for those folk, so not all one sided,
Anyway, all random thoughts at this stage But I agree with your main point, time is irrelevant here as something to code into an algorithm and perhaps even as a thing to measure, unless we can look back in time and say, hey that took X days.
Is this a concern about a section getting compromised? In the case of farming rewards, isn’t the security of a the transfer mechanism between the clientwallet->networkwallet and networkwallet->nodewallet fundamentally secure with the at2-dbc-bst approach? I’ve always considered having the network as an intermediary within the network economic model a genius part of the design. It would be a shame to see it go. It’s not entirely clear if this is what you are in fact proposing though…