No. There is a lot more wealth than the yearly budget of the government. The USA has 10% of annual budget held in gold reserves. Bill gates alone has what 50 billion. Remember the yearly budget comes from taxing increases in wealth and increase in total wealth is greater than the budget. And the world’s wealth, while mostly held in the hands of the rich, is still held by the population at large and the governments only work with a portion of it.
In 2014 the Global World Product GWP was 77,000,000,000,000 and increasing at around 10+% a year Gross world product - Wikipedia And held wealth is more than this.
Agreed. For instance a nano could buy 10^28 PUTs if things went really crazy
But wouldn’t it bring down the complexity in the core if we just use u128 as the sc and PUTs type? There would be no need for a second PUTs-account, no need for all the RPCs to manage PUTs. And all of that for just the cost of a few bytes more, 16 bytes instead of 8. API-wise we just expose nanos, maybe exposing smaller units in the future.
There will be thousands of sections, so we can’t not store the PUTs count in each section. That would dilute all your PUTs all over the network. So we need a central counter for PUTs, we would end up with a similar infrastructure to the normal SC accounting (maybe minus the tx queue)?
No need. Its a message back to the section handling your account.
I expect that is still quicker and less work than sending a message back to the section handling your account to do a safe coin transaction which then sends a message to the actual section holding the coin balance and then do the transaction.
The distinction between Good Node and Full Node is binary. Maybe it gets smoothed out over an entire network, but it could also give instability.
It would be better to replace Good Nodes and Full Nodes with a single value for % filled. I know the metrics on available space is the crux. (And part of another discussion)
Additionally, farmed coin (balances) of entire network doesn’t seem too complicated to know. Couldn’t there be a continuous pulse, a recursive request repeated between all neighbouring sections, where the total balance of each section is included, (and signed).
An approximate value for data storage available and used for each section, could be included there as well.
This could then be used in the farming algorithm.
Scaling frequency of the pulse would be one matter, also how deeply recursive it needs to be. Probably not very deep at all, before we have e 100% of sections having the data very close to network average.
Going only by the single section’s data will give that a few sections on either end of the normal distribution generate extreme values.
Because even though data will be distributed randomly in the network, it will not be evenly distributed, and so it does not prevent huge differences between some sections occurring.
Even if the neighbors metrics sharing is not something that is desired, I would like to see some analysis on what consequences the occurrence of sections with huge differences in generated values give, and how it is planned to be handled. (Or shown how it would not occur at all in the first place).
(I have read this RFC quickly but still feel I know practically nothing.) Assuming that safenet turns out to be unique without alternative, what would happen if Safenetwork farmers and developers decide to perpetually hoard SafeCoin beyond their own storage needs as a store of value instead of building up a 401k, i.e. supply would continue to be reduced, and if that would be faster than the reduction of cost of storage. Would that be the worst-case scenario for demand for divisibility?
Yeah, and actually the supply will be reducing, because certainly some Safecoin owners die without leaving keys to anyone. Is there any way to get a grip of the time frame when the coin loss by death of owner becomes significant?
A few tens of thousands of years IMO … with life extension biotech well underway now, I can conceive that humans will stop dying naturally within a century … that’s leaves accidental death - and I’ve seen statistical estimates that if you take away natural death (aging-related) then people would average 9000 years.
Technology isn’t static in any case and even if Safecoin were to become the top crypto and top form of money in the world within 30 years … within 50-80 years if not much sooner we will have something superior to the Safe Network (Safe 2.0!) that will incorporate all of the existing Safe Network data at the time and scale even better.
It’s another topic, but we would need a mechanism to move all data from a SAFE Network 1.0 to 2.0, without user intervention. Once that exists it will indeed buy us time to address many difficult open questions incl. divisibility.
Such a major upgrade could be needed much sooner than once in 30 years. Perhaps as soon as a vulnerability or major design issue is identified.
Yet, there is no upgrade RFC. (Why not??) At very least we should have hooks in place to do a centralized orchestrated by MaidSafe.
Upgrades are definitely being considered, but not needed for alpha 3 & 4
Expect a RFC in due course.
But to do a major upgrade “in place” can be done in 2 stages or more if needed by using version conditional code and/or having the vaults do the upgrade of the data stored. This way a multi-stage upgrade can be done to facilitate a major overhaul of the workings
In the typical OSS project, upgrades come second and that’s ok. However, in this case I feel it should perhaps come first?
This is because we are dealing with a store of value (SafeCoin of which the value needs to be preserved) and the core promise of perpetual storage and access to information.
In addition, a clean upgrade process could help to avoid having to solve all problems at once. It is a way to break down the problem SAFE Network needs to solve into smaller ones. However, I admit, I am not sure how difficult the problem of upgrades is relative all the other problems it could buy us time for.
I think that it is reasonable to say that a complete rework of the code so it is essentially a different network would require a planed upgrade that can only be specified once its known what the specs are of the reworked network.
For normal/typical upgrades then expect the RFC to be release sometime in due course. It is not being ignored and is planned
It would be great if the compute aspect could be made independent of certain core data storage/access aspects, to avoid a “forklift upgrade” to add functions like that.
I hope that an extremely minimalistic core of SAFE Network can be defined, that will have a chance to last 30 years. For instance, a very bare minimum for perpetual data preservation, and for providing perpetual access to it, based on not too complex SafeCoin-based incentive schemes that are preferrably mathematically proven.
Quotes are the first mention of PUTs by each individual and meant as a ping, not necessarily quoting for any specific meaning in the content of each quote.
Do accounts still have PUT balance? Are safecoins recycled to purchase PUT balance, or is payment for uploading now directly done with safecoin? Seems like PUT balance was originally in rfc-0012 because there was no divisibility so some extra precision was needed, but with divisibility introduced why would we need a second PUT balance system for managing upload payments?
RFC-0057 makes no mention of PUT balance, nor of how resources are purchased, so it’s ambiguous how PUT is paid for. I assumed (maybe incorrectly) the PUT balance was removed by the combination of divisibility and accounts-as-balances.
Maybe this quote from the Farm Reward Calculation section is what caused me to think payment is now directly in safecoin:
“When a client pays to store or mutate data, the payment will be immediately be divided amongst farmers.”
This doesn’t sound like a second PUT balance is being used for uploading.
Is this bolded part true? Would be interested to see you expand these thoughts, because to me it seems that both actions would require an equal amount of work. That seems like one of the big promises of data and network security, ie same for all data on the network (to my understanding). I’m just not sure about whether managing PUT balance is less work than updating a safecoin balance so would be glad to hear more about this.
You are right @neo we have internal pre-rfcs in place for node restarts and also upgrades as well as @Jean-Philippe 's earlier post on some thinking there. So it is not being ignored. The push right now is a minimum feature complete (data/safecoin) network first. We will get that in Fleming/Maxwell and then we will have a much clearer picture of what we are upgrading and how. Right now it would be a bit of a stopper for us. There are a couple of bits that are similar, such as the serialisation scheme, we currently use a flexible scheme, but perhaps not the fastest or future proof. We use it as we can iterate ideas quickly and again when the get the min feature set and some tests we would expect to switch to a more future proof and efficient serialisation (like flatbuffers or similar).
So both of these parts are waiting in the wings for this min feature set data & safecoin network.
You are leaving out violent death. And even though the possibility of that has been lowering drastically over the centuries, it is not guaranteed that this trend continues, especially if population growth accelerates because lack of natural death.
But you are probably right about how technology will advance, and how this problem may be left behind by updating the whole network.
Still, in theory at least, we don’t have stable amount of available coins, but a constantly diminishing resource. I’m not sure if hoarding + dying rich in a private submarine can have any effect short term.
I thought of PUTs as the equivalent of GAS in Ethereum, basically giving a measurement of how much work each operation was for the network. But now that you mention it, there are 2 key differences that may make it unnecessary:
1 - no block chain, so no gas limit for blocks (the equivalent of Bitcoin’s block size limit).
2 - no scripting, so no gas limit on individual transactions (ie. SAFE network knows in advance how much work each transaction will be)
Another reason why we shouldn’t is it gives an unfair advantage to the rich, such as large corporations.
How? Heres one example:
The future: The Safenetwork has now taken over 90+% of all “equivalent internet” usage of today. If a large storage manufacturer such as Samsung were to have a fire at their latest high-tech manufacturing plant. There would be an immediate spike and demand for PUTs as “large tech company” pre-pay for 36+ months worth of PUTs. Causing an artificial strain on the network.
If PUTs don’t exist, the only way to make use of storage space on the network is to:
Create useful data you want to store.
Upload that data to the network.
Even if overtime there was a strain on the network, the increase cost to store is shared among all its users, its a more natural “smoothed” trend.
Also from a human, non-tech perspective do we really want to explain using the Safenetwork in this way. (during the early/adoption phase).
Step 1. Sign up to a Safenetwork payment gateway
Step 2. Use credit card to buy Safecoin - (Explain Safecoin)
Step 3. (use Safecoin/fountain) to create Safenetwork account
Step 4. Transfer Safecoin to Safenetwork account wallet
Step 5. Buy PUTs <----- At this point you’ll need to explain PUTs.
As users won’t be able to transfer/sell them. People could accidentally buy far more than they actually need. Then start posting “I want my money back” because they didn’t understand what they were doing.
can have any effect short term.