Never Rebase the Starting Values of a Burn-Down Chart
Burn-down measures work remaining in the iteration. For example, if you start a Sprint containing 100 points, complete 50 points worth of work in the first two weeks, and then add 60 points of new work in the third week, you don't rebase the starting value. Instead, you show a rise in the amount of work remaining for the iteration. For example:
Since you didn't start the iteration with 160 points, rebasing the graph would misinform the viewer as to what really happened, e.g. that a significant chunk of new work was added mid-sprint. In the example above, the 60 points that were added in week three of a four-week Sprint clearly communicates when the new work was added, how much was added, and also shows that the amount of work completed in week four exceeded all the work done in the first three weeks of the Sprint put together.
Time, capacity, and efficiency information would be lost if you rebase your starting value, since it would no longer show work remaining over time, but instead would be pretending that the work was enqueued from the beginning. This is misleading, and will prevent process issues from being properly identified and accurately communicated.
However, you may find that you need to adjust the scale of your graph to accommodate work-remaining that is higher than your starting value. In this case, the graph now goes from 0-120 instead of 0-100 in order to accommodate the burst to 110 story-points remaining in Week 3.
Danger, Will Robinson!
Please note that unless stories were wildly mis-estimated, this type of successful swing in the burn-down (e.g. when work-remaining goes up dramatically, but the team still completes all work) is unlikely to happen in the real world. While you may frequently see small jumps where work-remaining increases rather than decreases due to new information uncovered during the Sprint or additional story-related tasks that must be added to the Sprint Backlog to meet the Definition of Done, large increases to the work remaining without a related change in team capacity or efficiency is a project smell that your burn-down chart has uncovered for you, and which the team must carefully inspect for process problems.
Use irregularities in the burn-down to identify problems with estimation, capacity planning, or scope-creep by tracking work remaining without retconning the baseline. Doing anything else simply papers over a process problem that should be made visible for the team to address during a Sprint Retrospective.