A quick question to my technically literate friends
- as far as I understand the network does not support prepayment for uploading data, ie. I can’t buy PUTs in advance and use them later. Is my understanding correct?
A quick question to my technically literate friends
To my knowledge you are correct, it’s not possible to buy PUTs in advance and use them later.
However there is this to consider: “The network on restart pays folk to re-publish any missing network data. (Network data is data that has been signed by a network section in the past and that is provable).” (source)
It’s not a big leap in logic to see that possibly we could maybe treat upload as separate to payment (ie all data is always considered missing). Whether separating these two aspects is a good idea or not… I’m not sure. It depends on what we consider the purpose of storecost to be.
If I understand you correctly, you think such functionality will be possible? I want to buy storage on the network and distribute it. I don’t want to give Safecoin directly, because people will either sell it on an exchange or keep it without using it, and if they only get storage space, they will have to use it…
I like your thinking…
It will be possible to pay for an upload on behalf of someone else, which would achieve the same effect.
This seems convoluted but this process is identical to replacing ‘Dimitar public goods wallet’ with ‘Sammys hardware wallet’. So it will definitely be possible for one person to pay for anothers uploads, ie give away upload without directly giving away safecoin.
But whether you classify this as ‘prepaid PUTs’ … probably not.
Thanks for the reply. I don’t know if this solution can be used to create several thousand accounts for different people, but if a better solution doesn’t appear it’s better than nothing…
There will always be ways to pay for the uploads of others. The particular wrapping on it is probably not too important.
Jim Collinson has done lots of work on this, I can’t find the exact post I want but this is one of his posts that discusses it: much of the underlying workings to make this happen still are being made to make the narrower invite creation/management process.
Yeah, that’s correct. It would be quite a fundamental reworking of the way the Network operates to do this.
Notwithstanding any more hacky/fudgey ways of doing this of course—for example, zeroing out a large mutable data that you’d come back and edit again later.
Yeah, as above you can’t really do this without a hack. Which would have potential security implications for both parties that you would have to be very careful of.
What we have worked on is purchasing invites for other people. That’s a pre-baked onramp to the Network, with everything you need to get going: a magiclink/QR that kickstarts everything, funded by just enough Safecoin to get you on the Network, let buy a SafeID, set some preferences, send a few messages etc.
Behind it all though, it is just a wallet with a little wallet with some Safecoin it, which would be topped-up/debited by your wallet to keep it at the appropriate amount. Someone could if they wanted and knew what they were doing, hoover out the Safecoin and go spend it on what they wanted.
So it’s really just a handy mechanism to help friends get up and running easily, without the need to run a Vault, or for an exchange to sell Invite for the Network that would be quick and effective to use.
It’s not a way to distribute pre-paid GBs of storage.
Yes, the network doesn’t allow to pay in advance the cost of a future put.
But I guess that some people will want to bet on the futur price of a PUT and that some exchanges or some kind of market places will allow to trade these bets.
In such market places you can buy a PUT to be delivered at the date you expect to upload the data.
A PUT cannot be physically delivered but the equivalent value in safecoins can be delivered which allow to issue the data upload.
Disclaimer : I am not a trader and I am sorry if all this doesn’t make any sense.
So that everyone is up to date here, with Digital Secure Broadcast and AT2/crdt types, we can split this up.
I will try and explain.
A client sends a store request (let’s say a payment) to the Elders who will store the data. They send back their signature_share (parts of the section signature). So now the client has data that the network hash authorised and she can upload this. However we don’t care when she uploads it.
So in this way, a client could pre-pay to upload specific data but not (atm) any data to be later applied.
So this part is possible with the current tools we have.
Two issues there, what if the client then loses the data and did not upload it? Also this is specific data (the network has not seen yet, although it agreed to save X bytes with a specific hash (so blinded)).
However, at this stage, we have no pre-payed generic Put’s.
If people would hoard generic puts and sell them/use them when prices are high this would work against the economics of the network (little free space => high storage cost, a lot of free space => lower storage cost) and possibly endanger the whole network…?
Imho there shouldn’t be a possibility for this behaviour…
Prepaying for PUTs is like buying gold - you prove before you need storage space that you believe that when you need it there will still be a network.
If there is a way to measure this encapsulated trust in the future of Safe this will be a huge tool for growth.
If the network has a way of knowing that some have prepaid for a storage, it can refer to this prepayment as if it has already used storage and allow more farmers to join accordingly.
Ie prepaid PUTs are the opposite of keeping Safecoin for speculation and not for use.
Booking a PUT when the prices are low could help stabilize prices and rationalize use. It could be particularly useful to help smooth the demand timeline and make it a bit more in line with the longer supply response. The trick would be to avoid speculative hoarding/some other feedback loop that could destabilize the network’s sense of itself. I think that if puts were non-transferable and could only be redeemed against actual data storage, then I don’t see any of the bad happening.
Big However, however… Implementing blank PUTs may also have other complexities … you’d have a license to store, but you wouldn’t know which section the store would end up in, so there would be no way for that section to know that the space was taken. Could also add attack vectors (e.g. prebuy lots of space, then construct data to end up in the same section, potentially overfilling/taking it offline?)
From how many physical connections can this one user store data?
(if not planning with targeted attacks I would agree but without really reserving/making sure the pre-purchased storage space is being reflected in current storage prices+already available I still think it’s an attack angle)
That’s a great capability. Re:
Too bad for the client if so. Only the client can recover the lost data, and introducing some kind of refund would be an attack surface.