Select With (nolock) OR TransactionScope With Option Read Uncommitted Data

Hi Sql gurus :))
I've got a question that I couldn't find a satisfying answer on the net.
What is the difference between:
1) running sql query (select from sth with nolock) with no transaction
2) running sql query (select from sth) withing a TransactionScope with option Read Uncommitted data
Basically, both should do the same work. However is anyone aware of any potential problems using any of both approaches ?
We use 1) to improve our web application scalability since the system works in such a way that any selects and updates on that table (sth) do not interfere with one another.
However, updates are done in a TransactionScope. And when having simultaneous select with nolock and update in a Transaction scope (the select statement has a where clause and
returns records that are not updated by the update statement). However sometimes ( we still cannot figure it out when) the select statement returns some records twice.
For example, the select should return 1000 records , but (sometimes) it returns 1002 records ( the extra 2 records are copies of some of the original 1000 records).
Removing the nolock, makes the problem does not appear - but i want to be 100% sure that nolock is our troublemaker. And if it is - why ?
We also have a problem that this particular nolock select sometimes return even less records than it should.
I know it sounds impossible but it happens.
So anyone who has experience with select with nolock, please share :)
Thanks in advance,
 Yani