I'm just quoting two examples of building conspiracy theories on the lack of understanding of the ISP technology.
Save the end of the world prophesies for the speculation subforum please.
We could try a proof of troll system, keep randomly saying the same thing over and over and every time a new variation is found its a new block
Noticed the same with the ISP's, Ireland's really lax on internet rights and there's lots of weird stuff going on, outages followed by slowdowns on certain sites, everything loading fine except images taking ages, that kind of thing. Obvious what's going on, lots of sites seem to be going offline lately, nothing big but a lot crypto related.
Have to get back onto my ISP again now, hadn't realised they'd blocked 8333 again. Second time they've done that, will have to tunnel out to a VPS. That's what the dumbasses don't get, that which doesn't kill us makes us stronger.
Anyone can name an ISP that blocks outgoing TCP/IP connections to port 8333? And where such a block isn't a voluntary one (some sort "Internet safety" option) and the unblocking isn't a self-service "turn it off" checkbox?
How about incoming TCP/IP connections to port 8333? And where such a block can be lifted and isn't a technical restriction stemming from the use of CG-NAT or DS-Lite?
If and ISP blocked a particular port, one would get zero connections on it.
It would not surprise me at all to have a max cons set by and ISP. That would explain the why one has difficulty. Each connection uses network resources in a router (yours and your ISP's respectively.)
This is what drives me nuts about ignorant people making simplistic calculations of capability based on the download speeds (which are artifacts of a marketing department usually anyway.) Ya, you might be able to get some decent percentage of a pipe in use but only by using multiple streams, and that is particularly the case with TCP on a wan. Anyone who has tried to SCP a large file can tell you this. Nobody is going to be thrilled about Joe Sixpack using a thousand sockets, and crappy consumer grade routers will have difficulty. Probably max-cons is set by the ISP to throttle those trying to do torrents. Same trick here. This certainly illustrates the point I'm making about being at the mercy of network infrastructure providers.
IIRC it's even less than that by now. Anyway, I don't have to guess about why this is. It's obviously because for some bizarre reason Satoshi didn't choose to reward transfer nodes in his implementation. Why I have no idea. It's one of the strongest observations supporting the hypothesis that Bitcoin was designed to fail (or at least become centralized and under control.) Not that I believe this to be true, but it is one of the many hypothesis that I continue to hold open. Probably he just ran out of time and patience. If he was ignornant enough to not forsee the difficulties with the block size hard-fork then he may also have imagined that transfer node rewards were something that could be tacked on later.
It would not surprise me at all to have a max cons set by and ISP. That would explain the why one has difficulty. Each connection uses network resources in a router (yours and your ISP's respectively.)
This is what drives me nuts about ignorant people making simplistic calculations of capability based on the download speeds (which are artifacts of a marketing department usually anyway.) Ya, you might be able to get some decent percentage of a pipe in use but only by using multiple streams, and that is particularly the case with TCP on a wan. Anyone who has tried to SCP a large file can tell you this. Nobody is going to be thrilled about Joe Sixpack using a thousand sockets, and crappy consumer grade routers will have difficulty. Probably max-cons is set by the ISP to throttle those trying to do torrents. Same trick here. This certainly illustrates the point I'm making about being at the mercy of network infrastructure providers.
Why do we average less than 7k nodes worldwide at any given time? https://getaddr.bitnodes.io/
IIRC it's even less than that by now. Anyway, I don't have to guess about why this is. It's obviously because for some bizarre reason Satoshi didn't choose to reward transfer nodes in his implementation. Why I have no idea. It's one of the strongest observations supporting the hypothesis that Bitcoin was designed to fail (or at least become centralized and under control.) Not that I believe this to be true, but it is one of the many hypothesis that I continue to hold open. Probably he just ran out of time and patience. If he was ignornant enough to not forsee the difficulties with the block size hard-fork then he may also have imagined that transfer node rewards were something that could be tacked on later.
This user is currently ignored.
Save the end of the world prophesies for the speculation subforum please.
We could try a proof of troll system, keep randomly saying the same thing over and over and every time a new variation is found its a new block
Noticed the same with the ISP's, Ireland's really lax on internet rights and there's lots of weird stuff going on, outages followed by slowdowns on certain sites, everything loading fine except images taking ages, that kind of thing. Obvious what's going on, lots of sites seem to be going offline lately, nothing big but a lot crypto related.
Have to get back onto my ISP again now, hadn't realised they'd blocked 8333 again. Second time they've done that, will have to tunnel out to a VPS. That's what the dumbasses don't get, that which doesn't kill us makes us stronger.
Anyone can name an ISP that blocks outgoing TCP/IP connections to port 8333? And where such a block isn't a voluntary one (some sort "Internet safety" option) and the unblocking isn't a self-service "turn it off" checkbox?
How about incoming TCP/IP connections to port 8333? And where such a block can be lifted and isn't a technical restriction stemming from the use of CG-NAT or DS-Lite?