Nuh on Nostr: 1. Run and SPV node. 2. Do NOT accept a tip that is too old (wait until you get a ...

1. Run and SPV node.
2. Do NOT accept a tip that is too old (wait until you get a header with timestap that at max 10 minutes older than your clock).
3. Wait until you get 6 confirmations.
4. If you see the latest 6 blocks taking too long, actively look for more peers and see if there is a fork.
5. If there is a fork with significant number of blocks, HALT and tell the user to go check what the fuck is going on.
6. If you can't find a fork but your chain is taking too long, HALT and tell the user to go check what the fuck is going on.

That is probably safer than fraud proofs, because... If the valid chain is a 10-100x weaker than the invalid chain... Maybe you just need to let the human intervene, instead of trusting code at this point.

quoting
nevent1q…dq9z

Unpopular opinion; a full node enforcing Segwit is more likely to find itself on an fork than an SPV client ... I know this is insane to say, but it is true, If enough economic nodes decided to run older bitcoin core versions, miners can safely mine an invalid block according to segwit, and the full node will reject it, but the SPV will just follow the heaviest chain which after 6 blocks is very likely representing the economic majority, and definitely after 100 blocks, or 2016 or whatever threshold that makes you feel safe.

At the very least, full nodes should halt receiving funds if they see sudden drop of difficulty or significant block time lag... But... That is also what SPV clients should do.

Literally all boils down to; heaviest chain is the only objective proxy for consensus and if that doesn't work you HAVE to manually intervene and make a judgement call.