by Albert Szmigielski
- Timeouts based on the object size allow individual nodes to dynamically calculate and set a timeout that is most appropriate for the node. This would acknowledge the fact that not all nodes on the network are equal, and that they do not have access to the same resources, be it computing power, memory, or bandwidth.
- The adversary has no information about the timeout set by the node, thereby making it more difficult to mount the attack.
- Requires modification to the protocol, which is not trivial on a system wide basis. Of course individual nodes could implement it partially if object size can be either discovered or calculated.
- The attacker could play around with object size, that is provide an arbitrary object size to a node, therefore still allowing the attacker to force the node to wait.
Request block from a random advertiser
- Prevents the attacker from continuing the attack indefinitely, as after one time-out another advertiser will be contacted
- Possibly allows to establish a hierarchy of advertisers to keep track of the fastest ones to deliver objects in the shortest amount of time, thereby improving the node’s view of the blockchain
- adds yet another storage requirement, which may be an issue for resource constrained nodes
- perhaps the attacker can spoof being multiple advertiser, circumventing the countermeasure
Don’t rely on inv’s, send block headers instead
- Receiver can verify POW upon transmission of the block header
- Allows learning about new blocks on the network thereby denying the attacker opportunity to delay delivery of multiple blocks
- speeds up block discovery and propagation
- slight increase in traffic (80 bytes for a block header versus 36 bytes for an inv message)
- perhaps opens up a new attack where an adversary floods the network with arbitrary block headers thereby forcing nodes to verify these invalid headers (perhaps this could be taken care of in the accountability system of Bitcoin mentioned in the lectures)
Request tx from a random advertiser
- improving the node’s view of pending transactions and the blockchain
- as with blocks, this countermeasure prevents the attacker from hiding a transaction indefinitely
- again, as with the block case allows a node to rank peers based on speed
- the need to keep track of advertisers may be an issue for a node with limited resources