How can you stop the dev team from padding their numbers when it comes to creating task times? How is there any motivation for them to do their work if there are no real deadlines and they are just measured against their velocity.
Get the job done by this deadline
vs
Get the job done whenever we will reduce scope, quality or increase resources
The foundation of most agile methods is trust. If you don't trust your team, why have you hired them in the first place? If you think they are not up to the task, it is better not to start the project because it is almost surely doomed to failure - either because you are right and the team is a bunch of inept developer,s or because you are wrong but your lack of trust and overcontrolling suffocates the team and actually saps their commitment and enthusiasm.
OTOH if you are sure that you have hired the best guys available, and that they are talented and motivated, the best is to give them a good challenge, let them work and try to remove all obstacles from their way.
In my experience most developers start out enthusiastic and motivated to create products they can be proud of. However, impossible deadlines, irrealistic expectations, too much bureaucracy, overcontrolling management - and last but not least, reducing quality - can quickly kill that motivation.
The point of agile methods is that developers are the right people to know / estimate the cost of a specific feature. If management insists on estimating both the resources, scope and time allotted to the project, it almost always results in disaster. If OTOH the developers are given trust and responsibility, they will usually live up to the task. In Scrum, the team together works out the estimates and fights problems / issues coming up during the sprint. In a good projects, team members quickly gel with the team and they feel personal responsibility for the project. This can go as far as poking laggard members to produce results instead of pulling the team back.
In my experience, developers pad numbers due to uncertainty. Are your product owners clear in their business requirements? Are the stories sufficiently small to estimate against?
Your 2 choices indicate to me that you have a fundamental misunderstanding of Scrum. The promise of Scrum is not getting the same result, just faster. It is the ability to iterate quickly, respond to feedback and alter course. The foundation of Scrum is the self running team. If you don't have teams you trust, Scrum probably isn't for your organization.
As Péter said in his response, team motivation is key and the quickest way to kill that is to undermine them. If the team feels management doesn't support or believe in them they will have no reason to make aggressive estimates and will simply cover their own butts. It's your job as a manager to help them succeed.
Additionally, the agile methodologies promote responsibilities to the peer. You shouldn't have just one person estimating items. Make it a group thing, and make sure (mostly) everyone agrees to the estimate. If you have your whole team colluding against you to pad estimates, you have a lot more problems than you think.
Besides, there's a lot of opportunity to pad estimates and make excuses in traditional waterfall / BDUF (big design up front) effort. I would say that scrum, with the daily scrum meetings, helps to contain this more than it helps to promote it.
It is actually quite impossible to "pad" estimates in scrum. After a few sprints the velocity will average out and the team will "know" how many points it can commit to. There is nothing to pad.
I think you have your statements backwards because
Get the job done whenever we will reduce scope, quality or increase resources
is an exact description of Waterfall; not scrum. In scrum we have deadlines, it is called the end of the sprint. In scrum we NEVER sacrifice quality because we know that will cost us more in the long run. In scrum we don't add resources because we know that people gel and form a "team" and upsetting that balance is detrimental to productivity.
Why are you bothering at all with task times? The only time I have seen good developers pad estimates is if they are forced into giving an estimate for an unknown feature. We don't do this in scrum. We know what the conditions of acceptance of a feature is before we commit to it.
I wrote a blog post a while back on estimation anti-patterns. It's a funny read but sadly all of the patterns are things I've either seen done or heard of from colleagues. We've gone through about 3 of them on our current project; I don't think there's any team which manages to avoid all of them entirely!
http://lizkeogh.com/2009/11/30/estimation-anti-patterns/
Also have a look into systems thinking, game theory and perverse incentives. If the devs are padding the estimates it's because the environment they're working in is encouraging them to do so. Changing that environment will help them.
One approach to avoid this situation entirely is to estimate in story points, i.e. ask the question "does this story require more or less work compared to that story?".
Good answers on this one already. Basically, if you assume developers will cheat on you by reporting hours they didn't in fact work (but spent playing whichever MMORPG is now en vogue) why you even work with them in the first place? And if you trust them, why you think they "pad"?
BTW - it is completely normal for teams that are new to Scrum to first overestimate (and have to drop items from Sprint), then - getting thus burned - underestimate to avoid that happening to them again, then as others have pointed out team velocity will level out and people will have a better understanding of how much they can do within a sprint.
One more hint as to what you can do: don't question their hours, don't try to "manage" them by telling them how much time this or that should take. Rather, ask them how they want to achieve this or that, what solutions they want to use and why? It is quite common with good geeks that they tend to over engineer - if things look way bigger than you expected probably there is a misunderstanding here about what is being built that needs to be cleared.