Product backlog can be described as evolving requirements books. The requirements here are in prioritized manner.
The product backlog contains ideas and business requirements given by the people who are interested in the product, people who are going to work on that.
These are just a small piece of information which carries a lot for the project. The product backlog can be created by doing a brain storming session with the people who are interested in the product and people who knows similar product. There is no need for the Product owner or the team to get the entire product backlog ready to kick off the first sprint. It is enough if the product backlog has contents that are ready for the first sprint. While the team is working on first sprint, the product owner can fill in stuffs in the product backlog.
The Product back log can contain stuffs like user requirements, any kind of impediments that needs to be removed or whatever is important for the product to be developed. The product backlog is dynamic requirements documentation. This document keeps changing. New stuffs get added, stuffs get deleted, and priority gets changed and so on.
As said earlier the items in the product backlog are prioritized based on the business needs and values. The product owner has the full right to change the priority of the stuffs in the product backlog. Though there may many people who are interested in the product, it will be the one person (Product owners) responsibility to prioritize stuffs in the product backlog. If someone wants to change the priority in the product backlog, he has to discuss with the product and the PO can make the change if needed.
To estimate the stuff in the product backlog, the PO sits with the team members and expertise. All these people will make an estimate on the stuffs in the product backlog. Estimation should not be done based on hours. Estimation should be made with respect to points. These estimations are subjected to changes as the team pulls the stuff from the product backlog for the sprint.