8

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?

2
  • I have lost a couple of transactions incomes because I think the daemon was working wrong, there was filling like 180Gb in errors, how can I restore the height? or it will be done automatically? all help is welcome
    – Davide
    Nov 30, 2020 at 17:10
  • @Davide - Can you explain your issue in more detail?
    – dEBRUYNE
    Nov 30, 2020 at 22:57

2 Answers 2

8

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.

1
  • 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, 2018 at 18:04
6

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.

Appendix:

My wallet was created in | Restore Height I should use
April     2021           | 2275000
March     2021           | 2255000
February  2021           | 2235000
January   2021           | 2215000
December  2020           | 2195000
November  2020           | 2175000
October   2020           | 2155000
September 2020           | 2135000
August    2020           | 2115000
July      2020           | 2095000
June      2020           | 2075000
May       2020           | 2055000
April     2020           | 2035000
March     2020           | 2015000
February  2020           | 1995000
January   2020           | 1975000
December  2019           | 1955000
November  2019           | 1935000
October   2019           | 1915000
September 2019           | 1895000
August    2019           | 1875000
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
6
  • Can you elaborate on why the "margin of safety" is advisable? Jul 7, 2018 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, 2018 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, 2020 at 16:41
  • @selsta - Will look into how to best update the answer.
    – dEBRUYNE
    Apr 15, 2020 at 9:28
  • do september 2020 for me bro give me new table plz Oct 18, 2020 at 3:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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