I'm comfortable that the core devs that are jumping ship have vetted it to their satisfaction, but then they also have an economic incentive to be satisfied with it as well.
There is not "trusted source" -> it works same as Bitcoin (what chain is longer ? chain with more PoW)
only roles will be changed. It is not miner who look for then longest sidechain. It is SC-user who must deliver list of HASH-es that proves he destroyed scBTC and now he can unlock BTC.
I think we are getting closer.
Help me to understand what the codebase is, upon which this SPV does its verification. Is it not the Side Chain?
So perforce Bitcoin must trust each of the side chains' proof mechanisms.
Side Chains may or may not be open source, and the source may or may not get decent analysis with each update.
The complexity risks are interesting in that they enable so many long cons.
SC-client will perform SPV proof
It is possible to verify payments without running a full network node. A user only needs to keep
a copy of the block headers of the longest proof-of-work chain
Using SNARKs he can create proof
1. that he "keeps a copy of ALL the block headers of the longest proof-of-work sc-chain" -> user will compress 80 M of sc-headers into few hashes
2. that this sc-chain contains transaction where he destroyed scBTC and this transaction is 2 days old
Edit:
It is not exactly what SC whitepaper say => how to compress SPV
How to compress SPV is detail :-) we can use SNARKs/SCIP to