> Hi Eric, > > I disagree that SPV-during-IBD is "far more trustworthy." Sipa already > said this better than I could in the Bitcoin Core pull request discussion > but SPV by construction never validates UTXO state and instead trusts > hashrate majority for chain validity
In this thread on May 7th you wrote: >>> I can not refute critique of something that is not part of this proposal >>> except for pointing out that what you are insinuating is not something I >>> am working on or plan on working on and I am not aware of anyone working >>> on skipping IBD and I would not endorse such a proposal if it were to be >>> published. In contrast to some hypothetical dangerous future extension... On the Bitcoin Core pull request entitled "p2p: UTXO set sharing" #35054, the presumably same Sipa on May 20th wrote: >> So my question is: if we had the option of a assumeutxo with P2P sync, but >> without background re-validation, would that tilt the scales for commenters >> here, in one way or the other? The reduction in bandwidth, computation, and >> validation code complexity may make it more appealing. and in a follow-up post: >> I refer to the current approach of background validation of the chain prior >> to the pre-assumeutxo sync point as re-validation, because it is validating >> something that is already trusted to be correct anyway. I am arguing for - >> at least as a thought experiment - dropping that re-validation. That indeed >> means not validating it. >> ... >> The dual chainstate is only there for re-validation. I am suggesting not >> doing that. >> ... >> I think getting rid of the background re-validation actually improves upon >> that, by ripping off the facade that makes it seem like something better >> than a trusted hash in the source code. https://github.com/bitcoin/bitcoin/pull/35054#issuecomment-4501781606 Despite the fact that this is clearly a proposal (even if initially presented as a "thought experiment") to drop validation from your proposal, and that you said just 13 days earlier, "I would not endorse such a proposal". You are not only failing to reject it - you are quoting favorably from the very same post. You rejected this possibility as a "slippery slope" argument. > AssumeUTXO trusts the same code-review process that already covers the > consensus rules implementation. It is a different trust model and I > don't think one is better than the other. Who's review process? The Central Bitcoin Team? > SPV also has many downsides which are well documented... BIP 157/158 resolves > the privacy issues but still doesn't validate UTXO state. Which is why there is full validation. Assume utxo also does not validate the utxo state (it assumes it). So you aren't even suggesting a distinction. > Your point about wallet-complexity in the node goes both ways: SPV requires > a wallet to implement filter matching, Merkle-inclusion verification, > and SPV-specific message handling, while AssumeUTXO requires no wallet > changes. No changes are necessary to any wallets without this proposal. > I also don't see how the "very costly DoS" could happen. > If somehow a maleated snapshot wouldn't match that snapshot > can be replaced by the fully validated UTXO set but there is no scenario > where the full chain validation is wasted. If you trusted the wrong bros, and you actually validate, you will find out once you finish validation, and at that point (assuming implementation) you will have the correct state. However you will have to validate everything above the assumption, since the previous "validation" was based on an invalid assumption. So that portion of the validation is wasted. And all transactions accepted until that is completed are also verified only by SPV. > And, as I pointed out earlier, > I don't see one or the other model as more trusted and so I also don't see > the p2p as more or less trustless with this proposal. The proposal is fully trusting a central authority. SPV is trusting that majority hash power is kept in check by the majority of economy actually validating. These proposals of nobody validating beyond SPV shift the entire security model of Bitcoin (as I pointed out in my first post here and you rejected as a "slippery slope argument") to SPV *without the check*, IOW majority hash power control over validity. > Finally, you said "People already widely use SPV wallets and direct them > to their own full nodes for better security." If people already have their > full node then they certainly have no need for AssumeUTXO. So I think your > arguments just don't speak to the use case the BIP targets. My argument speaks directly to the rationalization for fundamentally changing the trust model of Bitcoin as matter or protocol specification. Nobody is suggesting that implementations can't keep shipping "assume valid", "assume utxo", "assume utreexo", and whatever other trust-centralized modes they can come up with. However this community protocol process must not be coopted into providing cover for trust-me-bro "consensus". > However, I'm not dismissing SPV-during-IBD as a potentially interesting > development that someone could explore. It's already in widespread use and suffers only from the terrible experience of having to sync up a node and then having to sync up an Electrum server, each of which can take days to weeks. Those are very solvable problems. Best, Eric -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1c4389e4-e38c-4080-b8a7-f2886d5b923cn%40googlegroups.com.
