13
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 ...
12
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
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 ...
9
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 -...
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, ...
7
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 ...
7
How strict are the time validation rules?
Very.
If the next block is mined more than 2 hours after the current block, would this not stall the blockchain?
No.
It doesn't break the rule "Full nodes will not accept blocks with headers more than two hours in the future according to their clock."
Nor does it break the rule "Must be strictly ...
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
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.
6
I think you have a misconception about what this clause means:
Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time ...
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
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
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.
...
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 ...
5
Blocks have timestamps, but they are not very accurate. The protocol rules only (roughly) require them to not be more than 1 hour in the past and not more than 2 hours in the future. At least historically, miners have used this flexibility, effectively turning part of the timestamp as an additional nonce field. I don't know if this is still common practice.
...
5
Yes, you can commit to data this way, but there is nothing special about Taproot here.
The Pay-to-Contract construction used to tweak the root key in Taproot is generally usable, and has in fact been used for exactly this purpose. In fact, it is one of the mechanisms used in OpenTimestamps to commit to timestamped data (including a variant sign-to-contract ...
5
My original understanding of mining is to pick a timestamp (the timestamp of when miners started mining) and then fix it.
There's no reason for that to be the case, as mining is progress-free. It is actually an advantage to update the timestamp in some cases, as it means that new proof of work can be attempted without needing to update the extraNonce value ...
4
Block timestamps are not very accurate and are allowed to be up to several hours off. It is difficult for a decentralized network to come to an agreement on an official time.
Reasons that it might be inaccurate are different system times, lag, and also miners often change the time by small amounts once they have tried all possible nonces. This allows them ...
4
There is a fair amount of leeway in the block timestamp. The timestamp for block N must be greater than the median network time, which is calculated as the median of the past 11 blocks, and also less than the network time + 2 hours, where network time is calculated based on the node's system time, as well as the median time reported by the node's peers.
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
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 ...
4
I think the question isn't so much whether this is possible, but whether this is desirable.
The block rate limit has several functions:
Keeping the stale block rate low, so that the effort a collusion attacker has to do is not much higher than honest miners (per block).
Keeping validation on non-mining full nodes feasible.
The second of these goals is ...
Only top voted, non community-wiki answers of a minimum length are eligible