Rule 1: Estimates are a Game.
Consequence: Don't give an estimate until you know what it's being used for.
There's little real meaning in an estimate. Yet, everyone thinks they're very important. They change daily, yet, somehow there's management magic in having a number or a schedule that's based on utter nonsense.
An estimate might be used to make a go/no-go decision. A single big number is probably more helpful.
An estimate might be used to track ongoing progress. A sequence of releases with budget for each release is probably more helpful.
An estimate might be used to force you to ask for a lower billable rate. Doesn't matter what estimate you provide, you'll still wind up discussing your billable rate.
An estimate might be used to embarrass a manager in the future. It doesn't matter what you provide here, the project will break down in a few months and people will be moved around, and you'll be left wondering what happened.
You need to know what purpose the estimate serves.
What's funny is that a low-bid estimate might get a project started. Once you're rolling, you can raise the estimate and no one will care.
Sometimes, the estimate must be very high to make the project look big and important. Once you're rolling you find that the first few releases solve the business problem and the rest of the project gets cancelled because the later releases where a bad idea.
break it down into small tasks that can be done in a few hours and give them the full list?
Usually a bad idea. Depends on what the customer needs.
Your original guess at the small tasks must have errors, omissions and mis-estimates in it. You can't predict the future.
Tracking all of your errors will bother most customers, so it's rarely helpful to reveal this level of detail.
give them one big number and work towards that?
Usually a bad idea. Depends on what the customer needs. Sometimes they only need a big number of justify the budget vs. the cost of the problem you're going to solve.
Changing this estimate as your move through the project will bother some customers. A few are comfortable with change.
Some, however, will be bothered by the discrepancies between your original estimate and any revisions. Some can bury you with change-control paperwork to track the changes in the big number.
And if so does that come from a more detailed estimate that you don't need to show them?
Not a bad idea. It doesn't help in general, but it's not a bad idea.
Remember. It's a game. You can't predict the future. Working up from details is about the only way to "justify" the random number at the end of the process.
Do you break it up into big "phases" and give them a number of hours for each phase?
This is about the best you can do.
You can't win this game. You can't break even. You can't even get out.
Your estimates have errors and some customers will be upset when you correct those errors and revise your estimate.
The "phases" should be in order of importance. They should match user stories. They should be releasable (in principle) as incremental pieces of functionality.
What's most important is finding out what the estimate will be used for and providing something that fits the use case.