I maybe mix things up with the data problem. With data every MB has to be signed, until possible fix, is it similar with coins or is moving example 19000 coins at once, one transaction and one signing round?
Would love more info on this
Balance is now a number held in the wallet (or is it still token balance)
The transfer just specifies the amount.
Or have a contract attached showing the payment was made for that chunk. So instead of section sig there we have clients pay a storage cost. They apply that to the chunk and send to network for storage. We keep the “contract” with the data as it’s proof it was paid for. So no more need for client pay, sign at data section and sign again at store section and distribute funds. What I am keen on is an additional mint rule. so the contract to store is basically 1st closest, 2nd closest to data name. If you are such a node you collect these up and re-issue to yourself. So the min recognises, "oh you are X closest, so here is your payment.
That is much slicker and means client don’t need to query wallet addresses to pay etc. It’s all part of the contract.
Simpler UX “steps”
- Encrypting data
- Paying for storage
- Sending data + payment (contract) to store on network
That was we can see the steps and it’s nice and clean.
A typical day at MAIDSAFE: “Did you know we are building freedom and security for everyone, and a brand new internet?”
Me: Yes, I’m very excited about this…
MAIDSAFE: “oh, and just a side note, we’re also offering scalable micro-transactions at over 50000 tps, which means we’re going to save the planet on an economic level; including all the poor countries that everyone else ignores, and make any other crypto project feel like they should take their ball, and go home.
Thanks for blowing my mind once again, when I least expected it.
Can you start the upload a huge file, of say many terabytes, prepay and finish the upload for that price, even if the network’s price for data changes numerous times while you upload?
Yes you can and that’s safe as you have a contract to store that. So the network says, it’s paid and cool, we will store that if we ever see it. This also allows data republish nice and simply as well.
For my reference, David. Is the cost of each byte of data being put on the network being calculated depending on file size? I can imagine that for example 1 GB could be $1 to store, but 10 GB could be $11 at the same time. I’m aware these numbers are probably nowhere near accurate, but lets say there will be a time where putting data on the network is cheap. You wouldn’t want people to reserve 500 TB worth of data storage all at the current cheap price, right?
Yes, that’s true, however you cannot do that. The contract for that data has it’s name in it. That means you can only store the exact bit of data you paid for. As name == content hash then there is no way to game the system.
For mutable data we still need to work out details, but again I am keen those are all 32 byte fields and you pay per field. That keeps cost even and also allows the contract to state which field you are paying for. So again no gaming there either.
So contract is per PUT, though you can in effect pay for all the chunks (every PUT) in a large file before the file itself is being delivered to the storage nodes along with payment?
So it is a limited kind of prepayment, but only for a known set of chunks rather than arbitrary storage for chunk that are not yet known. Neat!
Yes that’s it. The contract is a Dbc really but on with a reason field. We can expand on reasons and then different reasons will take a different flow when minting. So this could be quite powerful. For data it’s really simple.
Some will call it smart contract but we are keeping it simple for now. However later when it’s up and running I imagine a lot of different reason fields for many purposes:
- Buy some cpu power
- Enclose or label an NFT type digital asset (so a receipt)
- Different currencies
- OMNI → SNT (this one is quite easy)
- Erc20 → SNT (ditto)
- Allow re-issue (mint) only when X happens (x must be measurable)
And so on, it’s quite flexible.
Simple Safe Contracts are better than “Smart” Contracts.
You guys really hit gold with this with regard to the new payment method and all it entails. It’s what we’ve all been hoping for.
Below are quotes from a while back that made sense to me.
Nice one @Sascha and @mav too of course plus @bochaco nailed it as well “So contract is per PUT, though you can in effect pay for all the chunks (every PUT) in a large file before the file itself is being delivered to the storage nodes along with payment?”
Does the node fullness counter go up after payment or after storage?
To ask the same thing a different way, do chunks paid-for-but-not-stored count toward node fullness?
To ask the same thing a different way again, could I pay for many TB of data, not store any of it yet, and get sections to split even with them not storing the data. The nodes would be full-by-the-accounting but not full-by-the-data-on-disk? (Not interested in the motive here, just the possibility)
I think payment must be the trigger for incrementing node consumption, not the upload. Otherwise the network could ‘owe’ a lot of data that was paid for but not uploaded and it may not have reserved enough space to store it.
How does this payment mechanism affect shuffling of chunks during membership change? How is ‘this chunk was paid but never uploaded’ different from ‘this chunk has been lost by the node’? I guess if at least one node has kept the chunk then we expect all others to have it too, but if none have it then we say ‘the uploader never gave it to us’.
This payment mechanism is interesting because it makes us really think ‘what is the purpose of storecost’. Is it a fee for service? Is it a rate limit? Is it an immediate motivation for current farmers? Is it a type of savings to motivate future farmers in times of stress? Is it a kind of prioritization mechanism? Is it a spam prevention? It’s probably a bit of all of these, but sometimes more one than the other… how will varying network conditions affect storecost and uploader behavior? This is not about the calculation of storecost, it’s about the delay between payment to workload and how that can affect behavior of nodes and uploaders.
It’s a neat mechanism that naturally allows data recovery. I’m excited to see how it performs in the real world.
Good point atm it’s after storage.
[EDIT Many folk talk about pay now for Put and game the system and perhaps we imagine pay now store later is bad, but I feel it’s the opposite. Storage/cpu and bandwidth all get cheaper and I imagine cost per Put will decrease and never increase. However we will see but the design is the price seeking thing here is how much do you need paid to keep your computer on. So resources definitely get cheaper. The problem would only happen if the FIAT value of safecoin dropped I suppose?]
This is OK though, as data is stored, paid earlier or now it would make no difference. The sections would split. Unless an attack was I am gonna pay for millions of Tb and try to store all at once and if I am successful then I have paid for nothing No seriously I don’t think this is an issue, but still thinking of edge cases. I can not see any right now.
Should have no affect.
The person looking for the chunk should know if they uploaded it. Unless you mean somebody uploads pointers (metadata) but not the data. In that case the network would error,
NoData but is that a problem?
Yes, I agree.
I would say it’s only this, but good points. Worth probing some more.
For sure. I think there will be many times nodes will try upload missing but paid for data. A neat question here is, should a node that uploads paid for but missing data be rewarded? That’s interesting! (original uploader has to upload the contract to store, which means the contract was fulfilled, so later uploads to missing data but the fulfilled contract is detectable.)
Hey @dirvine was it Peter Todd that many years ago came to Troon to look at the network code and made the claim what Maidsafe wanted to do could not be achieved?
Curious of exactly who that was and a quote of what he said. I know he was a big Bitcoin supporter or dev.
I thought it would be funny to say “first they ignore you, then they laugh at you, then they fear you, then they join you” in the process of this real world context.
Think I found it.
He seems mostly concerned over the “google attack” but I thought his criticism was more broad and dismissive. He seemed to be pretty neggy about it quite a lot so I might be missing what I think I’m remembering.
He came over under the false pretence of a job interview, arranged by the mastercoin CEO. When he arrived (and we paid for the flight) he said he was here to audit us for the “bitcoin wizards”. It was all bizarre stuff at the time as he did not want technical detail and said freenet could do it all Then he went away and wrote some squabble about the speed of light? All in all a weird experience. IIRC I had said something like I am not here to be audited by you and he threatened to tell the wizards.
I felt is would be best to consult Dumbeldor and check that one of his experiments had not escaped
Na seriously it was all a joke visit by some dev thinking he was black-ops CIA. He was not a character any of us took to, but it takes all kinds. He does offer something I suppose, but seems to live in a world I don’t.
Having you pay for his ticket under false pretenses is a shiesty move. That’s enough to get on my shit list.
A neat question here is, should a node that uploads paid for but missing data be rewarded?
Maybe this could be an attack vector. Malware installed on another computer could report the data that the user is uploading, throttle their upload speed, and allow the attacker’s account to upload it first for a reward.