Existing problems and the future of SIA
-
@bugger Sia can provided 3x redundancy encryption across a decentralized network- but cant mask an IP address of a host? hmmm
-
@DcyMatrix I think that @flibben has covered you. In the case of SIA theres no central server so the IPs should be encrypted with an algorithm that only the program knows of.
@flibben I don't bash the devs either, I'm sure they have poured their sweat and time into this project to make it what it is today. That being said, feedback is a must and current issues especially critical issues like these should be given attention and should be resolved as soon as possible.
@moorsc0de no **** :D exactly. I think that privacy means a lot for SIA and generally cryptocurrencies so an IP is like your real life home address. With a 100$ server and dns server scripts 1 person can attack the whole array of SIA's hosts' homes and render them uninhabitable/useless. That is even easier than a double spend 51% attack and more effective. It's only natural that privacy should be taken care of within SIA.
-
@bugger
I'm curious how effectively and for how long a $100 server could DoS-attack the current network of 600+ nodes...
And, believe me, if someone will want to attack the network, that someone will find out the list of nodes and corresponding IPs. If necessary, by modifying the source code, as it is opensource. An attacker with intentions does prepare the attack before carrying it out.
So, why unnecessary complicate things now?
Just remember, Sia is in early stage yet.
There will be much more hosts if/when the "product" matures and hosting turns somewhat profitable.
-
@reinisp With encrypted IPs an attacker would have to actually form contracts and buy storage to find the IP of the specific host he is using. This is incredibly time consuming, requires a lot of money and you don't know which host you'll end up using since you can't select. It may not even possible to find 50% of IPs this way.
As for the server, a 100$/month server can DDoS hundreds of GB per second with the right scripts. With vulnerable dns servers the server can amplify its power many many many times. Take a look here: https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification . Example: My server sends 1 GB worth of packets per second to thousands of different dns servers -> each dns server is requested to request information sending x200 times more the bandwidth sent to them -> 200 GB worth of packets requesting info from SIA hosts -> SIA hosts are overwhelmed and are unable to send the information requested by the dns servers on time while all their resources are trying their best to talk back to dns servers -> the more time passes the more responses SIA hosts have to give back to dns servers rendering their internet useless. Basically the server sends packets to vulnerable dns servers all over the world manipulating them to send even bigger packets to the targets so even with a 10$ server it is possible to put SIA off business forever. That's how bad the situation is.
Edit; Not to mention that a potential DDoS will generate hate for SIA since victims' internet will be unresponsive completely and they'll have to change their IPs if they have static.
-
With encrypted IPs an attacker would have to actually form contracts
How could the attacker form a contract if the hosts IP address is not known? Every renter needs the list of available hosts.
If the IPs are stored somewhere and handed out in encrypted form to "legitimate renters" only, it would be easier to attack the Host list serving server.And I doubt you can get a server for 100$ with available bandwith to "send 1 GB worth of packets per second to thousands of different dns servers". Anyway, that type of attack is effective against a limited count of servers, but ineffective against a globally distributed network with thousands of hosts.
-
@reinisp said in Existing problems and the future of SIA:
With encrypted IPs an attacker would have to actually form contracts
How could the attacker form a contract if the hosts IP address is not known? Every renter needs the list of available hosts.
If the IPs are stored somewhere and handed out in encrypted form to "legitimate renters" only, it would be easier to attack the Host list serving server.And I doubt you can get a server for 100$ with available bandwith to "send 1 GB worth of packets per second to thousands of different dns servers". Anyway, that type of attack is effective against a limited count of servers, but ineffective against a globally distributed network with thousands of hosts.
It's not that the IPs are not known, they are but only by the software. Encrypted IPs are used in torrents for example so an outsider can never know your IP. Now when someone uploads files to a host he can easily track the IP he is interacting with. Now I think that I missed is that if you upload a few files they are going to go to 30 hosts. So that's 30 IPs per contract.
I'm not involved in DDoSing years now so go to hackforums and play the 'buyer'. Ask someone to display a test DDoS to you and give us a screenshot with the bolume of attack in GB/s. You need like 100-200$ one time for scripts and servers if you cant find them yourself and a server with 1 GB / 1000 mbps internet. It doesn't cost much neither it requires time. You can even have someone from hf to set you up a server with everything you need to DDoS. You don't even need to know coding or anything.
Finally, you said that it can't work vs a global distributed network. At some point in the past Microsoft, Facebook, Google, Youtube, Amazon and every major company you can imagine has been successfully DDoSed and we are talking about the biggest clouds ever. Even half of the internet was disrupted during a DDoS attack.You think that SIA home user hosts with 100 mbp/s will survive? Inform yourself and Do the math.
-
For your concern of the software continually writing to disc, is this happening while running as a host or while just running the software & uploading?
This would somewhat concern me as well given I'm running on solid state all over & this would also worry me to some degree
-
@intheclouds someone here: https://dm.reddit.com/r/siacoin/comments/6mcatn/existing_problems_and_the_future_of_sia/
said
The more contracts are concluded by host ==> the more data that is written: Each second few files (related to the concluded contracts) are rewritten, and their their sizes are proportional to number of already signed contracts and amount of reversed space on disk.
So for a good active node with bunch of contracts it can be not just 10Gb/day buy hundreds gigabytes per day of useless/redundant data writing
so as a host
and another
Yes, other programs write to disk. None of mine write more than a GB per day, so they're negligible for this discussion.
At a link above, someone measured about 10GB a day with active contracts. Do you have a source or a measurement suggesting that it's 10x that?
At 100GB a day, my SSD life is limited to around 7 years. Again, that's over what I consider to be the useful life of a drive, so it doesn't bother me.
Absolutely this is a big bug that must be fixed -- I'm not arguing that it's inconsequential! But it's not killing my drive to the point that I feel I should shut it down until they roll out a fix whenever they get around to this particular issue in their endlessly expanding to do list.
They are aware of the bug and will fix it. We have no ETA at this point.
-
This post is deleted!
-
@flibben It's a false sense of security in my opinion, if I have a renter with some secret algo that encrypts the ips it contacts, it still need to make the actual connection. Where to upload the data? You can just observe the outgoing traffic and see the ip's connected too. If you go through a gateway of any kind, that becomes a point of failure as well. But instead of having DDOS'ed 1 server, you take down the gateway, it might be 100's of servers impacted instead of just one. Keeping it as decentralized as possible is the best way to keep the data and the network up. Creating single points of targets for DDOS is sure to bring it all to a halt.
There is also no one that says you're not allowed to setup a VPN or reverse proxy as a hoster to hide your true IP.
It is very early days of Sia, so maybe a solution will be found, I could think of IPv6 might hold the answer.
-
@DcyMatrix Why did you delete your first post? As for the encrypted IPs the only thing that changes is the format of the IP. Instead of 123.456.789 (IPv4) or :7a07:1234:556c:777:f363:8899:tre7:9q21 (IPv6) you'll see something like ABC123deF456gHIk789LmN. That's all. No gateway or any centralized middle-man server. That doesn't mean that your IP wont be able to make connections with hosts' IPs. The software is able to convert the encrypted IP back to normal with its algorithm.
Now, when you upload files, your files are spread across 30 hosts. So if you scan the connections you'll get 30 IPs.
-
@bugger Deleted my first post because I wanted to reply to flibben not you, so my post appeared to reply to you, but only flibben was the one I mentioned in the post itself :P
But I still stand by my remark I think it's a false sense of security. I don't see anything stopping anyone from simply scanning all the Ipv4 space for Sia hosts. So again, you think your 'hidden' when you're really not hidden at all. Hence the false sense of security.
-
@bugger @reinisp With encrypted IPs an attacker would have to actually form contracts and buy storage to find the IP of the specific host he is using. This is incredibly time consuming, requires a lot of money and you don't know which host you'll end up using since you can't select. It may not even possible to find 50% of IPs this way.
--- This is actually something I could see implemented via the blockchain, if a renter announce on the blockchain it wants to form contracts, then the Sia hosters reading the chain all the time, will be able to 'bid on the contract' and then even encrypt the answer to the renter only. Sounds like a great idea :-) But still would make your hosts vulnerable to a ipv4 scan of the internet for Sia hosts. Unless the hosts reply to the renter would include a 'port knock' to signal the host it's a real renter contacting you :D
-
@DcyMatrix
I still can't imagine how (without centralization) could a node with the intention to rent some storage get the IP needed for contacting host regarding the offered contract details. Even if it is encoded into the blockchain itself, the blockchain is publicly available and every node is able to decrypt the contents. The attacker just needs to run the node and let it sync the blockchain...if a renter announce on the blockchain it wants to form contracts, then the Sia hosters reading the chain all the time, will be able to 'bid on the contract'
That would turn the renter into the target for DDoSing...
-
@DcyMatrix @reinisp anything is better than this: https://siahub.info/ really. The current situation is like "I let my house door open, because even if I lock it, it is still possible to bypass it. Oh and by the way, here's where I live: https://siahub.info/. "
-
@reinisp There are other ideas emerging as we speak to deliver these types of services.... stay tuned
-
@reinisp Public / Private key encryption, the information is Encrypted using the public key of the recipient. Then only the private key will be able to unlock it.
It's the same thing that keeps all cryptocurrencies safe. If the information is on the blockchain, you will not be able to see who the recipient is, since everyone will have the same data (blockchain). Only the recipient (wallet owner) in this case the renter will be able to get anything meaningful out of the data since he/she holds the private key necessary to decrypt the information, in this case the information would be the IP & a 'port knock' code. To tell the renter the correct sequence of ports to send a syn package too, used to announce to the host it's a contract holder asking to upload or download data.All cryptocurrencies are built using the Public / Private key method. The 'private key' is just your wallet, the public key would be a receiving address of the crypto.
DcyMatrix: if a renter announce on the blockchain it wants to form contracts, then the Sia hosters reading the chain all the time, will be able to 'bid >on the contract'"
reinisp >"That would turn the renter into the target for DDoSing..."
All the information the renter would have to put on the blockchain would be the intent to rent, if a host picks up the contract, the host (and everybody else) does not know anything about the renter except the public key used to encrypt a reply to the renter. So the rest of the peers on the chain can not see anything meaningful about either the renter or the hoster.
This is all just brainstorming on my behalf, but Someone please do correct me if I am wrong in any of this :D
-
@DcyMatrix
I do not get it...
a renter puts intention into the blockchain. Somehow, without knowing where other nodes are (their IP addresses). Let it be so.
Hosts receive the blockchain and see there is a renter wanting something. What should a host do to contact the renter of whom the address is not known? How to send a proposal to the renter so the renter can decide which hosts offer acceptable conditions? You only get the best offers if you receive them from all, so all hosts need to know how to contact the new and unknown renter...
And the new renter does not know where there is a host, because host addresses are "hidden". Who will tell the renter the password to decipher the hosts addresses?
Just try to write down a step by step procedure, how the network would prevent an attacker to use the official (opensource) client to get the addresses of all hosts.- hosts have their copy of blockchain.
- renter installs the client and downloads blockchain. Let's assume it happens by magic (not knowing from where the client should download the blockchain).
What next? - Renter puts an announcement together with an ID (something for encription) into the blockchain. Again, somehow by magic, broadcasting, without knowing the nearest mining node.
- Host (every host on the network) notices the renting intention, and puts his proposal with unique ID into the blockchain, marked with the ID of renters announce?
- Every renter who has put an intention announce looks for proposals and discards without looking into all with "wrong ID"? After reading all proposals puts intention to contact host (or own IP so the host can contact) together with the proposals ID?
...
The keys could technically be exchanged over the blockchain as a medium. But remember, there are 10 minutes between the blocks. So how long would the contract creation last? And how would that blow the blockchain up? if there were thousands of hosts and even more renters?
I think the possible gains are not worth the drawbacks.
There is another type of possible attack which would even profit from this- use a network of, say 40-50 rogue hosts, getting a lot of contracts by offering very low prices and after getting some data uploaded to them, change the price sharply initiating a massive renegotiation round...
-
Does working as intended include 41k SC out of my wallet in a single TX for a 250MB upload when I have a 7.5K SC allocation/allowance set?
I am a noob, true but I have a decade of software testing experience and this does not seem good enough for an even an Alpha build to me.
-
Torrents do use encrypted IP's. They use encrypted data in the packets.
You do realize your home router doesn't understand "encrypted IPs."
You need to work within the confines of the network structure of the actual internet. All information sent and received uses the IP stack. (See the OSI model)
Besides, as Sia is open source, there's nothing stopping someone from making a modification to expose the IP's of hosts. Or even just using wireshark on the network adapter to see them.
The whole point of decentralization/p2p (peer to peer) is to send the the data DIRECTLY to the other peer. Of which, you need their actual Internet accessible IP.
I've pointed out how easy a simple DoS attack against people hosting at home was before. Damn near a year ago. it was met with the response that the hosts need to be responsible for taking precautions against attacks.
