The problem is not having or not access to a honest full node. The SPV client MUST have access to a honest full node sometime.On 04/27/2014 05:36 AM, Sergio Lerner wrote:Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks.I argue that you cannot talk about "the most-work chain" without actually making an assumption about honest peers.I should have said "without invoking moon math or interactive protocols requiring honest peers over jamming-free networks." The interactive protocol was more the point than the honest peers and jamming-free network. Yes, without an honest peer and an un-jammed network, you might never learn about the most-work chain in the first place. But having the security of the proof not depend on query access to an honest full node is absolutely necessary for some applications and certainly desirable in others.
First let’s review the main security assumption of headers-only SPV:
This means that there is at least a single connected peer that behaves honestly. This assumption is quite strong and may not hold during short periods of time, such as during application power-on (when only a few peers have been connected), or when moving to a place where the ISP is untrusted. For SmartSPV we’ll require weaker security assumptions:
This assumptions imply that the attacker may control all your
Internet connections while he sends you a malicious block branch
containing a fake payment to you.
Since in my use case (SmartSPV) I proposed you start from the most recent block and go backwards, the attacker must compete in PoW with the real current difficulty informed.First this is a method that uses NPPs, not SPV proofs. Since the method chooses all peers that are synchronized (have the latest current block) then going back means only skipping a potential short fork (which I suppose has never been more than 3 blocks during normal network conditions). You're looking for a common ancestor, not the checkpoint. So the linear scan is actually O(1). The exact value can be approximated by the sum of the convergent infinite geometrical sequence of forking probabilities, which it's about 1.03 without considering selfish-mining, and probably less than 2.03 considering it.Unless you're connected to attacker nodes which are wildly divergent from each other. It's relatively easy to create a massive fake history of difficulty-1 blocks.
So you agree that: you need a periodic connection to a honest node, but during an attack you may loose that connection. This is the assumption we should be working on, and my use case (described in http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/) assumes that.If you assume honest peers things get very easy. But that's not a safe assumption to be making. With back-link block-history commitments, on the other hand, an interactive protocol allows you to do a binary search to find common ancestors, and have trust that the intermediate links actually exist.