Still learning this stuff. But when restoring a wallet from seed, it gives an option for restore height (date).

Do/should I set this to just before my first transaction? Or more on point if I set it to a month ago, will it still show correct balance?


The wallet application will scan the blockchain from the height you have given. If there were transaction linked to your address before that height, they will not be included and your balance will probably be incorrect (unless all the previous transactions add up to 0).

So yes, try to use a height that is a little before your first transaction on that address and you will be fine.

| improve this answer | |
  • 1
    Thanks. That's what I figured. Just trying to speed up the multi hour refresh. (my node is all up to date) – Dave Feb 14 '18 at 18:04

The restore height works as follows. It will pull block hashes up till the restore height and scan blocks from the restore height on. Scanning blocks is defined as scanning a block and checking for each transaction included in the block whether rA == aR (alternatively denoted as D == D'). If this "checks out" a transaction is "credited" to your address.

Now, if you specify a restore height after the first transaction to your wallet, the wallet will "miss" this transaction and thus report an erroneous balance after the wallet refresh has completed. Thus, you have to set a restore height before the height of the first transaction to your wallet. In addition, I generally advise to add a margin of safety, i.e., subtract 20k blocks from the height of the first transaction to your wallet. For example, if the first transaction to your wallet was included in block 1450000, use 1430000.

To obtain the height of the first transaction to your wallet, simply enter the transaction ID / hash into a blockchain explorer like, for instance, XMRchain. If you don't have the transaction ID / hash, but do remember an approximate date, you can "trial-and-error" the blockchain for an approximate height. For example, block 1350000 was mined in the beginning of July 2017, whereas block 1250000 was mined in the end of February 2017. Note that each month approximately has 22k blocks (30.5*720). Thus, as quick arithmetic trick, you can take the current height and subtract 22k blocks for each month in order to obtain a proper restore height.

Lastly, note that the wallet creation height works similar. That is, upon creation of a wallet, the wallet will use the daemon (monerod) top block height as wallet creation height (an approximation (minus one month worth of blocks) will be used if the wallet is not connected to a daemon). It will then pull block hashes up till the wallet creation height and scan blocks from the wallet creation height on.

P.S. I've added a table of restore heights that you can use in the appendix.


My wallet was created in | Restore Height I should use
July      2019           | 1855000
June      2019           | 1835000
May       2019           | 1815000
April     2019           | 1795000
March     2019           | 1775000
February  2019           | 1755000
January   2019           | 1735000
December  2018           | 1715000
November  2018           | 1690000
October   2018           | 1665000
September 2018           | 1640000
August    2018           | 1615000
July      2018           | 1590000
June      2018           | 1565000
May       2018           | 1540000
April     2018           | 1515000
March     2018           | 1490000
February  2018           | 1465000
January   2018           | 1440000
December  2017           | 1415000
November  2017           | 1390000
October   2017           | 1365000
September 2017           | 1340000
August    2017           | 1315000
July      2017           | 1290000
June      2017           | 1265000
May       2017           | 1240000
April     2017           | 1215000
March     2017           | 1190000
February  2017           | 1165000
January   2017           | 1140000
| improve this answer | |
  • Can you elaborate on why the "margin of safety" is advisable? – Jonathan Cross Jul 7 '18 at 16:04
  • A user will typically not remember the exact date. Therefore, it seems prudent to subtract 1 month worth of blocks to add a "margin of safety" in case the user remembers a (somewhat) erroneous date. – dEBRUYNE Jul 8 '18 at 9:04
  • I think this answer could get updated to include YYYY-MM-DD format, it would make things easier to explain. – selsta Apr 14 at 16:41
  • @selsta - Will look into how to best update the answer. – dEBRUYNE Apr 15 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.