<p>Calling <code>importaddress</code> will rescan the whole blockchain in default according to <a href="https://bitcoin.org/en/developer-reference#importaddress" rel="nofollow noreferrer">bitcoin.org</a></p>

<blockquote>
  <p>Set rescan parameter to false to not rescan the block database
  (rescanning can be performed at any time by restarting Bitcoin Core
  with the -rescan command-line argument). Rescanning may take several
  minutes.</p>
</blockquote>

<hr>

<blockquote>
  <p><strong>help importaddress</strong></p>
  
  <p>importaddress "address" ( "label" rescan p2sh )</p>
  
  <p>Adds a script (in hex) or address that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.</p>
  
  <p>Arguments:<br>
  1. "script"           (string, required) The hex-encoded script (or address)<br>
  2. "label"            (string, optional, default="") An optional label<br>
  3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions<br>
  4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well</p>
  
  <p>Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.<br>
  If you have the full public key, you should call importpubkey instead of this.</p>
  
  <p>Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated as change, and not show up in many RPCs.</p>
  
  <p>Examples:</p>
  
  <p>Import a script with rescan<br>
  <code>bitcoin-cli importaddress "myscript"</code></p>
  
  <p>Import using a label without rescan<br>
  <code>bitcoin-cli importaddress "myscript" "testing" false</code></p>
</blockquote>

<hr>

<p>UPDATE Since Bitcoin core v0.14 you can use <code>importmulti</code> to import addresses. </p>

<pre><code>bitcoin-cli importmulti '
  [
    {
      "scriptPubKey" : { "address": "1NL9w5fP9kX2D9ToNZPxaiwFJCngNYEYJo" },
      "timestamp" : "0",
      "label" : "Personal",
      "watchonly": true
    },
    {
      "scriptPubKey" : "76a9149e857da0a5b397559c78c98c9d3f7f655d19c68688ac",
      "timestamp" : 1493912405,
      "label" : "TestFailure"
    }
  ]' '{ "rescan": true }'
</code></pre>

<p>Response: </p>

<pre><code> [
{
  "success": true
}, 
{
  "success": false,
  "error": {
  "code": -8,
  "message": "Internal must be set for hex scriptPubKey"
  }
}
]
</code></pre>

<p>Note: </p>

<ul>
<li>Bech32 addresses are not supported using this method until the moment. (You're free to edit this answer when it's available.)</li>
<li><code>importmulti</code> will not speed up importing progress since this method locks your wallet and block any further RPC calls.</li>
</ul>

CC BY-SA 3.0
2017-11-28T08:55:18.063Z
But if an address has already been imported earlier why would it trigger the rescan again? That seems very odd. The node could simply do nothing in that case and all would be fine, and a lot of CPU time saved.
blues
CC BY-SA 3.0
2017-11-28T08:59:40.560Z
Bitcoin core commands is like for advanced users and it's not an interface you can just use bitcoin-qt instead.

in your case if you would like to use bitcoin-cli you can check if address not exist you can call importaddress
Tailer
CC BY-SA 3.0
2017-11-28T09:12:17.747Z
So what you are telling me is that it is a bug, but a workaround exists by checking first? A rescan of an address that is already in the wallet and was rescanned for before can never result in any new information.
blues
CC BY-SA 3.0
2018-04-04T04:03:59.817Z
I have taken the liberty of adding further info about importaddress to your answer.
Willtech
CC BY-SA 3.0
2018-04-05T20:16:01.883Z
Now it's even better! @Willtech
Tailer
CC BY-SA 3.0
2018-04-05T21:01:55.357Z
This is not entirely correct. `importmulti` is not supposed to rescan the whole change, but only the part affected by the keys being imported (you can specify their birth time). I would say this is a bug.
Pieter Wuille
CC BY-SA 3.0
2017-11-28T08:34:19.890Z
2018-04-05T23:29:50.580Z
2018-04-05T23:29:50.580Z
Tailer
<p>While experimenting with importing addresses and keys via json rpc I noticed that importing an address twice triggers two rescans. This strikes me as very odd. My question is:</p>

<ul>
<li>Is this intended behaviour and if so, what is the reasoning behind it?</li>
<li>OR: Is this a bug? If so, is it a known bug?</li>
</ul>

<rescan><importaddress>
calling importaddress with same address
blues
# calling importaddress with same address

(Asked by: username_0 on 2017-11-28)

While experimenting with importing addresses and keys via json rpc I noticed that importing an address twice triggers two rescans. This strikes me as very odd. My question is:

* Is this intended behaviour and if so, what is the reasoning behind it?
* OR: Is this a bug? If so, is it a known bug?

**Tags:** rescan, importaddress


---

## 1 answers

### Answer by username_1 on 2017-11-28. Score: 2

Calling importaddress will rescan the whole blockchain in default according to bitcoin.org

Set rescan parameter to false to not rescan the block database
  (rescanning can be performed at any time by restarting Bitcoin Core
  with the -rescan command-line argument). Rescanning may take several
  minutes.



help importaddress
importaddress "address" ( "label" rescan p2sh )
Adds a script (in hex) or address that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.
Arguments:
  1. "script"           (string, required) The hex-encoded script (or address)
  2. "label"            (string, optional, default="") An optional label
  3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
  4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well
Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.
  If you have the full public key, you should call importpubkey instead of this.
Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated as change, and not show up in many RPCs.
Examples:
Import a script with rescan
bitcoin-cli importaddress "myscript"
Import using a label without rescan
bitcoin-cli importaddress "myscript" "testing" false


UPDATE Since Bitcoin core v0.14 you can use importmulti to import addresses. 
bitcoin-cli importmulti '
  [
    {
      "scriptPubKey" : { "address": "1NL9w5fP9kX2D9ToNZPxaiwFJCngNYEYJo" },
      "timestamp" : "0",
      "label" : "Personal",
      "watchonly": true
    },
    {
      "scriptPubKey" : "76a9149e857da0a5b397559c78c98c9d3f7f655d19c68688ac",
      "timestamp" : 1493912405,
      "label" : "TestFailure"
    }
  ]' '{ "rescan": true }'

Response: 
 [
{
  "success": true
}, 
{
  "success": false,
  "error": {
  "code": -8,
  "message": "Internal must be set for hex scriptPubKey"
  }
}
]

Note: 

Bech32 addresses are not supported using this method until the moment. (You're free to edit this answer when it's available.)
importmulti will not speed up importing progress since this method locks your wallet and block any further RPC calls.

> **Comments:**
> **username_0**: But if an address has already been imported earlier why would it trigger the rescan again? That seems very odd. The node could simply do nothing in that case and all would be fine, and a lot of CPU time saved.  
> **username_1**: Bitcoin core commands is like for advanced users and it's not an interface you can just use bitcoin-qt instead.  in your case if you would like to use bitcoin-cli you can check if address not exist you can call importaddress  
> **username_0**: So what you are telling me is that it is a bug, but a workaround exists by checking first? A rescan of an address that is already in the wallet and was rescanned for before can never result in any new information.  
> **username_2**: I have taken the liberty of adding further info about importaddress to your answer.  
> **username_1**: Now it's even better! @username_2  
> **username_3**: This is not entirely correct. `importmulti` is not supposed to rescan the whole change, but only the part affected by the keys being imported (you can specify their birth time). I would say this is a bug.  

---

