For a while I wondered whether proof-of-stake is possible, or whether all attempts would suffer from the "nothing at stake" problem. About a year after my initial pondering, I found a solution after rummaging through old academic papers.
The problem as you stated feels like it should be solvable. The CAP theorem is not relevant here -- you're not bound by strong consistency because you don't need to provide connectivity 100% of the time. There is strong geographical stickiness in connections, so that looks like something to exploit. Combined with smart localized buffering of packets near the destination, it looks like a solution should exist.
The solution may not be compatible with your existing semi-centralized solution, which may be blinding.
Yeah. This kind of network also cannot truly be partition tolerant, not if the partition is between the two nodes that are trying to establish a connection!
The article is fairly vague - what is the risk of Sybil attacks exactly? (I looked at the FAQ, but it's sparse on details; only glanced at source.)
Is it some kind of spoofing? Since addresses are supposed to be collision resistant and tied to public keys, it should be possible to discard all messages regarding a peer that don't come from it. Although 40 bits is actually way too small...
Denial of service by pretending to be able to route to a user? Okay, but there should be some way to punish IP addresses that consistently fail to route things they claim to be able to... complicated, but not impossible.
Of course, I've only thought about this for 10 minutes, while the author has studied it for a long time. I'm sure they have more insight about the problems, but without more details I can only speculate.
If you allow the nodes themselves to determine which nodes are trustworthy (instead of a centralized solution), then an example Sybil attack would be a botnet with a huge amount of identities managing to either vote that Botnode12345 is totally trustworthy, and that all data should be sent to it, or that NiceGuyGreg, comex, peterisp and a bunch of other nodes "consistently fail to route things they claim to be able to". Both ways can make the system unusable.
priorities. the whitepaper draft was meant to solicit criticism. it hasn't been shot down.
there's no point trying to convince the general crypto community that believes bitcoin is the first solution to the byzantine generals problem. i'll fix that later.
The point I was trying to make is that bitcoin achieves very specific decentralization and security properties, properties which your system trades off. Your consensus mechanism may solve a problem, but it's not the same problem as bitcoin.
I would say that the security properties are different, with pros and cons for both. For clarification, Tendermint has strong security independent of external factors, while Bitcoin has simplicity but it is always vulnerable to an external attack -- this is what makes all PoW altcoins vulnerable. Tendermint has pretty strong consensus guarantees, but when it's broken, it's broken and requires manual recovery. Bitcoin has weaker consensus guarantees, as any blockchain fork could become a winner in the future (esp true if large miners form cartels), but it's not brittle and in the case of a fork, the winner can be determined (even for inactive participants) by shoving more work onto it. Finally, Tendermint does require clients to "hook-on" to the correct blockchain fork by a priori knowing a recent correct blockhash before syncing, which is easy to do in practice and only needed after a period of long inactivity.
But the problem is the same problem, and I would counter that the security is if anything stronger than that of Bitcoin. Ever since I studied pre-existing literature on consensus, I no longer see Bitcoin as you probably see it today.
The problem as you stated feels like it should be solvable. The CAP theorem is not relevant here -- you're not bound by strong consistency because you don't need to provide connectivity 100% of the time. There is strong geographical stickiness in connections, so that looks like something to exploit. Combined with smart localized buffering of packets near the destination, it looks like a solution should exist.
The solution may not be compatible with your existing semi-centralized solution, which may be blinding.