Also you must pay the nodes you upload to, not random nodes like emissions.
No they are not, they are chosen by the client based on their data to upload and the responses from the chosen 7 nodes and then picking 3 of those. To implement what you suggest is to change the fundamental principle of nodes being paid to receive data to random nodes getting payments whether they stored anything at all.
And of course you forget that you magnify the auditing responsibilities of the foundation from just managing emissions and keeping audit trail to auditing every single payment for storage and keeping audit trail for the regulators and/or tax
I haven’t dug into the code for how this works, but assuming this is true, it would make direct payment for storage relatively straightforward. I’m assuming the nodes broadcast their receive address in some way to facilitate ANT payments right now too?
The process is that the client requests quotes from the 7 closest nodes to the record’s xor address. Then the highest and lowest quotes are thrown out and the median is chosen and 3 of the 5 nodes left are paid and the record uploaded to them
So while the client does the choosing of the nodes to upload to they must obey rules otherwise the nodes will most likely not accept the record.
A bit of give and take there in the choosing. Follow the rules of the network and choose 3 of the closest nodes.
This is supplied along with the quote metrics in response to the request for quote
Excellent! Thanks for the explanation. It rings a bell now that you detail it!
So, in theory the quote process could remain largely unchanged, with the payments still being made directly, but natively via a change of ownership?
That certainly sounds relatively straightforward.
I was also wondering about how to setup zero cost networks (e.g. for internal/corporate usage). It sounds like zero quotes or possibly disabling quotes and nodes checking for payments may not be a huge lift either. I have a client that may be interested in that, where GDPR is an issue for them (i.e. regional data storage).
And still what is the problem here? Simply pay to existing emission address of foundation holding those 240 millions of and that are here for reward. Or create new address owned by foundation, that is paid, and once every 24 hours it is drained and included into daily rewards. There is nothing to audit different than the emission pool. Redistribution is the same. The idea is, that we already have this emission system, centralized by foundation. it will stay here, so the trick is to use it more and solve the bottleneck problem of per chunk payments.
Why? Really i mean it. Why? We just need to know the 7 quotes, pick 5 of them to calculate correctly cost. But at that moment, it does not matter much whether I as a client pay them directly via erc20 or use credit. The cost mechanism works, clients are still motivated by dual payment system to give me correct quotes in hope to receive erc20 direct payment and if they don’t receive money directly what changes? more than 99.9% of income is from emissions anyway. Would they leave? No. Would they build their own code to quote always maximum to avoid upload? Maybe few, but the reality is the reward for that hassle is so little, especially now and with current massive emission reward dominance. Once the network is actually more full or more advanced payment option like native currency emerge, this can be removed.
If you have separate address owned by foundation and it collects receipt payments there and uses everything there every 24 hours to increase funds for emissions, what is the hassle?
Spending of those coins is not different from spending from emission pool. Receiving them, yes, this is a tax question that needs to be clarified. What does this mean from tax point of view.
For tax purposes usually average daily price is used, if it was not a sale on an exchange. So even if it is tax event, if you redistribute the payments very same day with emissions it evens out to 0. Auditing is simple, 1 address collecting all of them, no other type of transactions.
Edit: When thinking about it again, I agree that not paying the nodes directly introduces a flaw, that logically would not exist if there were a native currency and in long run will cause problems if proper solution does not emerge. It is an attempt to fix broken erc20 design by another broken design.
wouldn’t it be better for them to keep some form of coins to control uploads to the network in case a disgruntled employee dished out access details and gave people free uploads for life to there network ?
Many words, it is not just keeping track of prices. It is tracking all assets coming in and going out since it is a foundation and not a business.
It is caused by using emissions mechanism, so then the foundation is receiving ANT for every upload done and having to keep an audit trail available for auditors to audit their accounts and assets and provide a report to the authorities each year.
Personally i do not want the foundation knowing and tracking all my uploads done so it can be auditable
If it is an organisation then it would be easy enough to have nodes limit the IP ranges they can talk to. That solves the issue to one where normal company credentials apply. EG for remote access
If you read my proposal fully, you would know that the proof of purchase of receipt is private, so only closed group responsible of chunk upload can see it. Upload history is public chunk, but it does not contain reference to the actual transaction on blockchain. It cointains transactons about uploads, but no timestamps, and encrypted ids of chunks. So it tells nothing and at any moment only closed group responsible for chunk upload knows my entereum transaction Id and they can’t know other chunks ids. Impossible to track what you uploaded.
Edit: To clarify it, foundation or anyone in the world has absolutelly 0 knowledge what was that paid erc20 transaction for. That transaction cointains only hash, and noone knows what that hash means.
You missed the point. Because of the requirements of knowing how and why of received assets (ie ANT) then the foundation has to be able to make available to the auditors that audit their accounts each year, the details of all ANT received. IE in a report that can be generated for the auditors is the fact this account paid the foundation’s emission account x ANT.
So its taken from simple blockchain transaction to a smart contract to one where the ANT transfer is governed by the regulators. I am not talking of tracking chunks.
So no doing it to the emissions system is a nightmare to do for the foundation and for the users.
Also the payment for uploads is not an emissions function at all, it is not to be government style taking in money and distributing it to accounts it decides. In this case a random payment to nodes that may not even have a single record stored yet.
It does not matter whether you direct payments or payments to global pool, you are always suspicious that you did some autonomi uploads.It is on blockhain, does not matter where the transaction went. In both cases they don’t know what you uploaded.
I already wrote in previous post, that I accept the regulation argument. That is a problem, that I can’t quantify.
Yes exactly, I never said anything different. What I said was, that in the end it is all random on average. Even If I pay for direct upload, the node takes money and leaves and in the end remaining nodes have to take care of that chunk. So on average in long run it does not matter whether I pay them directly or by emission the rewards act randomly. It is random chance that the node online will get uploaded paid chunk. It is random whether he gets emission reward…
The pricing algorithm wants to average out the load between all nodes. Direct payment makes sense only for one reason, and it is to get fair 7 quotes, to have local price discovery based on how full nodes are.
It’s actually not for employees, but for remote devices to pool their local storage. This pooled storage can then be used to store various data, taking advantage of the resiliency, allowing new devices to join/leave, etc.
In short, making better use of the devices, rather than having to do something similar in the cloud.
There could be a pool of tokens that get recycled, but it would essentially be a permissioned/private network, so no real need for them. They just add complexity in this use case, tbh.
Fwiw, it could lead in reinvestment into the network and tooling too. I wouldn’t see it as competition as they simply couldn’t use autonomi due to its permissionless nature. It could be handy in these sort of use cases though.
In autonomi documentation https://docs.autonomi.com/developers/how-to-guides/payments
there is this section:
Pre-paid operations using a receipt → Work in progress..
that is all. So Autonomi in official docs have a plan for prepaid option. This means, there have to be a mechanism in the network, where a client sends bunch of money, that are somehow redistributed. This involves all the tax and accounting issues you mentioned. And by definition involves not paying nodes directly for each chunk upload.
So my proposal is quite easy implementation for planned receipt. If there were not this section in the documents, I would not try to push it. I just wanted to share easy idea how to implement what team wants to implement. And I don’t see a way how to do it without central redistribution and not paying nodes directly for chunks. For direct payments we would need a native token and decentralized emissions. But with a native token, we would not need receipts.
So until Autonomi officially rejects this planned receipt, I would like to keep my proposal open, since it is exactly that what is achievable with current technology.
I’d be keen to understand how fast it would be, relative to depending on Arbitrum. Clearly, there would still be a lot of quoting going on, but making the payments should be relatively fast.
I’ve not studied quote time vs payment time, but assuming the latter is substant, currently.
Maybe divisibility is a non issue (for the network) and we simply shouldn’t mix the topics of ‘money’ and ‘payment for upload/download’ ?
A coin could still only have one owner but a field that represents the currently available remaining balance of this one coin..? On upload they get eaten up… Lowest value always wins…
Maybe a mind fart… Then there wouldn’t be enough coin to include humanity (which ofc could be resolved through a one time split…)
Maybe it would even be a feature to have the safecoin not being a proper currency - but the network enabling data types that are..? (spam protection due to small fee)
I suppose you could have a mutable field, much like the counter, which represent this.
Arguably, the counter already chips away at the value of a mutable, by decreasing the number of mutations left (despite it being silly huge and not meaningful).
For data payments, having a smaller range (than counter) could make it more appropriate.
Obviously, for partial payments between individuals, it wouldn’t help much though. Maybe you are onto something with the idea though!
If the network would support deducting at one end and adding up to a different coin even that might be on the table… But that would need to be carefully investigated to not defeat the counter based reduction of value..
… That would have a lot similarity to DBCs with reissued coin (at same address)…
