All requirements are completely predictable. By doing enough analysis up-front, extra work will be discovered before the sprint starts. Accurate estimation will therefore be possible, and this question will never arise.
Parts of your project will be new things you've never done before (otherwise it would be exactly the same project that you did before, and that never happens). Discoveries are inevitable, both in analysis and development. You can't estimate things that you've never done before, and trying to do so will usually result in floundering and / or estimate padding.
What to do about it
Recognize that there's always uncertainty in development and be adults about it. The end of the sprint is there for you to focus on getting feedback from your stakeholders, and that feedback is far more important than any story-point estimation.
Arguments over these discoveries often result in people spending more time trying to analyze the newest, most risky elements of a project ahead of time. Analysis isn't as good at flushing out those discoveries as actually delivering something is (or Waterfall methodologies would work), so when those discoveries are made, it's very important to focus on delivery and feedback.
Otherwise, analysis paralysis sets in, and those elements end up getting pushed to the end of the project instead, when there's no time to react to them.
The purpose of estimation and velocity measurement is threefold:
- To help decide the focus for the sprint
- To measure against long-term plans in order to see how a project is progressing
- To help gain stakeholders' trust through delivery.
Pure Scrum doesn't mandate story points and velocity measurements. Instead of making promises around points, consider making promises around aspects of stakeholder needs on which you'll deliver or showcase something for the purposes of learning and feedback. By addressing the riskiest aspects of a project early on, you'll learn fast, de-risk the project (and help to make more accurate plans), and gain stakeholders' trust through addressing the things that stop them sleeping at night.
Under no circumstances should the story points ever be used to "punish" the team. That will only create a rift between the PO and other team members, and the PO ought to be part of that same team.
If you're looking for a tracking mechanism, and the scope changes happen regularly, consider a burn-up chart, or CFD, instead. That will let you track your work against the scope over the longer term, and you'll also be able to see how scope itself is changing.