Contract matters
This is a big mistake because the time that I will spend [...] will not be paid
Actually, the big mistake is that your contract makes it possible that you spend your time working for free. It doesn't matter if you are solving a bug or learning a technology required for a new project: the customer has to pay for the time you spend.
You should not work for free. That's as simple as that. It makes you feel bad, and it encourages your customer to think about you as a guy who works for free anyway, and so who don't have to be particularly respected, or paid at all, after all. As soon as your customer knows that you spend one hour working for free, your relation is screwed.
This is also why it is essential to have a contract written by an actual lawyer specialized in software development contracts.
Technical estimates
What errors I did, and how can I avoid it in the future.
Technically speaking, you error was to give an estimate too quickly. You may have spent maybe a few more hours studying the impact, and probably find the relation between the data and the authentication.
But such mistakes happen anyway, so it's not a big fault from the technical point of view.
This is not very different from cases where you give an estimate of two weeks for a task, and a week after you started the task, you find that it requires much more work. Then, you simply send to the stakeholders (would it be your manager or your customer) the readjusted estimate which takes in account the things you have discovered meanwhile.
You may have made a mistake of giving a very precise estimate. If you tell that a change will take “eighty hours”, this is not the same thing as “ten days”, and not the same thing as “two weeks”. Moreover, estimates are often represented as a range or contain a hint about the precision:
The task will take from 4 to 9 days.
or:
The task will take 16 days ± 4 days.
This makes the progressive readjustment of the estimate more intuitive.
Another important aspect is that you should be able to say no. This applies specifically to those two types of questions:
“Do you know how long this task will take?”
If you don't know how long the task will take, don't tell “Three weeks” just to get rid of the person.
“Can you make an effort to deliver it faster?”
If you answer “Yes”, it means either that your last estimate was wrong (in which case, why would you make wrong estimates in the first place?), or that you know how to be more productive, but don't do it unless specifically asked, which doesn't sound very professional either.
It's all about leverage
But, again, the most important thing is how do you interact with your customer, which boils down to two things: what contract says and what is your leverage.
For instance, compare this message:
On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task also requires to make changes in the top menu, since both partially rely on the same code. Given those new elements, the updated estimate is 11 days ± 2 days.
with this one:
On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task is much more difficult than I thought, so I'm not sure I'll be able to release the changes on time. Can you, please, accord me three additional days for this task?
The second one sucks. It shows that the developer has no leverage whatsoever. It doesn't give any estimate, but barely begging for extra time. It feels like the developer screwed the original estimate, and feels bad about it. The first message is purely informal: here's an estimate, I don't care what you think about it and I don't need your approval, since our contract doesn't require your approval in this case. My early estimate was correct, and the later one just takes in account additional info. Nothing more.