Re-estimating target blockheights #16
Description
As currently designed, the user enters a "target date" of their choosing. It is the site's responsibility to get a Bitcoin transaction (which includes the OP_RETURN containing the "stamp") mined into a block as close to the "target date" as possible.
When the user submits a future date, they are presented with an estimated blockheight. This blockheight is just an estimate, and could become very inaccurate depending how far in the future the user-submitted "target date" is.
This issue defines a possible solution to this challenge.
The database will need to store the "target date", in addition to "target blockheight" and "stamp" that it stores now.
At a regular time-interval (every day, every hour), the site will scan the database for "target blockheights" which were originally estimated when the "stamp" was initiated, and update the "target blockheight" with a re-estimation based on the current blockheight.