3 byte files you mean?
In the current setup they will error out and should not be written at all.
Higher level apis (the account packet/ fs chat) will probably look to wrap un-self-encryptable data and encrypt it into the account packet or in another fashion.
So for now: errors (or encrypt yourself), later: everything handled via high level apis.
I think there’s a bug in the change then, either that or I can’t understand very simple code, because the minimum encryptable file size appears to have been changed to three bytes!
Edit:
Looks like I can still read code 
and that it’s not a bug, so my question is does the above affect the security of encryption for small files < 3 KB, because presumably that limit was in place for a reason. @mav?
was going to ask this exact question in the update!
Essentially in the end it seems that the limit was there to avoid us ending up with encrypted data + addresses that were bigger than the actual data.
So as long as we’re not concerned about that the limit can be lowered to something divisible by 3 (such is the nature of self-encryption that we do chunk 1 encrypts 2 encrypts 3 encrypts 1 ; or so… It’s not my realm of expertise), but basically we need 3 small things minimum!
Thanks Josh. When a node prices storage is it regardless of chunk size?
I’m guessing yes, ie same price per record whether 3 bytes or 1MB.
I think that’s the first post of yours I’ve ever fully understood 
Yes, KISS please. Size-dependent variable chunk pricing is a feature that should be left till after release - if it needs addressed at all. Lots of things are charged by the unit or part thereof and nobody moans too much.
yup.
More of the work is in the act of uploading any bytes rather than the limit of bytes. (Is my impression)
yep, also not forgetting work churning or retrieving is not much different between small&large chunks so there isn’t any or much reason to factor in differences to account for future work of nodes.
But imagine trying to have 1/1000 cost for say 100 byte chunks. LOL what is 1/1000 of 0.000000025 SNT again. (when 1MB chunk costs 25 nano SNT)
Dose this mean we are going to be back to UDP for the next testnet ?
We’re going to test it out and see what things are like at the moment aye.
Seems like most node operators are using VPS, so it should not really stymie participation on that front? (tell me if I’m wrong here!)
Don’t see why it would stop anyone iv already got my port forwards set up for TCP/UDP so ready to roll 
I don’t really remember why we changed to TCP, but I dont recall UDP be a problem for home node operators (such as myself) are you suggesting that it would be?
Also @joshuef could you hazard a guess as to what caused Neil not to be able to use safe wallet balance please.
Did the nodes die ? I wonder if they died mid-write? I’d be surprised if that happened for many many ndoes though 
I’d have to see some last logs from those nodes.
He would be in a better position to answer that but seems a grey area. A bit of a puzzle really.
@joshuef node appears to be doing something as the log files keep growing
Only thing that happend around that time was I installed vnstat and it restarted some services.
But if that was the cause I’d have expected it have wiped out all my machines
haven’t had a chance to scope this out, sorry. Was this one server only that’s had the issue though, is that right?
Do you know exactly when the file was corrupted perchance? +/- ?
From a look at NTracking I have two servers that had the issue where all the nodes have the wallet issue.
I’m thinking it’s not worth your time at the moment but I can keep an eye on if it happens again to any of my machines or anyone else’s it’ll be worth a look ?
here is the out put of trying to check the nodes balance
ubuntu@oracle:~/.local/share/safe/node/12D3KooWAmvt4zYW5fvLo39Pg26ft1sgtwJeby3hcxNKugMaCkSn/logs$ safe wallet balance --peer-id 12D3KooWAmvt4zYW5fvLo39Pg26ft1sgtwJeby3hcxNKugMaCkSn
Logging to directory: "/home/ubuntu/.local/share/safe/client/logs/log_2024-01-17_14-44-00"
Built with git version: 9be7e8d / main / 9be7e8d
Error:
0: I/O error: Could not read and deserialize wallet file after multiple attempts
1: Could not read and deserialize wallet file after multiple attempts
Location:
sn_cli/src/subcommands/wallet.rs:326
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
here is the log off that balance check if it is of any help
http://safe-logs.ddns.net/log_2024-01-17_14-44-00/
current log file for that node