pull down to refresh

This is his whole mistake in one sentence: you cannot maintain the same security guarantees if you trust someone to tell you the chain state at any point.

What if you trust you (or your family members) though? I serve my own SPV clients, and that of some family and friends (as a preferred node they connect to, I've given them wireguard peering to it). But my SPV clients only check from wallet birth.

Furthermore, I can validate the chain once and linearize it (and pgp sign it if I think someone will steal my USB drive), so that next node I launch, I don't need to download the whole thing again. With assumeutxo I can pair that with an utxo state, that I validated.

A feature can still be useful in trust model where you're the only trusted actor. The problem of course is that people narrate these kinds of things as a solution where you never validate the whole chain. That, is bad.

100 sats \ 1 reply \ @Scoresby OP 13h

But in all those cases, there is a relationship of trust with the person providing the actual validation...and as you point out, they did do the validation.

I have nothing against an SPV node. It serves a purpose. I think my argument is with secsovereign claiming that something like AssumeUTXO has the same guarantees as a node that actual does validation.

reply
204 sats \ 0 replies \ @optimism 13h

Yeah and I agree with you and Voskuil that that's wrong and I support the "not not spv" assessment, unless of course there's some magic proof like what zerosync has for headers, but iirc no one has done it for tx validation yet. Relatively, headers are "easy".

I also am quite sure that assumeutxo is meant to be a temporary solution. It just bootstraps a state that could be correct, and then validates towards that.

Without having a hash and a validation rule on the utxoset (like a utxo merkle mountain range commitment, much like the witness commitment) in each block, there is no way to do it in absolute safety - unless you made your own snapshot.

reply