This is an elaborate version of a known attack vector, but one that is limited to a particular target, not the blockchain itself or the network as a whole. Basicly, it's another way to perform a double spend fraud against a particular node. There are many ways that a major vendor node could use to thwart this that are not mentioned by the article, probably due to lack of research on the author's part in this forum's thread history. One defense is mentioned in the article, but he largely dismisses it's value.

This is the 'blockchain watchdog' process mentioned in many prior threads. It does not exist, but it could. There are many signs that known attack vectors are underway. No, this would not necessarily result in an automatic response, but it could notify the user that something is wrong as well as suspend transactions on an ecommerce site.

"Use the median block chain time exclusively when validating blocks."

This is a client issue, and one that can differ between client versions. If a programmer wishes to come out with a version that does this, he is free to do so.

In short, this attack is possible, but very difficult even if the attacker is aware of any secret defenses the target may have already taken. Nor is it a threat to bitcoin itself.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

I'm surprised there isn't something more damaging that can be done if you get enough nodes to change a majorities time. It seems like all he gets is a small chance to put a few false confirms on one or a few nodes.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.

The complicated time handling in Bitcoin has bothered me for a while. Good to see somebody really explore this in depth.

It's one place where Satoshi took a shortcut. Nodes could just use pool.ntp.org to find the current time. If an attacker is able to control that, it means they control your entire internet connection and thus can fork you onto a separate block chain anyway if you aren't paying attention.

So clearly Satoshi intended to integrate NTP into the client at some point, he just never got around to it.

I'd rather we drop the median-time-of-peers technique. It leads to obscure and subtle attacks like this one. Theymos' suggestion is something that can be done easily for the next release, but integrating an NTP library would be the best long term approach because it's trivial to convince yourself the approach is correct.

pool.ntp.org is itself a peer to peer network. It's no different from LFnet in that sense. The DNS name is just a rendezvous point.

At any rate, somebody (a government) trying to hijack the NTP pool just to screw with Bitcoin would be an incredible escalation. All kinds of things rely on that service to work properly. Breaking it would have tremendous collateral damage, there are far easier technical methods of hurting the Bitcoin network. I don't think "somebody hijacks the NTP pool" is a scenario worth worrying about.

NTP + median peer time + system clock seems like the perfect solution to me. If two or more sources are in agreement within 40 minutes, use the average of those times. If all three disagree, ask the user to fix it.

Edit: instead of using the average, you could get a more accurate time by using NTP if it agrees, or the system time otherwise.

Accurate timestamping is basically free. If somebody were to hijack pool.ntp.org (which will never happen), Bitcoin users could switch to some other NTP pool. Bear in mind these timestamp drift attacks are only useful if one node believes the current time is different to other nodes, so changing the time reported by the NTP pool wouldn't help you (it would be detected very quickly though).

Satoshi didn't use highly reliable distributed service here, and it backfired by opening up obscure attacks. Simplicity is good.

Different nodes could get their timing from different sources. It's rational for an Android client to get it's timing directly from GPS whenever it can, and for servers to get their timing from ntp. Different methods of achieving timing mean that it's pratically impossible for this kind of attack to work, because how it is achieved is dependent upon all the nodes involved in the attack using the same timing methodology.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

The huge majority of stratum 1 NTP nodes are getting their feed from GPS, so trust in NTP is essentially trust in the US Government.

A huge majority of internet routers use NTP. A huge majority of the long distance synchronous optical links use GPS to synchronize clocks. To use the IP protocol is essentially to trust in the US Goverment.

Any sufficiently self-deluded internet cryptoanarchist is indistinguishable from a crackpot.

The un-deluded cryptoanarchist would probably research how to transmit bitcoin over shortwave radio. Or better yet, use VHF/UHF moon bounce (EME). It is the only way to be safe.

The huge majority of stratum 1 NTP nodes are getting their feed from GPS, so trust in NTP is essentially trust in the US Government.

A huge majority of internet routers use NTP. A huge majority of the long distance synchronous optical links use GPS to synchronize clocks. To use the IP protocol is essentially to trust in the US Goverment.

Any sufficiently self-deluded internet cryptoanarchist is indistinguishable from a crackpot.

The un-deluded cryptoanarchist would probably research how to transmit bitcoin over shortwave radio. Or better yet, use VHF/UHF moon bounce (EME). It is the only way to be safe.

IP has no concept of time, and routers only set their clocks so the logs are coherent when aggregated.

For what it is worth, I run NTP on everything that I possibly can, and I personally maintain two NTP nodes with GPS receivers. But I am keenly aware that for 99% of users, NTP time is GPS time (central authority), and not necessarily UTC (distributed), even though they are in total agreement right now.

I also patch my clients not to accept time corrections from the bitcoin network and think that the clock skew acceptance built in to the bitcoin network is insane. Or at least silly and out dated.

With regards to the suggestions of integrating NTP into the bitcoin client, I think it is a bad idea. The bitcoin client is simply not an appropriate place to put timekeeping software.

If I were emperor, I would make the client turn red if it thinks the local clock is off by more than 5 seconds from what the peers report, and refuse to run if off by more than 30 seconds.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

Some of these systems need a color worse than red, but I think 5 seconds is too tight. 1 minute would throw a blanket of most of them, and a popup message to the rest pointing them to instruction on how to fix their clock would suffice for the rest.It's interesting to note three are 1 hour, one is 2 hours, and three are ~24 hours off. I wonder if that is deliberate (run your computer in a different timezone so you now when to skype your grandkids), or a curious mistake.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM

With regards to the suggestions of integrating NTP into the bitcoin client, I think it is a bad idea. The bitcoin client is simply not an appropriate place to put timekeeping software.

If I were emperor, I would make the client turn red if it thinks the local clock is off by more than 5 seconds from what the peers report, and refuse to run if off by more than 30 seconds.

Some of these systems need a color worse than red, but I think 5 seconds is too tight. 1 minute would throw a blanket of most of them, and a popup message to the rest pointing them to instruction on how to fix their clock would suffice for the rest.

In light of a global system capable of keeping every clock on or near the planet (maybe even in the entire solar system) synchronized to within a dozen milliseconds or so, I would say that a 5 second skew is evidence of a serious error.

It's interesting to note three are 1 hour, one is 2 hours, and three are ~24 hours off. I wonder if that is deliberate (run your computer in a different timezone so you now when to skype your grandkids), or a curious mistake.

Both. Computers are capable of displaying the time as an arbitrary offset from the system time. If the system time is wrong, that is a mistake, even if the reason it is wrong is because someone did it intentionally.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

It has an option in the settings which allows a user to specify if their host is using NTP and to trust the system time. For systems that havent taken the time to configure ntp, the default behavior is to perform time synchronization with the network. This is the best of both worlds. Disciplined admins can make sure their clock is not pulled off by an attacker, while other hosts that are possibly misconfigured would default to syncing with the network. With many hosts using NTP, the rest of the networks time should drift closer and closer to the correct time.

This of course would not protect a host not using NTP from having a time attack done on it individually. But individual hosts are not protected from DDoS attacks or most of types of flood or packet attacks either.