I want to know if a sender can somehow predict what the last digit will be. Also the only possible combinations are a-z and 0-9 right?
Yes. If the sender has the technical knowledge, they can choose what the last digit of their transaction ID will be.
The only possible values when the ID is in its common hexadecimal representation are: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, & f
Although you may also see the alphabetical values in upper case: A, B, C, D, E, & F
Thanks.
What about the last 5 or 10 digits, will there be a point where they cannot have any influence on it?
It all depends on how fast their computer is.
The sender can just keep creating transactions (modifying an unimportant part) and seeing what the resulting hash is. If it meets your criteria they broadcast it to the network. If it does not match your criteria, then they DON'T send it to any peers. They just try again instead.
Since there are 16 possible values for the last character, there is a 1 in 16 chance that the address they generate will match. On average, they will need to try 16 different transactions before they find one with an acceptable value. I'd expect any modern computer to be able to do this in a few thousandth's of a second.
Notice that you want them to match 1 character and the number of possibilities is 16
1 = 16
If you want them to match the last 2 characters, then there are 16 possible values for the last character, and for each of those there are an additional 16 characters for the previous character. That means they have 16 X 16 = 256 different possibilities. They have a 1 in 256 chance with each attempt and on average will need to try 256 different transactions until they find one to broadcast. I'd expect any modern computer to be able to do this in less than a second.
Notice that you want them to match 2 characters and the number of possibilities is 16
2 = 256
If you want them to match the last 3 characters, then there are 16 possible values for the last character, and for each of those there are an additional 16 characters for the previous character, and for each of those 256 pairs there are 16 possible values for the character before that. That means they have 16 X 16 X 16 = 4096 different possibilities. They have a 1 in 4096 chance with each attempt and on average will need to try 4096 different transactions until they find one to broadcast. I don't know how long to expect that to take, but given the ease of parallel processing I'd be surprised if someone told me it would take more than a few seconds.
Notice that you want them to match 2 characters and the number of possibilities is 16
3 = 4096
Perhaps you are beginning to see a pattern here?
Matching 4 characters will be 16
4 possibilities which is 65,536
Matching 5 characters will be 16
5 possibilities which is 1,048,576
Matching 6 characters will be 16
6 possibilities which is 16,777,216
and so on.
So, the question to figure out the answer to is...
How much money would they need to spend to generate the necessary number of transactions?
How much time will it take to do it?
If the user needs to respond to something quickly, then getting the average time high enough might be enough to stop nearly all attempts.
If finding a matching transaction ID will earn the user some money, then getting the average cost high enough might be enough to stop nearly all attempts.
