Hitbox Expansion using Rounding Errors

I can't tell if this is the funniest meme I've come across in this game or the most upsetting information I've had the displeasure of happening upon.

Basically, the long and short of it is that the size of your hitbox doesn't really get fact checked too often, and so by abusing weird rounding you can cause it to grow(or shrink) ever so slightly over time.

And I guess the long and longer of it:
Disclaimer I'm really in no position to explain this, I literally had to google what a float was for this video(I mean I knew they existed but what do you mean a "mantissa" that's just an old lady's name??).

Pretty much, your hitbox is defined as a minimum and a maximum coordinate on each axis. And when you move around, it calculates how far to move you in whatever axis, and then adds that distance to both your minimum and maximum on that axis. (Your actual position then gets set to the bottom center of this new hitbox).

It's just kind of assumed that since you're adding the same distance to both the min and max, the distance between them should stay the same. In fact, it only really resets your hitbox to default if you like. do something that updates your hitbox size(idk crouch/uncrouch/swim), or relog/similar. Mathematically it's a pretty fair assumption I suppose, but its also just not true when it comes to floats n stuff.

See floating point numbers only have so much precision, so its a given that adding numbers won't always give the perfect result. But as long as the precision is consistent there aren't any problems, since everything would be off by the same amount. But alas, the precision isn't consistent. Whenever the value passes over a power of two, the precision gets coarser and coarser(I think by half(?)).

So what I do in this video is go super far on the X axis, to the highest power of two accessible in a Minecraft world(2^24, or 16,777,216). By then standing on this coordinate, I can have my hitbox's minimum X coord on one side of the power of 2, and my maximum on the other side of it. Essentially this just means the coordinates of the two will have slightly mismatched precision levels. That way when I move around on the x axis, there's a chance one rounds it differently from the other. It's only the difference of like, one float value, but its still a difference. And it still leads to a net size gain in that axis(or size loss if the opposite happens).

From there I just did this for 1000 hours(technically only 33 but at 600tps), and came back to a hitbox ~0.12m larger!

Theoretically, if you could go way out past the world border, the effect would be even more emphasized as the precision decreased, but oh well. You can also technically do this closer to the world origin, but even out at 8192 the size change would be like 0.000000000001m, and take like a millennia to grow by 1m. It'd work for the other axes as well, including Y, but since you can't really go past y 256, you'll be stuck jumping for like half a million years to grow by 1m.

There could be ways to optimize this, again you're literally only changing your hitbox by the smallest possible value every tick, but it's miracle enough I managed to get a consistent setup for this.

I should also probably note that the server is much more strict about its hitbox sizes, almost constantly making sure they're the right size. So even though your hitbox is funky shaped here, the server probably still thinks it's 0.6x1.8x0.6. This can do some funny stuff in of itself, but I think this is what renders small hitboxes pretty useless. It just sounds the alarm or smthn and it resets. This also might mean this doesn't work for other entities, but I could just be making stuff up.

More silly than useful, but that's the finding(I say, as if there probably isn't some 4 person parkour community out there that's known this since 2013). I could honestly see this being useful for aligning yourself float precisely, but that's not really something you need to do too often, lol.