Using Hashes as Unique ID
Generally not a good idea, for the following reasons:


If someone knows UserID and times, they may be able to match that back to transactions (depending on how this ID is exposed - if it's exposed externally via an API, someone knowing UserID could generate candidate TransactionIDs from guessed times)
High amount of entropy in the key means that your indexes on this key are going to fragment rapidly. If your DB has a page cache, the cache efficiency will drop as your data volume grows (this can be a killer).
If you can handle the performance concerns, then why not just generate a GUID?