What prevents continued hashing of a key from being used as a cipher when xored with plaintext? This is just an idea I had while looking through some threads so take it as you will. 

Given a plaintext of any length and a key that a specific hash function is capable of taking as input(I mention this as I know bcrypt has issues with extremely large inputs), what would be the potential issues/attacks of hashing the key and then xoring the resulting key with a plaintext block of the same length? For the next block you would hash the previous hash created via the key and xor that with the next plaintext block. Repeat till you reach the end of the plaintext, pad it to the needed length, and commit the last xoring

I would imagine that it would make for a high speed stream cipher that is reasonably capable as long as the initial key is sufficiently strong.

Thanks.
This is essentially a (bad) stream cipher. It has multiple problems:


You might hit a cycle much sooner than you'd want.
It's not parallelizable - this is a large performance issue on modern CPU's compared to algorithms that parallelize well.
The key is only inserted at one point of the stream, meaning if an enemy knows only one block of plaintext it can XOR it out to retrieve the internal state of the cipher compromising all further blocks.
There is no nonce, meaning that every cipherstream will be the same.


(5.)&nbsp;&nbsp;Padding plaintext is not necessary in a stream cipher - you can simply discard the unneeded bits from the cipherstream.

However, the answer to the question in your title (What prevents continued hashing of a key from being used as a cipher when xored with plaintext?), is nothing. For example the ChaCha stream cipher works by repeatably hashing the key, nonce and an increasing counter for each block. Note that the hash function ChaCha uses is very specialized - it doesn't compress or is collision resistant, and as result can be much faster than "regular" hash functions that have much more stringent requirements.