What happens if a new node syncs with a peer that has a corrupted UTXO set

Not sure if this is a silly question, but I gotta ask. Imagine a brand new node is trying to sync for the first time and it connects to a peer that has a messed-up UTXO set, like it’s corrupted or something. What goes down then? Does the new node figure out the UTXO from the blocks all on its own, or is there a risk it picks up the bad data from its peer? I get that full nodes check everything from the very start, but I’ve heard some folks talk about using UTXO snapshots or fast sync methods. If someone goes that route and the snapshot is wrong, does the node catch that? Or could it just keep rolling along, thinking everything's good while actually being out of sync with the rest of the network?

That is not likely to happen because the bitcoin node downloads the blocks from the genesis block and not in reverse order. If it is connected with a bad peer then it will detect the inconsistencies and automatically reject the connection with that peer. If the user is using a snapshot instead and if that snapshot consist of corrupted/bad data then it identifies that while background validation and will reject the snapshot and fallback to full validation instead. So in any case, the bitcoin node will make sure it is staying consistent with on-chain data and sync to it.

Here's the answer from Jameson Lopp blog. So the node would notice the UTXO snapshot doesn't match expected hash. I never tried using this feature, so i don't know whether it'll simply ignore corrupted UTXO snapshot or exit with error message.

The honest nodes will still have to validate this and if they have different hash they are ignore/rejected. At least this is the mechanism for the Bitcoin core which is more efficient than how other blockchain may process this. Historical validation are also made with the hashes.

Each node builds its UTXO set alone, the peer's isn't used at all and doesn't directly influence you.   If a peer has a corrupted utxo set the only influence it can have on you is that it might cause the peer to have rejected the most work valid chain,  so you might temporarily follow them onto a fork (one which is also consistent with a valid utxo set) but you will move onto the correct chain as soon as you are in communication with someone whose state isn't corrupted in a way that has made them reject the most work valid chain. If you manually accept a utxo set from a third party e.g. by copying their datadir, then indeed it might be corrupted without you knowing it.  The corruption will have no effect until it causes you to accept a block you shouldn't (which itself wouln't influence any of your non-corrupted peers, as they'll reject it when you give it to them) or reject a block you should accept. As per prior posts, there is apparently now also as "loadtxoutset" which can load a serialized utxo set which is checked against a hash in the software-- so it can only be corrupt if the software has been tampered with.

Aside from this based on the fact that nodes are interconnected, it will reject the corrupt UTXO set once it connects with other nodes thats where validation of UTXO sets come in. The idea is ,new node syncing from scratch will rebuild the UTXO set completely and from block 0 kinda validating every single transaction along the way. So Even if the peer it connects to has a messed up UTXO set it won't really matter. The syncing node will simply see the blocks from its peer and as it processes them it will build its own correct UTXO set from scratch. But If you use a UTXO snapshot you're kinda trusting that the snapshot is correct. The node may not be able to notice if the snapshot is wrong because it hasn't re validated the entire history. But If it tries to broadcast a transaction it will be dropped by all other nodes immediately.

1. So what kind of trust you're talking about? The blog i quoted earlier clearly stated it check whether the snapshot meet expected hash (hard coded on Bitcoin Core code). 2. If the snapshot is wrong/not expected, the hash should be different.

For example, if the author of the software you are running was held at gunpoint to release software with an incorrect hash -- then any utxo set it accepts via the load command will be a corrupted one, and would permit you to accept a invalid block and/or force you to reject a valid one.  A savvy attacker would try to get many economically significant users running a corrupted utxo set and then concurrently produce transactions that the faithful nodes accept and corrupted reject, and that the corrupted accept and faithful reject-- in order to split the chain, and try to get holdouts on the faithful chain to follow the economically significant parties on the corrupted side. I dunno if there is even any recorded process in place to validate the one placed into the software.  Unlike assumevalid, where you can just check if your chain has the block in question (or any block explorer if you want to trust them), there doesn't appear to be an easy way to do so-- you have to roll back your entire chain to that AUTXO point, which takes you out for a long time and you can't do if you're pruned (without doing the terabyte scale IBD download again, of course).  And given that, it seems on the last update only a single person has documented actually testing the value ( https://github.com/bitcoin/bitcoin/pull/31969 ).  Although perhaps other people did so and didn't record their success. As it stands I think it is a somewhat unsafe feature, though it's probably more unsafe for contributors to the project than it is for users, and the contributor unsafety is moderated by the fact that no one or almost no one uses this, yet. It could be improved a lot if at some predictable interval nodes all cloned off and background hashed their UTXO set and stored the result so that anyone running a node can trivial audit the value just like they can with assumevalid (which gets more people reviewing that the value is correct).  It would also be good if it got attested to in the same way the deterministic builds are, since the comparison ability is about as difficult as verifying the deterministic builds but with the added wrinkle that you have to have a node with an unpruned blockchain that you don't mind rolling back. When I created AV a big part of the logic was that it was utterly trivial to audit if it was correct-- anyone running an existing node could check in a fraction of a second with one command, and even non-node runners could check against explorers-- and that any tampering also had to be with a collusion of the majority hashpower... and if the software review / distribution was so vulnerable that it could ship an unfaithful AV value then the same vulnerability could just let it ship something with the script checking commented out as that would be even more subtle than an unfaithful AV value and not require majority hashpower collusion to do damage.   These arguments don't apply to the UTXO snapshots, they're hard to audit (arguably harder than the code) and don't require majority hashpower collusion to abuse so if anything the security process for them should be more strenuous.

I certainly didn't think trust from software side. But considering Bitcoin Core also have feature to generate UTXO snapshot file[1], the attacker probably need to manually add malicious/fake UTXO into Bitcoin Core code to ensure Bitcoin Core always generate corrupted/altered snapshot file and fooling basic check (e.g. compare hash of snapshot generated by Bitcoin Core and downloaded from internet somewhere). What do you think? [1] https://github.com/bitcoin/bitcoin/blob/master/doc/assumeutxo.md

Right which is why I said I think the specific functionality as it exists now (which I wasn't aware of until this thread![1]) is probably more of a risk to the developers than other users. It's currently mitigated because it seems few know about or use the feature, but if it were to become ubiquitous it would potentially paint a target on their backs of developers. It's not a hypothetical risk either,  we were already sued by a party essentially demanding edits to the UTXO set-- an event that contributed to multiple long time contributors quitting the project.   And as anyone knows a lawsuit doesn't have to have merit to cause a lot of harm, in fact they can be even more damaging the stupider they are.  It helped that there was no credible means to actually do what they demanded,  but as is this 'load a hash of the utxo set embedded in the software' has moved closer to that functionality (or something that could be confused for that functionality) existing. There also appears to be a new entity that thinks it can just claim to "take possession" of random older wallets.  Presumably their next step is to apply pressure either legally through lawsuits or extra legally through kidnapping, torture, or extortion to whatever parties they think can make their claimed ownership actual. -- I assume they have some plan to actually do so, otherwise why waste thousand of dollars on press releases and spam? [1] I knew of the assumeutxo work but I'd been expecting it to eventually get used by some more tamper resistant process, rather than just having some snapshot hash in the code that isn't even easy to verify.