Timejacking & Bitcoin | Bitcointalksearch.org

osmosis

sr. member

Activity: 300

Merit: 250

Quote from: kjj on September 22, 2011, 03:18:15 PM

If someone can't manage to get it installed and working, they have no business using bitcoin.

In a free world we do not have any control over who does or does not run the software. What we are trying to do is protect the network. Accurate packet time stamping is an important aspect of p2p protocols. We can ban or throttle peers who send msgs who's time stamp is skewed from our own clients. Maybe this is already implemented.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: 2112 on September 22, 2011, 03:09:35 PM

Quote from: osmosis on September 22, 2011, 02:50:18 PM

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

Probably correct.

I'm going to side with ArtForz and his idea of built-in SNTP for the Windows version of bitcoin. The native Windows NTP works well only in domains. For the regular Windows boxes that are just members of a workgroup there are multiple problems. Majority of those problems are caused by the various add-ons, but I don't know how many people run just bare Windows machines with software only from Microsoft.

The code to properly query the Windows Time Service would be more complex than just a simplest generic SNTP code.

Tardis 2000. If someone can't manage to get it installed and working, they have no business using bitcoin.

We should not write our own buggy implementation of NTP when other good options exist. Notice that bitcoin does not include an antivirus scanner either, but the same arguments that would apply to including NTP would also apply equally well to virus protection.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: osmosis on September 22, 2011, 02:50:18 PM

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

It would be great if you contribute it back to core so that others can enable it as an option.

It is trivial, and probably wrong. But in util.cpp, replace the GetAdjustedTime() function with:

Code:

int64 GetAdjustedTime()
{
    return GetTime();
}

When this came up on the mailing list the other day, I suggested that we scrap everything involving timekeeping in the client and protocol, and start over with the requirement and assumption that the local clock be correct. It wasn't a popular proposal, but I'm pretty sure it is still the right thing to do.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: osmosis on September 22, 2011, 02:50:18 PM

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

Probably correct.

I'm going to side with ArtForz and his idea of built-in SNTP for the Windows version of bitcoin. The native Windows NTP works well only in domains. For the regular Windows boxes that are just members of a workgroup there are multiple problems. Majority of those problems are caused by the various add-ons, but I don't know how many people run just bare Windows machines with software only from Microsoft.

The code to properly query the Windows Time Service would be more complex than just a simplest generic SNTP code.

osmosis

sr. member

Activity: 300

Merit: 250

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

It would be great if you contribute it back to core so that others can enable it as an option.

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

Probably correct.

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

gtk-gnutella has an amazing statics view in the user interface. It tracks 100's of variables. If similar data was just made available from the command line, I would write some munin plugins to graph the data.

osmosis

sr. member

Activity: 300

Merit: 250

Here is the time_sync doc for gtk-gnutella

https://github.com/gtk-gnutella/gtk-gnutella/blob/master/doc/gnutella/msg/time_sync

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.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: bcforum on September 22, 2011, 09:17:16 AM

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

Quote from: bcforum on September 22, 2011, 09:17:16 AM

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.

bcforum

full member

Activity: 140

Merit: 100

Quote from: kjj on September 22, 2011, 08:58:48 AM

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.

Code:

Added time data, samples 405, offset +0 (+0 minutes)
-86493  -86018  -3606  -277  -168  -121  -100  -98  -87  -80  -79  -75  -74  -60  -56  -54  -53  -52  -36  -36  -36  -32  -31  -31  -30  -29  -27  -26  -26  -26  -24  -24  -23  -22  -19  -18  -18  -16  -16  -16  -15  -14  -14  -14  -14  -13  -13  -13  -12  -12  -11  -11  -11  -11  -11  -11  -10  -10  -10  -10  -9  -9  -9  -8  -8  -8  -8  -8  -8  -7  -7  -7  -7  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -6  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -5  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -4  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -3  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -2  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  -1  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +1  +2  +2  +2  +2  +2  +2  +2  +2  +2  +2  +2  +3  +3  +3  +3  +3  +3  +3  +3  +3  +4  +4  +4  +4  +4  +4  +4  +4  +4  +4  +5  +5  +5  +5  +5  +5  +5  +6  +6  +6  +7  +7  +7  +7  +7  +8  +8  +8  +9  +9  +9  +9  +9  +11  +11  +13  +14  +14  +15  +19  +20  +20  +22  +23  +26  +26  +37  +43  +44  +45  +50  +59  +85  +87  +93  +96  +124  +126  +169  +189  +284  +311  +3596  +3687  +7217  +83428  +5654326511063269263  +5790349588594885090

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.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: 2112 on September 22, 2011, 08:35:28 AM

Quote from: kjj on May 28, 2011, 06:05:12 PM

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.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: kjj on May 28, 2011, 06:05:12 PM

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.

osmosis

sr. member

Activity: 300

Merit: 250

Quote from: Mike Hearn on May 28, 2011, 04:56:29 AM

but integrating an NTP library would be the best long term approach

How about config options to set which ntp server to use,
or even a setting to turn off time syncs and use host time if you have a ntp service already running locally.

MoonShadow

legendary

Activity: 1708

Merit: 1010

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.

kjj

legendary

Activity: 1302

Merit: 1026

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.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

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.

theymos

administrator

Activity: 5222

Merit: 13032

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.

theymos

administrator

Activity: 5222

Merit: 13032

It's still centralized. Someone controls pool.ntp.org.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

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.

theymos

administrator

Activity: 5222

Merit: 13032

With NTP we'd really need to reduce the max adjustment time, or else whoever controls pool.ntp.org could easily attack people.

Originally NTP was supposed to be used along with peer time. Maybe that would be better than relying only on NTP.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

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.

And sure enough, the source code says this:

Code:

net.h:
    void PushVersion()
    {
        /// when NTP implemented, change to just nTime = GetAdjustedTime()

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.

theymos

administrator

Activity: 5222

Merit: 13032

I think it is a legitimate attack, though it's difficult to perform. The max time the network is allowed to adjust your clock should be reduced to 40 minutes.

Topic: Timejacking & Bitcoin (Read 6046 times)