29
It takes the median time of the other clients connected, but only
1. if there are at least 5, and
2. if the median time does not differ from system time by more than 70 minutes.
For specifics, we look at AddTimeData, in timedata.cpp.
Note: I have edited it down for length
void AddTimeData(const CNetAddr& ip, int64 nTime)
{
int64 nOffsetSample = ...
19
The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.
When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these ...
17
The root cause of this is that without a central authority, it's impossible to know for sure what the current time is.
The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may ...
11
From this blog post describing the timejacking attack:
Each node internally maintains a counter that represents the network time. This is based on the median time of a node's peers which is sent in the version message when peers connect. The network time counter reverts to the system time however if the median time differs by more than 70 minutes from the ...
10
As individual clients may have an arbitrary timeshift, the Satoshi client will use the median of its neighbors times alongs with its own time to find an offset to the local clock. This offset will then be used throughout the client wherever an accurate time is needed.
9
Nothing directly prevents it in Bitcoin, and indeed the attack has been demonstrated on testnet3 many times---it's the primary reason that testnet3 currently has almost three times as many blocks as Bitcoin, despite being launched several years after Bitcoin mainnet and with a something similar to[1] Bitcoin's 10-minute average block interval.
Indirectly, ...
9
The 32-bit signed integer timestamp runs out in 2038. But Bitcoin uses a 32-bit unsigned integer for the timestamp. That runs out it the year 2106. We'll have to find a solution by then, not by 2038. Since that is still a long ways off, there is no plan for changing the timestamps yet.
Whatever happens would not affect existing blocks. The same thing would ...
8
Solved. You can prepare transactions with a wait time and the standard client will accept them.
You can check some details in:
https://bitcointalk.org/index.php?topic=131443.0
Essentially, I have been able to create a raw transaction https://en.bitcoin.it/wiki/Raw_Transactions using bitcoind. Then, before signing, I could manually replace the bytes for ...
8
It allows the pool to avoid making new work for every single request. Instead, it just increments the time by a second and gives that to the next miner. Under heavy load (longpolls), Eligius might use the same work for up to 7,200 miners, meaning the last miner gets a work timestamped 2 hours into the future. This helps reduce stale shares significantly.
7
You can encode any arbitrary data using the Bitcoin script's OP_PUSH and OP_DROP commands. For this, however, you would need some custom Bitcoin client, as the standard one does not allow you to send messages like this.
Alternatively, you could just use the hash as a part of the generation of a Bitcoin address and store it in the Block chain by destroying ...
7
If you are literally referring to the "time" or "blocktime" property of a transaction within the blockchain, then this timestamp is in Unix format.
And if by "convert it to a meaningful value", you mean a human-readable format, you can use a unix command line (e.g. Terminal on OSX) to do a quick conversion:
Linux:
$ date -d @1395103695
Mac OSX:
$ date -...
6
Bitcoin miners can construct the block header, including the timestamp, however they want, as long as it adheres to the consensus rules. The shift you describe is well inside the 2 hour timerange, so it can be done when setting out to mine the block. It cannot however be done once the block is mined as the timestamp is part of the header, which is hashed ...
6
Transactions don't have a timestamp. Blocks have a timestamp. The difference is important, because the block timestamp on some of the blocks changes the difficulty.
Why is the maximum difference two hours?
It's not particularly important to have very accurate timestamps. Timestamps have two uses:
Difficulty retargeting
Calculating progress of ...
5
One way to insert an arbitrary SHA-256 hash into the blockchain is by using it to generate a Bitcon address, then sending a very small amount of Bitcoin to that address. The Bitcoin wiki does a good job of covering the actual process of generating an address from an ECDSA private key here and here.
If you'd prefer not to have to perform the computation ...
5
For those of you who are wondering what TimeJacking is, please consider the following:
In order for computers and machines, separated by vast distances, to work in tandem, they usually have to be synchronized. If the time and date aren't isn't synchronized, this can lead to issues relating to security, usability, and overall response time. According to NTP....
5
The timestamp exists so there will be a permanent record of when the block was found. The timestamp needs to pass some sanity tests for the block to be considered valid.
One of the key uses of the timestamp is in calculating difficulty retargets.
5
There are several things you could mean by the time of the transaction:
When the transaction is created
When the transaction is known about by 90% of the network
When the transaction is first included into a block
When the block is known to 90% of the network
We can't know 1, because it could have been generated offline, and there's no time field. You can ...
5
Ripple times are seconds since 1/1/2000 00:00 UTC. You can add 946,684,800 to a Ripple time to convert it to a UNIX time. If you are writing code to convert from Ripple times to UNIX times, please do your math in a 64-bit variable, not a 32-bit one.
5
A miner applies their own timestamp to a block.
Nodes add the first block they receive to the top their chain. They will not replace the current tip of their chain with a newly received block just because it has an earlier timestamp.
Therefore, you can think timestamp is a rough indicator of when the block was formed by the miner.
From bitcoin.it/wiki/...
5
BIP 113's goal is not to aim for a specific offset.
Its goal is guaranteeing monotonicity (treating every block's timestamp as strictly larger than the timestamp of each of its ancestors). It does this by leveraging the existing consensus rule which states that the median of the timestamp of a block has to be strictly larger than the median of its 11 ...
5
I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".
The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.
A block's timestamps must:
Be greater than the median of the past 11 ...
5
The blog you linked to talks about a fairly sophisticated attack, involving large scale network manipulation.
The basic premise is:
You are able to identify the node that belongs to the person/entity you want to execute a double spend against
You trick that node into thinking that the network time is far behind what it actually is (up to a difference of 70 ...
4
First, where do these time samples come from: when your client connects to peers in the network it exchanges a version message with them. Among other things this message contains the current UTC timestamp at the peer. Your client then calculates an offset between the time at its peer and its own clock. The network time is simply the local timestamp + the ...
4
Transactions do not have a time per se. They do have a lock_time which is currently not used anyway.
Blocks do have timestamps, bytes 69-72 after trimming the protocol headers and checksums. Some may say that a transactions time is the time of the block that included it.
Another interpretation (the one used by blockchain.info) is simply the first time the ...
4
Yes, the miner can increment the time stamp by a limited amount, but only if the pool advertises X-Roll-NTime as a feature. DiabloMiner and CGMiner both support this.
See the official spec for more information.
4
It's checked in the IsFinal() method of CTransaction. A non-final transaction cannot be included in blocks.
A transaction is final if either:
The lock time is in the past.
All of the inputs have sequence numbers equal to UINT_MAX.
The second one is probably what confused you.
4
OK. This got interesting quickly. I have built a small block explorer and have found 5 transactions with high nLockTime values in blocks:
http://blockexplorer.com/rawblock/000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c
http://blockexplorer.com/rawblock/000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05
http://blockexplorer....
4
The first confirmation was in block 298902, so the third confirmation was with block 298904, which is timestamped as 2014-05-03 09:42:49 (66 minutes after it was first received).
However, this timestamp is later than the one in the block after it, suggesting that a timestamp was pretty far off. As Matthieu's answer shows, blockcypher.com's API includes the ...
4
The simple solution is a soft fork that requires each block's time be equal to or greater than the time of the previous block on the block chain. That is, time on the block chain can't go backwards.
If time can't go backwards, then the attacker can't artificially lower difficulty except by mining blocks with times in the future, and the network already ...
4
When there's a re-org of the chain of several blocks, isn't the total chainwork of both chains compared?
Yes, that's true. In fact, that's how a reorg of any size is considered. However, that wasn't always the case. In the first version of Bitcoin, the client compared purely by chain height. In version 0.3.3 (released July 2010) we switched to comparing by ...
Only top voted, non community-wiki answers of a minimum length are eligible
