I really think there’s a misunderstanding here. I’m on the side of ensuring efficient bandwidth usage. Not attacking you, truly. Try to take a step back and see what I’m saying. Storing data is what causes bandwidth usage. If the stored data is deleted every time, it’ll have to be called and stored again => more bandwidth usage. But if the stored data is retained, it’ll mean less bandwidth usage.
The bandwidth issues you’re seeing right now is likely caused by other bugs, which must be dealt with. Deleting data will only make bandwidth usage worse.
Lol, no. Please see above for my suggestion to address Neo’s concern.
We need to get this network out of theoreticals and put something real out there in the hands of people to test against and help make better. That won’t happen with endless design changes.
The network needs to work and be robust or there is no network. If that can be done without design changes good, but whatever is needed is needed, and that might include more work on the design IDK.
Agreed. So what’s the current issue that’s bringing up talks of redesign? It’s @neo’s concern over xor address retention. All I’m asking is that we do a thorough analysis of that attack and weigh it’s risks very the benefits of retaining the xor address. Also, critically, are there mitigations that could be implemented?
Intuitively, I personally don’t see that potential attack as being worth losing the benefits of xor address retention (and its attendant implications on bandwidth efficiency). And I think it could be mitigated (e.g., increasing replicates to 8 or 10; storage is cheap, bandwidth isn’t), especially for more critical datatypes like spend/money data.
It you guys are over-egging talk of a “redesign”. It’s more just about an implementation of how the node-manager handles node restarts, not some rearchitecture of the Network.
One moment - would this mean that the attack vector does still exist if one does not use the node manager for it and does the management by hand?
… At least some network side code must be affected because somehow right now the network accepts nodes with ‘self chosen’ xor addresses back…? (even after days as we saw with an upgrade that resulted in nodes being not really connected… Many weeks back)
For the first time in Beta testing,I can’t get the nodes to work. After running the command:
safenode-manager upgrade --interval 10000
only the first node started and the others updated but did not start, I waited a few minutes and tried to restart them but to no avail.
So I tried typing the update command again but then a message appears that the file contains a virus:
PS C:\Users\gggg> safenode-manager upgrade --interval 10000
╔═══════════════════════════════╗
║ Upgrade Safenode Services ║
╚═══════════════════════════════╝
Retrieving latest version of safenode...
Latest version is 0.110.0
Using cached safenode version 0.110.0...
Download completed: C:\ProgramData\safenode-manager\downloads\safenode.exe
Error:
0: The operation was not successful because the file contains a virus or potentially unwanted software. (os error 225)
Location:
sn_node_manager\src\helpers.rs:279
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
Currently all nodes are updated but won’t boot, anyone have any advice?
Time to let your computer compute, not waste 30% of its resources mitigating the effects of 40 years of poor design and criminals.
remember AV software is 100% wasted overhead - but very profitable. I wonder how much AV vendors are forced to kick back to Microsoft?
