<p>Solution number 1 would mitigate this problem, but the attacker could try creating enough nodes to flood the network anyway (see <a href="https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes" rel="nofollow">cancer nodes</a>). It would not be likely that the attack would be performed, but it would still be possible.</p>

<p>Solution number 2 would help with this problem, although it would cause a lot more problems with everything else. Imagine the excess traffic caused by tens of thousands of Bitcoin clients dropping all of their connections each minute and reestablishing them with new peers. You would need to exchange a lot of information this way you wouldn't normally have to (version, verack and inv messages during each such reconnection at the very least). As the attack does not appear a likely threat for the Bitcoin network, such overhead would be unjustifiable.</p>

CC BY-SA 3.0
2012-09-25T22:21:38.987Z
Actually, solution number 2 ("peer rotation") is certainly a viable option, and I intend to implement it someday. Dropping a connection and reconnecting somewhere else every one or a few minutes should have negligable impact on bandwidth usage, and make the network much more dynamic.
Pieter Wuille
CC BY-SA 3.0
2012-04-28T19:23:10.457Z
2012-04-28T19:23:10.457Z
ThePiachu
<p>I've read about the proposed Timejacking attack:</p>

<p><a href="http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html" rel="nofollow">http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html</a></p>

<p>There are a number of solutions proposed, but it seems like there might be a simpler solution to make the selection of peers more random.</p>

<p>As I understand it, the attack relies on an attacker being able to connect to a specific target node.</p>

<p>Wouldn't either of the following two solutions work?</p>

<ol>
<li><p>Differentiate between input and output peers. Allow anyone to connect to you to receive information from you but only take information from peers that you connect to. This would make it very difficult for an attacker to have a large number of connections to a specific node because the node is randomly choosing which nodes to receive data from.</p></li>
<li><p>Continuously change connected nodes. i.e. every minute or so, disconnect from one connected node and find a new one to connect to. This would create a constant rotation of nodes that would make it much harder for an attacker to keep his/her connections to your node.</p></li>
</ol>

<security>
How could the protocol or client be altered to mitigate a timejacking attack?
Computerish
# How could the protocol or client be altered to mitigate a timejacking attack?

(Asked by: username_0 on 2012-03-04)

I've read about the proposed Timejacking attack:

<http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html>

There are a number of solutions proposed, but it seems like there might be a simpler solution to make the selection of peers more random.

As I understand it, the attack relies on an attacker being able to connect to a specific target node.

Wouldn't either of the following two solutions work?

1. Differentiate between input and output peers. Allow anyone to connect to you to receive information from you but only take information from peers that you connect to. This would make it very difficult for an attacker to have a large number of connections to a specific node because the node is randomly choosing which nodes to receive data from.
2. Continuously change connected nodes. i.e. every minute or so, disconnect from one connected node and find a new one to connect to. This would create a constant rotation of nodes that would make it much harder for an attacker to keep his/her connections to your node.

**Tags:** security


---

## 1 answers

### Answer by username_1 on 2012-04-28. Score: 1

Solution number 1 would mitigate this problem, but the attacker could try creating enough nodes to flood the network anyway (see [cancer nodes](https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes)). It would not be likely that the attack would be performed, but it would still be possible.

Solution number 2 would help with this problem, although it would cause a lot more problems with everything else. Imagine the excess traffic caused by tens of thousands of Bitcoin clients dropping all of their connections each minute and reestablishing them with new peers. You would need to exchange a lot of information this way you wouldn't normally have to (version, verack and inv messages during each such reconnection at the very least). As the attack does not appear a likely threat for the Bitcoin network, such overhead would be unjustifiable.

> **Comments:**
> **username_2**: Actually, solution number 2 ("peer rotation") is certainly a viable option, and I intend to implement it someday. Dropping a connection and reconnecting somewhere else every one or a few minutes should have negligable impact on bandwidth usage, and make the network much more dynamic.  

---

