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?”
8 Likes
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.
14 Likes
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.)
11 Likes
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.
2 Likes
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.
27 Likes
Having you pay for his ticket under false pretenses is a shiesty move. That’s enough to get on my shit list.
18 Likes
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.
1 Like
Funny you should mention that - although no way to tell where he stands in that power game.
Throughout history whenever some disruptive tech appears that threatens large interests, it attracts all types of “weird” attention. Disrupt the disruptors is a standard response with lametable real world consequences. I would file all those MaidSafe Tax problems and fear posts under this category, it fits the MO.
4 Likes
There is something in the air… Tonight? Tomorrow?
2 Likes
Once cli gets updated I am going to get my party hat on. That is my incoming test canary right now.
2 Likes
I’m expecting a really really exciting testnet!
4 Likes
I think it is just a PR or two in routing…
Yeah, a lot of activity, but no sign of T6 announcement Tonight.
Lets pray for Thursday.
3 Likes
We might get lucky this week but better to get it right
1 Like
I disagree. In my opinion it is better to get just something that is a step away from previous problems. No need to get anything very slick. I am hooked at waiting the next episode after the cliffhanger we got last Friday:
Without testnet it would feel like moving back to the “no timelines” zone. Well, of course there are not timelines at the moment, too, but you know what I mean.
But this is just my opinion, and it is not about the actual technical development, it’s just about what kind of narrative would feel better. Cliffhangers should be resolved soon enough 
And I am confident they will.
9 Likes
cli and latest node are now playing together again.
11 Likes
sn_testnet_tool being updated…
6 Likes
im getting this…
willie@gagarin:~/projects/maidsafe/sn_dbc_mint$ safe update
Checking target-arch... x86_64-unknown-linux-musl
Checking current version... v0.26.0
Checking latest released version... v0.27.0
New release found! v0.26.0 --> v0.27.0
New release is *NOT* compatible
Error: Error performing update: ReleaseError: No asset found for target: `x86_64-unknown-linux-musl`
Is safe 0.26.0 compatible with sn_node 0.46.3 now?
0.27.0 is compatible with 0.46.3
josh@pc1:~$ safe node bin-version
sn_node 0.46.3
josh@pc1:~$ safe -V
sn_cli 0.27.0
AHH sorry @southside I did not see that you were in sn_dbc_mint there… not sure about that.
2 Likes
Thatsa OK - thats just the directory I was in at the time
I can confirm that unzipping sn_cli-0.27.0-x86_64-unknown-linux-musl.zip from https://github.com/maidsafe/sn_cli/releases/tag/v0.27.0 into ~/.safe/cli works just fine
Im going old-skool with my terminal
Thank you
3 Likes