30
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 = ...
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 ...
11
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 ...
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
There is no requirement that blocks have a timestamp after the previous block. The only requirement is that the timestamp is greater than the median timestamp of the last 11 blocks. So this means that a block can have a lower timestamp than its parent, within a certain bound.
This happens because miners do not have perfectly in sync clocks. There can be ...
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 ...
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
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
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
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
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
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
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
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
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
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 ...
4
Testnet is frequently attacked, abused, due to the complete lack of value and proof of work. A piece of code which is intended to allow a difficulty 1 block is none has been found in 20 minutes also enables a person to "warp" forward and mine multiple in a row. If this is exploited over the difficulty adjustment, the entire chain difficulty is reset to ...
4
Extremely creative question. Most of UTF-8's answer is correct. I'd like to observe a few consequences:
If someone brought a future blockchain to current reality and even 11 blocks were immediately accepted, you would have some serious chaos. People that didn't spend bitcoins from their wallet would suddenly see money they were going to spend in the next ...
4
The timestamp is used primarily for establishing the difficulty. Without a timestamp, new nodes would not be able to determine the correct difficulty to be used for each 2016 block period as they wouldn't know how long it took to mine those blocks. So that everyone calculates the difficulty correctly, the block timestamps are used instead of real time.
...
4
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
The above is actually Bitcoin Script, not just byte data.
This breaks down to:
04 # PUSH the next 4 bytes
ffff001d # This is the same as the nbits for the block, which was the target for the ...
Only top voted, non community-wiki answers of a minimum length are eligible
