I believe it's hard to get a canonical answer for this question. In this case, the best answer would be something like whatever works better for you and your team.
How to assess this? Well, maybe doing some experiments, the good ol' trial and error. Before going into them, some assumptions could be made that might be helpful on the empirical testing:
Considering blockers
Pros: Segregate items that cannot be started now, leaving a 'clean' to-do list
Cons: Doing so could be a Scrum Smell, as an item that's not ready to be implemented should not be considered to the current iteration (and I second Liaths comment - you should have a good DofR)
Considering ToDo
Pros: You'll ensure Scrum Master will be dealing with actual blockers rather than raising potential false alarms - the Scrum Master might have enough on his plate dealing with actual blockers to be concerned about a (assumed) controlled dependency to make it to the sprint goals
Cons: Depending on the nature of the project and the expectations the Product Owner has, if it may become a blocker then the PO might come with the complain that 'he should have been warned before'
There are several other factors to consider, but all in all, you need to find what works better for you and your team.
Bottomline: My gut feeling says that your blocker ratio is very likely to be inversely proportional to the maturity level of the team, so if you're running a senior team with seasoned PO, having these items on 'ToDo' shouldn't be a problem. Likewise, if you live on a challenging environment with scary POs, having items highlighted as 'blockers' could improve transparency in case plans go wrong.