16
10 minutes. Assuming, as you say, that the current network hashrate matches the difficulty - otherwise it is proportionally higher or lower.
Block finding is a Poisson process. The rate parameter λ is chosen so that 2016 blocks on average are found every 2 weeks, and since in such a process the expected number of events is proportional to the time span, it ...
11
I'm not sure it was. When the network started operating (and Satoshi was pretty much the only one mining), blocks weren't found every 10 minutes. For example, the first 2016 blocks were found in 24 days rather than 2 weeks. Normally this would cause the target to go up but it can't go above the hardcoded max target, so only in block 32256 in December 30 2009 ...
11
Excluding complications like difficulty changes and temporary blockchain splits, you can model the block generation time as an exponential distribution.
An exponential distribution has a standard deviation equal to the expectancy value. This predicts a 10 minute standard deviation for Bitcoin.
Measuring the actual distribution isn't that easy. While each ...
11
Most likely, you'll have to download all the block headers. The easiest way is to get them here. Note each block is 80 bytes so it's roughly a 30 MB download.
Next, what you're going to need to parse these block headers and make an array of timestamps. You can then write a program to parse these block headers and find the 3600-second interval that produced ...
9
I found that part of the wiki frustrating too, and I just edited it. I'd appreciate corrections. Here's what I wrote:
Ten minutes was specifically chosen by Satoshi as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then ...
9
I wrote a program that extracts the blockchain into an SQL database and ran a query. The answer is that block 152218 followed block 152217 after a delay of 1 hour 39 minutes 7 seconds. This was the longest inter-block interval in 2011. There were many longer interval in the early history of the blockchain, often multiple hours or days.
Edit: I also find it ...
8
The variability is exactly the same no matter the difficulty. It is always an exponentially distributed random variable with mean 10 minutes (the mean could be slightly off if hashrate mismatches difficulty).
What we may see in the future however is a reduction in variance due to decrease of the block reward. As transaction fees become a more significant ...
6
One problem is that lower block times mean an increased chance of forking, which makes head of the chain, and the system, less reliable.
Another problem is that it normally takes a block a few seconds to a minute to propagate across the network. Proportionally that time becomes a lot higher with a decreased block time, giving the original miner and miners ...
6
GHOST is outdated, the more relevant protocol based on recent research by Aviv Zohar et al is called "SPECTRE" - https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5, https://eprint.iacr.org/2016/1159.pdf.
It has many advantages over the traditional longest-chain rule of Bitcoin, but:
It requires a hard fork, something which has never been done ...
5
The shorter the blocktime the more time is lost by the relaying of blocks in relation to the average blocktime. A very short block interval therefore makes SPV mining (i.e. mining empty blocks without transactions) more attractive, and increases the advantage of large pools, because they can start mining on top of their own block the quickest.
Additionally, ...
5
In the very early days of Bitcoin the time between blocks could vary a lot since there were so few people using it (so the total hash rate was very unpredictable). I'm pretty sure the biggest gap would be between block 0 and block 1 (5½ days), probably because nobody was mining.
5
Any mining device can be used without alteration for mining a specific alt-chain, as long as the chain's proof of work is the same (double-SHA), and the size, encoding and position of the timestamp and nonce fields is the same in a block. The latter ensures that devices that increment those fields internally would not be altering other parts of the block ...
5
The network difficulty is recalculated every 2016 blocks. The difficulty is adjusted based on the duration of the most recent 2016 block interval. The difficulty can adjust up or down at most by a factor of 4.
Currently, the network is growing rapidly. The network finds blocks at a faster rate than one per 10 minutes because the current difficulty is ...
5
Block time is a tradeoff between:
Network propagation time
Amount of work wasted due to chain splits (miners continuing to work on the last block before becoming aware a new one was found)
4
There are a few things to know about the frequency of blocks:
Every hash has the same chance of finding a block. So, times between blocks are randomly distributed.
The difficulty (i.e. the expected number of hashes required to find the next block) is only adjusted every 2016 blocks. With ten minutes between blocks that would be every 14 days. However, since ...
4
The probability of 90% of miners suddenly stopping mining bitcoin is only slightly more probable than the chance of the sun going dark this afternoon.
Anyway, supposing that 90% of the active bitcoin miners were to suddenly vanish, the first effect would be that blocks would take much more time to be confirmed (10x longer, so 100 minutes per block instead ...
4
We don't have to wait until a block is full, instead blocks are created in a random process. Whenever one is found, the miners directly try finding the next one. This takes roughly ten minutes, regardless of how many transactions are waiting to be confirmed.
So, we'll all be waiting for the new block.
4
Since current hashrate and current difficulty level should be matched up usually, we can disregard them. (Although, we could easily accommodate them if they are diverging as well.)
Finding blocks is a Poisson Process.
The chance to find at least two blocks in ten minutes is "all cases" excluding the cases where we find 1 and 0 blocks: P(2+) = 1 - P(1) - P(...
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
To make it simple:
Mining consist on finding a specific block that once hashed gives a value bellow a certain threshold (the target).
The target is recalculated every fixed amount of blocks (2016), so that it is refreshed every two weeks (at 1 block per 10 minutes rate).
When recalculated, the total network hash rate is taken into account, so that ...
4
First off, it is worth noting: this paper is not only talking about throughput in the 'transactions/second' sense, it is also addressing the effects of block size and interval on the network's latency (which is an important factor in scaling blockchain networks). The authors define 'effective throughput' as:
Our results hinge on the key metric of ...
4
(This data is current through block 535276.)
Based on block timestamps (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1. The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and 15324.
For "shortest"...
3
Blockchain technology, at least without accepting central party that controls access to the chain, inherently has slow blocks, or strong centralization incentives.
The reason is that blocks need to propagate much faster than the block interval time. If they don't, miners who are further away from the majority of the hash power are put at a disadvantage.
To ...
3
There was a coin called Flashcoin that tried to do 6-second block times. I don't think that's being actively mined anymore as another Flashcoin appeared a year later (60-second block times).
Ethereum is planning a 12-second block time. Vitalik makes an argument for why that's probably the minimum for now here. Of course, ethereum hasn't been released yet, ...
3
I have found the answer in this article by Meni Rosenfeld, page 7. The problem should indeed be modeled with a Negative Binomial distribution, and the computations done on Satoshi's paper are approximations.
The fact of matter is that the quality of the approximation does not rely on the expected high number of trials required to mine a block, but in the ...
3
If by "instantaneous" you mean "right at the moment of the transaction" - well, no. Not even with Visa et al. Even if you mean that, after waiting for a reasonable amount of time (say, less than 2 mins.) you receive a definite answer about your transaction's validity, it's not possible either.
The way cryptocurrencies work, all transactions are "waiting in ...
3
It probably comes from the fact that the mining power always increases; the recomputing of the target is done on the last 2016 blocks, but the mining power of the network is always higher the next 2016 blocks than the last 2016 blocks.
Therefore, the average time is actually shorter than 10 minutes, because the hashpower is always rising.
3
You couldn't make functional Bitcoin-like fork with that fast of block mining. There is a tradeoff between speed of block creation and consistency of the network. In Bitcoin the blocks are created infrequently enough that the entire network can agree on the canonical blocks quickly and transactions can propogate quickly enough of that they tend to get ...
3
The major factor for pools is that if they do that, their blocks might get rejected by the network and the honest nodes. That would mean not only loss of profits for the pool and the miners, but also a loss of confidence. Both of those factors might result in the pool losing its miners and hashpower.
3
A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-...
Only top voted, non community-wiki answers of a minimum length are eligible
