<blockquote>
<p>So sure enough Bitcoin Core seems to start faster after doing that.</p>
<p>Is it a good idea? Or more specifically, what could go wrong?</p>
</blockquote>
<p>It must be the placebo effect that you are experiencing because <code>assumevalid</code> has no effect on this when the default values for the consistency checks are used (changed with parameters <code>-checklevel</code> and <code>-checkblocks</code>)</p>
<p>There isn't anything that could go wrong, but it also isn't actually doing anything. There are two reasons for this: the default depth to check for is 6 blocks and the default check level is 3 which means that the part that uses <code>assumevalid</code> is not even run.</p>
<p>Now if you increased the check depth to be more than 400 blocks and the check level to be 4, then yes, you should see a difference. But with the default parameters, it won't make a different.</p>
<p>Setting <code>assumevalid</code> is really only useful for the initial sync and for when you are catching up from being a few weeks behind. But that all happens once the software has fully started, not during the initialization phase which you are asking about.</p>

CC BY-SA 3.0
2018-01-06T08:01:26.073Z
I think OP may not be talking about the startup check, but about IBD for catching up with new blocks while his node was down.
Pieter Wuille
CC BY-SA 3.0
2018-01-06T18:16:45.427Z
@PieterWuille - no I was in fact talking about the startup check.  Maybe though the OS file cache was nice and warm (64GB RAM) so it did just seem a lot faster when I stopped/started Core.  Hmm, I'll have to really pay attention and find out what exactly, during the splash screen, seemed faster and report back ... thanks!
davidbak
CC BY-SA 3.0
2018-01-06T07:54:50.660Z
2018-01-06T07:54:50.660Z
2020-06-16T11:10:03.350Z
Ava Chow
<p>On my server my full node Bitcoin Core 0.15.1 can take several minutes, on starting, to "validate blocks".  And during that time it's thrashing the disk, slowing down everything else.</p>

<p>So I discovered the <code>assumevalid</code> command line/configuration parameter which takes a block hash and tells Core to "assume valid" that block and all ancestors.  Apparently it's updated when Bitcoin Core releases - and as a result it can be weeks or even months old.</p>

<p>So I created a little script to RPC to my full node and do <code>GetBlockCount</code> to get the current height, then I subtract 400 and use <code>GetBlockHash</code> to get the hash for a block about 3 days back.  Then I rewrite <code>bitcoin.conf</code> with that value as the parameter of <code>assumevalid</code>.</p>

<p>So sure enough Bitcoin Core seems to start faster after doing that.</p>

<p>Is it a good idea?  Or more specifically, what could go wrong?</p>

<bitcoin-core><bitcoin.conf><validation>
Script to periodically update assumevalid block in bitcoin core configuration, good idea?
davidbak
# Script to periodically update assumevalid block in bitcoin core configuration, good idea?

(Asked by: username_0 on 2018-01-06)

On my server my full node Bitcoin Core 0.15.1 can take several minutes, on starting, to "validate blocks". And during that time it's thrashing the disk, slowing down everything else.

So I discovered the `assumevalid` command line/configuration parameter which takes a block hash and tells Core to "assume valid" that block and all ancestors. Apparently it's updated when Bitcoin Core releases - and as a result it can be weeks or even months old.

So I created a little script to RPC to my full node and do `GetBlockCount` to get the current height, then I subtract 400 and use `GetBlockHash` to get the hash for a block about 3 days back. Then I rewrite `bitcoin.conf` with that value as the parameter of `assumevalid`.

So sure enough Bitcoin Core seems to start faster after doing that.

Is it a good idea? Or more specifically, what could go wrong?

**Tags:** bitcoin-core, bitcoin.conf, validation


---

## 1 answers

### Answer by username_1 on 2018-01-06. Score: 2

> So sure enough Bitcoin Core seems to start faster after doing that.
>
> Is it a good idea? Or more specifically, what could go wrong?

It must be the placebo effect that you are experiencing because `assumevalid` has no effect on this when the default values for the consistency checks are used (changed with parameters `-checklevel` and `-checkblocks`)

There isn't anything that could go wrong, but it also isn't actually doing anything. There are two reasons for this: the default depth to check for is 6 blocks and the default check level is 3 which means that the part that uses `assumevalid` is not even run.

Now if you increased the check depth to be more than 400 blocks and the check level to be 4, then yes, you should see a difference. But with the default parameters, it won't make a different.

Setting `assumevalid` is really only useful for the initial sync and for when you are catching up from being a few weeks behind. But that all happens once the software has fully started, not during the initialization phase which you are asking about.

> **Comments:**
> **username_2**: I think OP may not be talking about the startup check, but about IBD for catching up with new blocks while his node was down.  
> **username_0**: @username_2 - no I was in fact talking about the startup check.  Maybe though the OS file cache was nice and warm (64GB RAM) so it did just seem a lot faster when I stopped/started Core.  Hmm, I'll have to really pay attention and find out what exactly, during the splash screen, seemed faster and report back ... thanks!  

---

