It depends on the window size. A pure TCP ACK packet is going to be 64 bytes (the minimum ethernet frame size). If you were to ACK every incoming packet, that would then mean the incoming packets have to be at least 3804 bytes, which puts them in jumbo frames territory, which are unlikely to work over the Internet.
However, you only need to send an ACK when the TCP window is full, not for every incoming packet. If the TCP window is set at 64k, for example, and assuming an MSS of 1460, then you can receive a total of ~66K bytes for each ACK you send ((64k/1460)*1500, assuming the provider counts every byte in every packet, not just the TCP payload). The window size can actually scale much higher though, up to 1GB. So, in principle, yes, you can comfortably get this much download speed with only this much upload speed.
Of course, this would only apply for downloading huge files with a very efficient implementation. If you are using HTTP to download lots of small resources, your uplink would be saturated with GETs far before you saturate your downlink.
However, you only need to send an ACK when the TCP window is full, not for every incoming packet. If the TCP window is set at 64k, for example, and assuming an MSS of 1460, then you can receive a total of ~66K bytes for each ACK you send ((64k/1460)*1500, assuming the provider counts every byte in every packet, not just the TCP payload). The window size can actually scale much higher though, up to 1GB. So, in principle, yes, you can comfortably get this much download speed with only this much upload speed.
Of course, this would only apply for downloading huge files with a very efficient implementation. If you are using HTTP to download lots of small resources, your uplink would be saturated with GETs far before you saturate your downlink.