In 1.9 the Hitboxbug has been fixed, and everything on this page has been fixed. This page is written for 1.8 versions.
Hitboxbug[]
In Minecraft, at any given point in time, all blocks with the same block ID have the same hitbox. The hitbox of the blocks of a certain block ID can however change multiple times within the same game tick.
The hitbox of all blocks of a certain block ID will update when one of the following things happens:
-A player looks at the block
-An entity collides with the block
(More stuff needs to be added here)
For example, if a player looks an upside-down stone slab, all stone slabs in the world will get the hitbox of an upside-down stone slab. If the player later looks at a normal stone slab, all stone slab will get the hitbox of a normal stone slab. Most of the time, this does not influence the game in any way, since every entity, that needs to interact with the hitbox of a block will normally update the hitbox before interacting with it, but if the code forgets to update the hitbox before using it the hitboxbug can be exploited.
Testian Item Elevator[]
If a item is inside a block with a full cube hitbox, and the 4 blocks around it in the x and z direction also have a full cube hitbox, then the item goes up. However, the hitboxes of the 4 surrounding blocks don´t get updated before they´re checked. Therefore the hitboxbug can be exploited here. One exploitation looks like this:
.
If the item moves into the fence, that is connected at all 4 sides, the item will go up.
.
.
This works in the following way:
When the item first gets into the fence, that is connected at one side, the hitboxes of all fences will get updated, so they have an incomplete hitbox. This allows the item to enter the second fence, without any problems, even though the second fence is supposed to have a full block hitbox.
.
.
.
Once the item enters the second fence, the hitboxes of all fences will get update, so they have a full hitbox. Now the item is inside a block with a full hitbox, and the 4 surrounding blocks also have a full hitbox. Therefore the item will go up. The item will not get spit out to the left, since the fence on the left has a full hitbox,.
Wireless redstone[]
A common exploit of the hitboxbug is survival-friendly wireless redstone.
Wireless restone requires two components: a sender station and a reciever station.
When the sender station is activated, it needs to update the hitbox of a block A, with block id X. This causes all blocks with the block id X to get the hitbox of A.
The reciever station has to repeatedly check, which hitbox a block B, with block id X has. If block B has the same hitbox as block A, then the reciever must output a signal. In all other cases, it outputs no signal.
So basically, if the sender station gets activated, all blocks with block id X get the hitbox of A. This is then detected by the reciever station, which can be anywhere in the world. If on the other hand the sender station doesn´t get activated, the blocks with block id X will probably not have the hitbox of A, and therefor the reciever station won´t output any signal.
Piston heads, glass panes, colored glass panes and iron bars are often used in wireless redstone, since their hitboxes can be changed through redstone contraptions.
Arrows are also often used in sender stations, since they update the hitbox of the block they´re stuck in every game tick, and can be automatically fired by dispensers.
Normally, this glass pane would push the boat. However, if the glass panes hitbox was that of a straight glass pane, the boat would not be pushed. This may be used to transmit wireless signals, because the hitbox may be changed remotely.
Arrows shot into a glass pane updates the glass pane, and therefore the global hitbox changes.
A contraption like this will result in a different lamp being powered based on the global hitbox.