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 ...
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
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
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, ...
8
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
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
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 ...
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 ...
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 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
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 ...
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 ...
4
The system called timestamp server in the original whitepaper is currently more often referred to as a "miner".
They timestamp blocks, which combine several transactions, imposing an authorative order on these transactions. This is necessary as the system cannot otherwise decide which of two conflicting but otherwise valid transactions should be accepted.
...
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
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
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 ...
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 ...
4
If the nLockTime is less than or equal to the next block height, it can be included in the next block.
To explicitly answer your questions:
The CLTV op restricts the nLockTime field of the spending transaction, therefore if it is set in the past the condition is already fulfilled.
If the nLockTime field of a transaction is set to 500 000 it is valid to be ...
Only top voted, non community-wiki answers of a minimum length are eligible
