Answered here: https://stacker.news/items/1457342

> It checks that every block header commits to the previous block header, and that the assumevalid block is in the header chain.

Isn't this the same level of security as SPV?

> It also rebuilds the utxo set from scratch  

But if they don't check for validity, the node is trusting that the rest of the network did such checks. What is the difference between this and an SPV node trusting that the longest the majority of hash power isn't tricking them?

Scoresby

 does all checks except script validation. Among other things, it verifies that the transaction bytes hash to the txid, and the Merkle root commits to all txid in the correct order. It checks that every block header commits to the previous block header, and that the assumevalid block is in the header chain. It also rebuilds the UTXO set from scratch. With that you are guaranteed to have the same blockchain byte-by-byte up to the assumevalid block as the rest of the network had when the 

 block was defined. Otherwise, the assumevalid header would not be in your header chain. To arrive at a different UTXO set, you’d have to interpret a byte-by-byte matching transaction differently than the rest of the network.

If your software were to do that, it’s broken, but (maliciously) broken software could also mislead you in any other number of ways. That’s why you should always check the signatures on the binary or build from the source code yourself, but even then you trust the people that created the binary that someone would cry foul if there were a conspiracy going on.

Given which other types of trust are extended when assuming that non-assumevalid sync is trustworthy, I am confused when people posit that 

bitcoin

bitcoin_beginners

Are we all running SPV nodes?

`assumevalid` does all checks except script validation. Among other things, it verifies that the transaction bytes hash to the txid, and the Merkle root commits to all txid in the correct order. It checks that every block header commits to the previous block header, and that the assumevalid block is in the header chain. It also rebuilds the UTXO set from scratch. With that you are guaranteed to have the same blockchain byte-by-byte up to the assumevalid block as the rest of the network had when the `assumevalid` block was defined. Otherwise, the assumevalid header would not be in your header chain. To arrive at a different UTXO set, you’d have to interpret a byte-by-byte matching transaction differently than the rest of the network.
If your software were to do that, it’s broken, but (maliciously) broken software could also mislead you in any other number of ways. That’s why you should always check the signatures on the binary or build from the source code yourself, but even then you trust the people that created the binary that someone would cry foul if there were a conspiracy going on.

Given which other types of trust are extended when assuming that non-assumevalid sync is trustworthy, I am confused when people posit that `assumevalid` is a significant step up in trust.