How is the block hash for "skip transaction validation" determined?

4 replies 352 views
DarkSeedSenior Member
Posts: 209 · Reputation: 1423
#1Feb 2, 2018, 12:13 PM
So I’m setting up a Bitcoin Knots node from scratch. It’s been a while since I’ve done this (usually I just used Core). I came across this option that says: "skip validation of the transactions until after block" And then it shows a block hash. I’m guessing this just skips all transactions that come before that specific hash. But I’m curious, how is that hash chosen? Do the devs pick it manually? If so, what’s the reason? Or is it something that changes dynamically? What criteria do they use to decide the hash? Honestly, I turned off this option and prunning too since I want the whole blockchain, but I’m just curious if this is something specific to Knots. I figure it might be from the Bitcoin Core codebase, which they added at some point to help nodes sync on smaller storage. Just hoping that 2TB will be enough to hold the whole blockchain for a few years.
6 Reply Quote Share
byte2019Senior Member
Posts: 270 · Reputation: 1836
#2Feb 2, 2018, 01:19 PM
You just observe the chain, and pick something, which is unlikely to change. For example: we have a rule, that coinbase transaction needs 100 confirmations to be moved. Which means, that if there would be bigger reorg than 100 blocks, then we would have some problems, because then, newly created coins can be used to make transactions, which could disappear after chain reorganization. For example: at the moment of writing this message, the latest block hash is: 00000000000000000002128242740a658cddd02874729a1bff5a485130d84c5a. And you can go something around 100 blocks backward, and say, that everything up to 00000000000000000001fbcc91af1dc346662bc536cb4d8713cd992f00794970 is valid. If it is not, then it would be in the news, if someone would find some bug, similar to Value Overflow Incident, in some earlier block (even during that incident, reorgs were not bigger than 100 blocks, but rather something like 53). Yes. You can change one block to another, if you want. Or you can disable it entirely, and always check everything. It is just some assumption, which makes synchronization faster. If you checked a chain once, and you know, that for example everything up to the block 900k is valid, then you can trust yourself, that if the hash of this block didn't change since the last time you did it, then everything is still as valid as it was (unless you assume, that someone broke SHA-256 in the meanwhile, or did something similar). But of course, it is up to you. In the same way, if you synchronized the chain once, then you can copy-paste files, and avoid synchronizing it again. The client fully trusts the database you pick, and if you checked it once, and didn't mess up anything, then you can just reuse it. It is adjusted manually every sometimes. Now, trusting the block 911250 seems to be ok, but if the chain will grow to one million blocks, then it would mean, that the last 88750 blocks will be checked, so by keeping the same hash, this optimization becomes worse over time, so every sometimes, it is manually updated, to some more recent block header. And by checking that hash, you can roughly estimate, when it was updated, and do you need to bump it, or not. Nothing more than just performance, and likelihood of seeing some block reorganization. If you need to validate everything, then set it to the Genesis Block, or disable it entirely. And if you synchronized the chain recently, and you know, that everything up to a given block is correct, then you can set it, to avoid checking everything yet again, if you don't want to. For secp256k1 with its 4 MB witness limit, it should be acceptable. But for some quantum experiments, I think they may consume much more than that. But for now, it should be sufficient, I guess, as long as you don't have to deal with quantum signatures.
1 Reply Quote Share
DarkSeedSenior Member
Posts: 209 · Reputation: 1423
#3Feb 2, 2018, 03:15 PM
Thanks. I want to use assumevalid for tesnet to sync faster. Something I don't understand is, if assumevalid= is a 0/1 toggle option, how do you specify your own block hash? If you use assumevalid=1, then it uses whatever was pre-selected by the developers I assume. But if I want to use my own blockhash value, what do you do? would this work? testnet4=1 assumevalid=00000000000000000001fbcc91af1dc346662bc536cb4d8713cd992f00794970
3 Reply Quote Share
byte2019Senior Member
Posts: 270 · Reputation: 1836
#4Feb 2, 2018, 08:15 PM
I guess you should run the client from the command line, and read its help carefully. Because there are a lot of options you may want to tweak in that way or another.
5 Reply Quote Share
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#5Feb 2, 2018, 08:24 PM
Based from how it's written, are you pertaining to your bitcoin.conf file? If so, those options should work but if you want it to apply to testnet4 only, put it under "[testnet4]" line. Else, mainnet and other test chains will try to read that config with hash from the wrong chain. e.g.:
6 Reply Quote Share

Related topics