2

I suspect that we CAN make them virtually impossible, but that we have not yet done so. We operate on the assumption that computing a private key from the public key is virtually impossible. We also operate on the assumption that computing a pre-image from a SHA256 hash is virtually impossible. We are comfortable with these assumptions because we have theoretical responses to handle their failure. We are prepared, but we are doing nothing to implement the changes required to handle failures of these assumptions.

We are, however, doing a lot of work to avoid the problems that a Sybil attack can cause. It would be nice if we established some prophylactics so that effort can be directed more toward improving bitcoin than toward handling Sybil attacks gracefully.

Specifically, we trust "the network" as represented by eight (or more, if you enable upnp) "random" peers that are part of it, but that trust only goes so far. We still (by default) validate every transaction in every block. We still haven't figured out how to compensate non-mining nodes for providing a route between whatever miner solves the next block and a peer who needs such a route. And we resist sharding the blockchain because we don't want to have to trust strangers.

It seems to me that the difficulty of progress in those areas would be significantly reduced if A)the software made Sybil attacks virtually impossible, and B)the virtual impossibility was well established through the natural and existing bitcoin education channels.

Some methods I've been pondering are:

  • How many valid blocks would indicate that you are connected to the entire network?
  • Has the difficulty been relatively stable?
  • Cycle the set of peers you're using.
  • Make it easy for a node operator to provide IRL contact info, as that would make a node far more trustworthy.
  • Validate peers by requesting known information, like the firstbits of the first transaction hash in the blocktip, or of a transaction that should be in the mempool. The bitcoin software would include instructions to get this, including a warning that a Sybil attack can include spoofing popular bitcoin data websites like blockchain.info.
Improve this question
1
  • It sounds like you're actually asking about eclipse attacks, not sybil attacks. Sybil attacks cannot be prevented entirely, because a sybil attack doesn't require the attacker to misbehave in visible ways. A sybil attacker can do things like extract information from the network while acting entirely like an honest node.
    – B T
    Commented Jul 27, 2019 at 18:45

1 Answer 1

Reset to default
3

Proof of work is what makes Sybil attacks very difficult. Put simply, you trust the chain with the most proof-of-work on it. This cannot easily be faked (at least without significant mining power). It is possible that all the peers you happen to connect to give you false information, but at any time, if you have even one peer that tells the truth, this can be determined cheaply and easily by seeing that the chain has more proof-of-work than the others.

Flooding the bitcoin network with nodes that don't tell the truth is possible, but as long as there are some nodes that tell the truth, it's easy enough to know which ones are telling the truth and therefore easy enough to thwart such Sybil attacks.

Improve this answer
5
  • I suppose that once your node has seen six blocks come in, the assumption is that it is safe because of the amount of work those blocks represent. However, this requires that the difficulty be near the well-known difficulty, which can be estimated from the hashes of previous blocks. Upon node-startup, is there any calculation like that to detect Sybil attacks?
    – Dave Scotese
    Commented Jan 5, 2016 at 21:58
  • Again, if all the nodes you connect to are from an attacker, there's nothing you can do. But if even 1 is legit, that should be obvious from the significantly higher POW in the chain of the legit one. You can't protect against a complete network takeover, but a Sybil attack is getting a majority of nodes, which you can protect against.
    – Jimmy Song
    Commented Jan 5, 2016 at 22:25
  • Are you saying that even with a calculation at startup, detection is still impossible, or do you just mean that even if you detect a Sybil attack, there's nothing you can do about it? I think you're wrong on both counts: Even if you have to call a friend to get a measurement (hashpower or difficulty seems useful here) to enter into your freshly started client, that would do the detection. And if the software allowed you to disconnect or ban a peer (temporarily or permanently), then that defeats the attack.
    – Dave Scotese
    Commented Jan 7, 2016 at 0:05
  • I'm not sure what you're talking about with "a calculation at startup". A Sybil attack would imply that an attacker with a majority of nodes would be able to fool you, an innocent node, in some way. Unless you're talking about some zero-confirmation double-spending attack, all transactions that you can get fooled by have to be in blocks. Those blocks need proof-of-work. And proof-of-work requires mining power and hence can't easily be faked. Thus, you won't get fooled unless the attacker has a lot of mining power. That's all I'm saying.
    – Jimmy Song
    Commented Jan 7, 2016 at 0:14
  • "A calculation at startup" would be, for example, to compare difficulty reported by peers to the difficulty recorded from the last time the node was up for at least six (or 100, or whatever) blocks. I can't think of others, but I'm sure there are some. I asked because nodes are valuable for connectivity even if they aren't mining, but compensating them for non-mining connectivity seems to be something that would be vulnerable to Sybil attacks.
    – Dave Scotese
    Commented Jan 8, 2016 at 4:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.