4 ms·
This is one of life's great mysteries. Given the hosting provider for 2b2t, we know pretty much for a fact that the packet spam from 2018 and 2019 (before I kne
by leijurv 5y ago
This is one of life's great mysteries. Given the hosting provider for 2b2t, we know pretty much for a fact that the packet spam from 2018 and 2019 (before I knew about the project ;)) would have cost tens of thousands of dollars in bandwidth overages per month. Yet, he never added a packet limiter until an unrelated exploit could cause other clients to crash due to spamming an offhand swap sound effect. It took the exploit going fully public, plus another 36 hours or so, for it to actually get patched. ¯\_(ツ)_/¯
- goldenkey 5y agoHow does monetization work? Was the server host making hundreds of thousands of dollars? That makes the extra cost negligible.
- rebane2001 5y agoThe server's main income is priority queue. By default, if the server is full (it almost always is) you are placed in the "normal queue" and have to wait for other people to leave. This normal queue is often hundreds of people long, leading to wait times several hours long. For $20 a month you can purchase the priority queue, which skips the wait. A lot of people pay for this as it is the only way to comfortably play on the server, so it is quite the income.
- gwern 5y agoI see. Maybe they were just lazy, and since they didn't see anything obviously going wrong other than wasted bandwidth, let it go. Sort of like the NASA management in the Challenger report; as Feynman pointed out, the fact that the O-rings were eroding when they were not supposed to erode at all indicated that the models were simply wrong, and thus there was no guarantee of safety at all, as the "safety margins" were only margins if the models were right; but since no shuttle had visibly blown up yet... Cryptographic and anonymity and information leaks are particularly dangerous that way, because when they fail, they fail silently: a bad crypto scheme still encrypts and decrypts your emails, it just lets the enemy decrypt them too. I'm reminded of my work on darknet markets: DNMs often leaked their IP or other information because there are so many ways for Apache or Linux to do so by default, and when they do so, there's no visible error; the DNM will continue working exactly as intended, right up until the police kick in your door. Aside from being proactive about investigating anomalies, information leaks are very hard to defend against in general. Hard to see how you could reasonably block this bug without some fancy capability security implementation which would let you do something like require the client to produce a proof that it is in sight of a block and permitted to query its current status. (Then requesting arbitrary blocks would fail by default, and a patch which mistakenly gave everyone a global capability to let requests succeed would be impossible to write without knowing one was introducing a grave vulnerability.)