,
5 tweets,
5 min read
Read on Twitter
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Maybe I'm missing something, but current thin client implementations either rely on a trusted server or connect to multiple nodes. So, you'd not only need to be served a fake block, but also get verification by other nodes to follow it. That means you need to be sybilled.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt BIP157 done right would first gather multiple filter fingerprints and compare them, then download the full filter if they agree. If they disagree, the would need to be back-off validation procedures. I don't see why such a validation couldn't include parsing the full block.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Obviously, a thin client doesn't have the full UTXO set, but many other rules could be checked on a single block. This would significantly reduce the attack surface and susceptibility to accepting chain tips with protocol changes.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt Likely, one would even go so far to validate the complete block (as far as possible) whenever the thin client receives funds. And even then, thin clients should wait for multiple confirmations to protect against a block referencing non-existent funds.
@giacomozucco @CarstenBKK @BlueDelta0 @StopAndDecrypt As to the question whether there is a market for thin clients, there most certainly seems to be. And if there are going to be thin clients, less shitty ones are better than completely broken ones. Claiming that worse thin client options drive full node adoption is tenuous.
