Time attack without fork protection proposal

groll

around block 53896 for around 100 blocks we got a non forking time attack demonstration.
what happen:

the attacker with more then 51% was able to keep in the chain a timestamp way in the past, this is possible as long as the median of the last 11 blocks are under the time of the new block.
we also know that putting block 2h in front cause issues and 11 should be greater to something like 47. and this in an interval in the future (currently 2h, and is looked to possibly be changed) will be name time window

the proposal is to add a simple condition that prevent block with previous block time - 1.5 * window to be inserted. so if previous block is time window in the future a block with 0.5 window in the past would be accepted but no more so a block can’t be 1.5*window in the past, yes this is a bit big, but at least limit it and remove the 24h using fork to be done this way as it is possible to make the time to drift to 24h this way right now.

why 1.5 in fact it should be greater than: time window + adjusted time. so it’s

time inconsistency exist and the chain should keep its resilience to it, but 5 to 10 minutes should be acceptable range, actually client can be adjust as much as 35 minutes and accept block 2h in the futureand from the median time of the 11 blocks preceding it…

what are the current values
adjusted time:35 minutes
time window:120 minutes
number of past block to check for past time median: 11
past block min time= median of the preceding blocks

adjusted time must be lower then window and has been discuss in Bitcoin forum to open some possible but difficult to exploit vulnerabilities if below a factor of 2. As difficult in Bitcoin often means possible if near 50% hash power, we should stay on safe side and have it greater then a factor of 2.

proposal
adjusted time:35 minutes
time window:120 minutes
number of past block to check for past time median: 47
past block min time= upper of (median of the preceding blocks, preceding block time - 2* time window)

wrapper

Groll,

I agree with your analysis. You have identified a mode of failure. The cause of failure is the none optimum time window. The prevention technique is optimising allowed time windows. As this mechanism already exist it is an adjustment not a dangerous novel “Design Out” and less likely to develop unknown bugs. It is therefore an optimum solution. i.e. “easy” implementation and high probability of effectiveness.

It also coincides with other analysis that a stricter time algorithm would be help prevent attacks. My other analysis also shows it would be helpful to damp out significant swings in Hash rates (where blocks can be overproduced at incredible rates).

It would obviously need monitoring and any detecting presently unknown effects (say on Hash power movement).

Well done.

ghostlander

[quote name=“erk” post=“27477” timestamp=“1378540607”]
Here is a paper on time attacking bitcoin: http://culubas.blogspot.com.au/2011/05/timejacking-bitcoin_802.html

The proposed solution is to use Internet NTP timestamps, not coin network agreed timestamps. The inaccuracy of coin timestamps has always annoyed me, it creates a barrier for writing error handlers to weed out invalid blocks.
[/quote]

Seems a good idea. Although NTP servers can be DDoS’ed, so there must be a fail safe solution implemented involving network time, system time and NTP.

groll

first the client time and block time need to be differentiate. the timeadjusted is the client time. so it validate the block time it would accept with the time windows describe in previous post.

why we need windows is because time for each client is different even with ntp we would have latency and other networks stuff that will make time window necessary. kerberos, windows and many other usually allow ± 15 minutes difference. you need to accept time drift in any distributed system.

the block time is set by miners at block creation. so they mine on it and then release it the header of the block is pre-calculated including the timestamp and than the mining for it start. so the block would likley be in the past by some times (usually few seconds). tis timestamp in theory also comes from the timeadjusted.(an attacker can put any timestamp he wants)

using NTP as several issue.
the biggest one is DNS poisoning (the ntp pool address is redirect to fake ntp so your client go to the wrong ntp server). the link below explain why and some part of the solution, but this is way from trivial to put in place correctly
http://security.stackexchange.com/questions/4981/is-ntp-vulnerable-to-dns-poisoning-or-spoofing-attacks
another one is ntp source control in corporation. many organisation redirect the internal request to ntp to their own server(via firewall). their server then sync externaly

ghostlander

There are non-profit NTP servers such as [url=http://tf.nist.gov/tf-cgi/servers.cgi]nist.gov[/url], and we can even set up a few ours with IP’s coded in the client.

Bushstar

I can see huge issues introducing NTP as this would be a great chink in our amour. My biggest concern is if someone spoofed an NTP server, from global to localhost it could be a major concern.

We would have to use an encrypted form of NTP with the client holding a public key. Otherwise anyone can target the time server.

And there are many other ways to collect time. Like with GPS. No, I wouldn’t be scared of ddossing all the NTP servers. There simply are too much of them and they don’t all get their time from peers.

Wellenreiter

Part of the NTP protocol is, that the client can syncronize with several NTP server.

If more than one server is configured, it selects the one with the best stratum value.
If several with the same stratum are configured, the client will do a round robbin at every start of the NTP protocol.

This means, that an Attacker must spoof more than one server to be sure, that a sufficient number of clients are on the fake time.
Also as there are a large number of NTP server available in the Internet, and most people use NTP server located on their continent, it would be a huge effort to attack the network by spoofing NTP servers, as an attacker would have to spoof several NTP server managed by several provider/companies all over the world.

I don’t see a big risk here.