(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.
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 ...
The time to produce the next block is completely unaffected by the number of unconfirmed transactions.
The time is generally expected to follow a Poisson distribution as explained in answers to a related question.
I'm no statistician so what follows may be nonsense:
A Poisson distribution with a lambda of 6 shown as a probability mass looks like this
So in ...
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 ...
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 ...
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.
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 ...
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.
Cryddit on Bitcointalk posted some source code that Satoshi supposedly emailed to him. This code contains a target interval of 15 minutes rather than 10. It is in https://bitcointalk.org/index.php?topic=382374.msg4108739#msg4108739. Search for nTargetSpacing.
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.
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 ...
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 ...
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(...
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 ...
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 ...
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 ...
In consideration of replacing the 1 block with N blocks in the same time frame, N > 1, I see the following points:
Expected time until first confirmation is reduced
Mining revenue is distributed smoother among pools
Capacity of network is increased
Smaller peak traffic than increasing blocksize by N
A hardfork is required to ...
The time T until a block is mined follows an exponential distribution. Assuming the difficulty has properly calibrated to the network hash rate, the rate parameter for T will be λ = 1/10 per minute. So the probability that the block is mined within t minutes is
P(T <= t) = 1 - exp(-t/10).
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 ...
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.
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 ...
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.
10 minutes is the average time between blocks that the network tries to attain (by adjusting the target/difficulty). It is not a fixed thing.
Due to the way mining works, there is a great deal of random variation in the time between blocks. A block may be found seconds after the last one or hours may go by between blocks.
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, ...
Let's think of blocks as a basket. Each transaction is an apple weighing 0.1 kg. You are the network. Currently, let's say we have a basket large enough to carry 1000 apples (10kg). As the network, it takes you around 100 seconds to carry this from point A to B.
Our throughput is 10kg/100seconds = 0.1 kg per second.
Now, we want to increase this.
I'm not the author, but found this code:
Top 10 longest (using timestamp in block header, which can vary up to 2 hours from actual time)
Block 1: 2009-01-03 463160 seconds (5 days, ~8 hours)
Block 15324: 2009-05-22 90532 seconds (~25 hours)
Block 16564: 2009-06-05 90390 seconds (~25 hours)
Block 15: 2009-01-09 87157 seconds (...
For a good portion of its history the bitcoin network has seen continuous increases in difficulty, which warps the average block time to be below 10 minutes until the next difficulty adjustment. If the reverse were true the block time would be longer in kind.
This latency serves to protect nodes against isolation attacks where you could otherwise ...