You must have a 0.1uF cap between power and ground on the ATTiny (if using a breakout board, this is probably already there).
RESET ought to get get a 10k pullup to Vcc on it, though you shouldn't need it unless there are longish wires connected to reset that can pick up electrical noise; as long as the pin isn't configured to act as an I/O pin, the chip turns on the internal pullup)
Pin 5? *
Do you mean physical pin 5? (Arduino pin 0, PB0) This should definitely work (though, obviously, post your sketch so we can verify that you aren't doing something wrong there).
Arduino pin 5 (physical pin 1, PB5) is only available for GPIO if using a bootloader to program it (most often for the t85 this means a Digispark VUSB board**).
The timebase in the ATtiny85 (or any classic AVR) using the internal oscillator is only guaranteed to be accurate to within +/- 10%. In practice at 3.3~5v and room temperature, it is very unusual to see one more than a couple of percent out (exception: ATtiny841, 1634, and 828, which are consistently 3-4% high at 5v, but much closer at 3.3 - ATTinyCore has a workaround for this, and 1.4.0 will have considerably better workaround) - but that's still too much to be using it for timekeeping over the scale of hours. The modern AVRs (megaAVR 0-series, tinyAVR 0/1-series) are better, but they're still only within a couple %.
If you need accurate timekeeping, you need to use a crystal; ATTinyCore does support using crystal as clock source on the t85 f (most cores do not) - although since it takes 2 of the 5 pins, this is rarely done on the 8-pin parts. Crystal goes between pins PB3/PB4 (arduino pins 3, 4, physical pins 3,2), and each of those pins gets a loading cap appropriate to the crystal between that pin and ground. After connecting the crystal, you need to select crystal as clock source and "burn bootloader" from the IDE.
Have you ruled out EMI as the source of these false pulses? (eg, if you put the same sketch on there, only omit the part that actually does the pulse every hour, do you get any false pulses? If so, that would strongly implicate EMI, that is, the cable picking up ambient electrical noise)
- General comment regarding pin naming/numbering - the most common practice I've seen is to refer to the Arduino pin number; I think it is better to refer to pins by port/bit (eg, Pxn). Note that - except on the t85 (sort-of-coincidence), you can't refer to the pits in Pxn notation, because the io headers (supplied by compiler package) already define all the Pxn's as n (ie, PB0 is defined to 0) so you can do PORTx|=1<<Pxn; and things like that. I'm pushing for PIN_Pxn defines to be defined to the arduino pin number of Pxn - it's already in my megaTinyCore, and will be in ATTinyCore once I get the 1.4.0 release out (hopefully tonight), and it's in the MCUDude cores too.
** Note that if using a VUSB ATtiny85 breakout board, assuming temperature/voltage hasn't changed from when it was last programmed, it's going to be significantly better, around 1%, since they cal the oscillator from the USB clock when you upload, and save that value.