Yes, except we have people both setting and answering, so maybe harder to automate.
At first sight perhaps, but someone willing to put effort in and with money to spend can exclude others by swamping the network with nodes trying to join (what I referred to as spamming earlier). Very much like advertising, or media outlets manage to censor other voices and messages, because they can outspend them.
We need to be able to show the PK the CLI owns so we can then transfer more coins to it, we don’t have such a command yet on CLI but we’ll try to add it for very next CLI release so we can top it up its balance.
What’s happening there is that since you can transfer to either a Safe-URL or to a PK, it’s assuming cryptokid is not a URL but a PK, so it’s trying to decode it as a PK, and that’s why it works when you add the prefix safe://. I guess we can add a fall back there and try it as a URL if it fails to decode it as a PK.
Thanks @GeekOverdose , we’ll be investigating this further, I can reproduce it consistently.
Perfect example.
Media attention is affected by quality and personal taste. Some of it is just “better.” On top of that, money and connections with established people, all that counts. It makes for higher barriers to entry.
If it were purely random, the barriers to entry there would be lower. You might still get some people putting it a lot more effort, but the effort would count for less than it does now.
Which is all we’re after really I suppose, if it’s good enough.
I don’t know anything about the various types or the level of security they provide, but I’m sure people wouldn’t mind confirming they’re not a robot, or telling us how many bicycles are in the picture in order to join the queue!
I suspect it’s not as simple as that, but maybe @happybeing’s idea could be an improvement.
Has everyone updated their node?
A new version got released earlier today - presumably due to initial lessons learned since last night.
safe node update
and expect out put similar to below
willie@gagarin:~/projects/maidsafe/local_sites$ safe node update
Checking target-arch... x86_64-unknown-linux-musl
Checking current version... v0.35.1
Checking latest released version... v0.35.2
New release found! v0.35.1 --> v0.35.2
New release is compatible
sn_node release status:
* Current exe: "/home/willie/.safe/node/sn_node"
* New exe release: "sn_node-0.35.2-x86_64-unknown-linux-musl.tar.gz"
* New exe download url: "https://api.github.com/repos/maidsafe/sn_node/releases/assets/34712044"
The new release will be downloaded/extracted and the existing binary will be replaced.
Downloading...
[00:00:02] [========================================] 10.91MB/10.91MB (0s) Done
Extracting archive... Done
Replacing binary file... Done
Update status: '0.35.2'!
Node has been updated. Please restart.
I’m afraid not, keeping the barrier small without making spamming hard leaves us wide open to people with lots of money swamping the network and getting many more nodes because they can pay to inundate it with join requests. That’s potentially dangerous until the network is of a size where this isn’t effective.
Later I think you may be right, because the rewards will be smaller proportionally than in the early days. But getting a lot of nodes early on could bevery rewarding, and perhaps more importantly it could potentially lead to control of sections which is a serious problem because it could undermine the network itself.
The actual cost of doing a recaptcha is tiny though, even with the question setting (which recaptcha has a bit of), and it could still be gamed very easily through things like Mechanical Turk.
Also, I’m not sure simple proof of human should be a pre-requisite/the aim, it’s just not being malicious, and having a random spread, that’s the important bit, no?
What if you had a “proof of human” check for the first node under an “account” (or whatever you guys are calling the key combo) and then future ones are automatically added to the queue once the first node gets in and proves to be a good member?
If nothing else, this wastes an attacker’s time, and makes it difficult to run an effective attack.
Fair enough, makes sense that it’s too easy to game.
Was just thinking along the lines as someone pointed out above, that lessening the chances is good enough, rather than necessarily perfection.
Trouble I suppose is that when an attacker learns how to cheat a defence it becomes worthless, or worse than that if it’s slowing others down.
I’m seeing a Blob not found, so we’ll investigate this further @davidpbrown , thanks!
Not being malicious is a chief aim of node promotion and reward allocation but not necessarily queue selection. For queue selection, the proof of human requirement would have merit as it would reduce the likelihood of automated farming conglomerates monopolizing the network-join queue and would put “indies” on more level footing.
Would it be a good idea to separate the queue selection and resource discussions into a different thread?
I see some other folks have come across this error when trying to upload (my first upload by the way). I’ve tried creating some keys and adding coins but still no joy. I’ve checked the safe is unlocked. Any ideas?
SafeKey's current balance: 4294967295.000000000
user@user:~/safe$ safe files put ./to-upload2/ --recursive
Error: NetDataError: Failed to PUT Public Blob: Transfer(InsufficientBalance)
user@user:~/safe$
In case this helps a dev, I tried to upload a large file (1.8G Linux Mint ISO) and got an error:
me@sto:~$ time safe files put -r to-upload
[qp2p::connections] ERROR 2021-04-09T20:38:02.136313867 [/home/runner/.cargo/reg istry/src/github.com-1ecc6299db9ec823/qp2p-0.11.7/src/connections.rs:234] Failed reading from a uni-stream for peer 138.68.131.218:57691 with error: Failed to r ead expected number of message bytes: connection closed: timed out
FilesContainer created at: “safe://hyryyry97o6w8ssp5pmxhaqjzr6gxrem5q4m3tzxwzhso pfjhmmupa6q79wnra”
- to-upload
E to-upload/linuxmint-20.1-xfce-64bit.iso <NetDataError: Failed to PUT Public Blob: SelfEncryption(Generic(“Connection lost”))>real 66m39.299s
user 19m15.509s
sys 0m55.753s
The put comes from your self auth wallet balance. I’m guessing that wallet showing the 4.2B balance is a SafeKey combo you created and not your default?
Yes that’s right - do I need to add coins on creating a safe?
That was a discussion above. We don’t have the ability to get the XOR-URL or keys for our default credentials created during the self auth. They need to implement that so we can send funds to fill up the default balance.
Is deduplication in place in this testnet? Has anybody tried to upload same file twice? What happens? I may give it a shot tomorrow, now off to sleep!
user@user:~/safe$ safe keys balance
Checking balance of CLI's assigned keypair...
SafeKey's current balance: 777.000000000
That should be enough? I think something else must have failed. I’ll start again.
I get similar
willie@gagarin:~$ time safe files put ~/Downloads/0AuraLee.pdf
Error: NetDataError: Failed to PUT Public Blob: Transfer(InsufficientBalance)
real 0m27.689s
user 0m1.207s
sys 0m0.274s
willie@gagarin:~$ safe keys balance
Checking balance of CLI's assigned keypair...
SafeKey's current balance: 626.000000000
Its not like its a huge file
willie@gagarin:~$ ls -l ~/Downloads/0AuraLee.pdf
-rw-r–r-- 1 willie willie 52391 Jul 4 2015 /home/willie/Downloads/0AuraLee.pdf