Bitcoin Forum

Pretty interesting, to say the least. It's been a while since I've seen a really large block time, so I think it calls to ask: What could lead to such a long wait?

bad luck and new mining difficulty

You just HAD to go and spend your millions of Bitcoin in a single TX.

http://en.wikipedia.org/wiki/Poisson_distribution

my understanding is that the difficulty is based off of how many leading zeros are in the hash of the nonce.
The smallest increase in difficulty is adding one additional zero, correct?  by what order of magnitude does this increase the difficulty?

Makes sense (trying to draw back to my required Statistics course), so is the reasoning found in the difficulty and luck calculations?

Bad luck, basically. :)

It really sucks -- it seems lately anytime I send a bitcoin payment, I end up on the block where it takes 1+ hour for a confirmation. I dread when I send a payment, and look to the see the last blocks at like "1 min, 4 min, 8 min" and then I know I might be in for a wait. Gambler's fallacy aside....

not really.  Poisson just describes distribution of solving time based on 10 min average and no dependencies between one block and the next.

http://en.wikipedia.org/wiki/Exponential_distribution

http://www.stat.berkeley.edu/~stark/Java/Html/ProbCalc.htm

variance.

10 minute block time is on average, sometimes 4 blocks can be found in 10 minutes, and other times 40 minutes can pass without finding a block.

it's a random process.

So essentially as long as it averages out to roughly 10 minutes the process works exactly as planned? Haven't actually looked at the source to see where variance is accounted for. Thank you for this.

It is expected that blocks will not be found exactly once every 10 minutes, but rather, on average once every 10 minutes. When the average block time goes under 10 minutes then the difficulty will increase and when the average block time is over 10 minutes the difficulty will decrease, this is check ever 2016 blocks

No, the difficulty is not adjusted in huge four bit increments (adding another zero), the difficulty is adjusted in much finer detail, read this:

https://en.bitcoin.it/wiki/Difficulty

The current target is here:  

http://blockexplorer.com/q/hextarget

and it is:  0x0000000000000000415FD1000000000000000000000000000000000000000000

"The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network."

So it must be less than or equal to the number shown above, until the next adjustment.

Oh, to answer your question directly "adding another zero" is a shift by 4 bits so it would increase the difficulty by 2⁴ = 16 times the previous difficulty = a 1600% increase in the difficulty.

thx Burt...yeah didnt really understand the article.
too much thinking for a Sunday :)

I guess my question is: whats the granularity of the difficulty changes?

"The largest legal value for this field is 0x7fffff"

The number has 6 bytes for the mantisa minus the sign bit so the minimum change is 1 part in 2²³ = a minimum change of about 0.00001192%

In other words changing the target from:

0x0000000000000000415FD1000000000000000000000000000000000000000000 to
0x0000000000000000415FD2000000000000000000000000000000000000000000

is a very tiny adjustment.

You call a 40min long ?

I have waited for hours before .

This isn't a surprise though, it happens.

+1


timecode of block here : http://blockr.io/block/list/


block 308511 and 308512 = 52min
http://media1.break.com/dnet/media/2013/8/11/8aed130a-4bda-43f4-ac9a-c7f5034458d6.gif

I am pretty sure that I read somewhere that the maximum the difficulty can increase each 2016 block period is (was) 4x the current difficulty

The more we hash... the longer it's gonna take. Crazy its at 40 minutes though.

I waited 40 minutes for a pizza once. now that was crazy.
BIP399 though says the blockchain will confirm your transaction
within 30 minutes or it's free.

True.  The maximum allowed increase in one adjustment is 4X.

The fee you pay the miners yet? 
just 0.0001 btc

The target is an average of 10 mins but we have exceeded that target now for a long time and we are ahead of schedule. The next reward division will be much sooner than what it was supposed to be.

+1 (at least)

I love it when people give the correct mathematical reason for the "long/short" block times.

There was a similar discussion not so long ago when there were 6 blocks in like 11 minutes.

As a note, we should be expecting "droughts" like this about once every 4 days (with using the average propagation time of 8 minutes as it has been recently). If the average propagation time was 10 minutes like intended, then it'd be once every 1.5 days.

Again with these super long blocks. 37 mins. 20++.

One quick confirmation is better than an unconfirmed transaction for 40 minutes. Even if ultimately it doesn't provide any more or any less security.

WTF?  What are you babbling about?  Confirmations = security.  There is no such thing as "one quick confirmation".  Confirmations happen when they happen by design.

I'm talking about quicker confirmations and the fact that the same amount of time needs to pass in order to achieve the same level of security. Like when using Litecoin(with it's 2.5 minute target) you still need 4x the confirmations in order to reach the same confidence level as one Bitcoin confirm .

One confirmation however is much, much better than zero confirmations and prevents Finney attacks. If you trust the network then one confirmation is enough, and if you can have that confirmation quicker than 10 minutes it's much better imo. Even if in the end it's not any more secure against double spend attacks that involve confirmations.

Do you see what I mean? If you were running a business and you decided that one confirm by the network to acknowledge the transaction was sufficient(despite the fact that it's never going to be 100% secure, you're accepting the risk) wouldn't you rather have that confirmation quicker than 10 minutes on average?

I just got done watching over 40 minutes to use a service after depositing. It's not a very good system.

I have seen a block found in 30sec and I have heard blocktimes as low as 2 seconds. It is only natural we get the other side of the norm too. There was a time I wonder whether it was possible that a block could not be found for a long long time, let's say days. The answer I got was there are so many combinations to the transactions, not ever finding a nonce for a solve is nearly impossible.

If we get more of these long blocktimes, difficultly may even drop, or not rise as much.

Then the answer is obvious.  You should use Litecoins.

I don't like Litecoin though. And I have no desire to use Litecoin. Nor would I want to buy a coin with such an obvious lack of development.

I use Bitcoin though and I would hope to see it improve over the years instead of stagnating.

OK.   So then are you suggesting a hard fork to reduce the confirmation time from 10 minutes?  What confirmation time would you prefer?  If you say 5 minutes then you will still randomly get very long confirmation times of over 5 minutes.  This does not seem to work.  What would work is to figure out a way to make zero confirmation transactions much safer and leave the protocol alone.

Does anyone know what led the devs to 10-min block times instead of shorter ones?

Bitcoin was designed to grow into a universal currency, used all over the world.

This means it needs to be able to reach consensus among miners located on every continent.

There unavoidable communication delays inherent to that process.

Satoshi picked 10 minutes to give blocks and translations time to propagate globally to reduce the amount of wasted work that occurs when somebody starts mining a block that has already been found.

Yeah, the main issue comes down to the potential wasted hashes. I definitely see the logic in it from that angle. But I think when you look at it from a users perspective and not as miners perspective it really makes sense to lower the block target in my opinion.

LTC only has confirmations after 2.5 minutes on average, LTC should have a 10 minute block roughly as often that bitcoin has a 40 minute block. Having shorter confirmation times will also mean a much higher orphan rate as miners have an incentive to build on their orphaned blocks to try to get them to be part of the longest chain to get their block rewards. 

Yeah, there will be more orphaned blocks which is bad for miners and is a waste of their hashing power. But even a 10 minute wait on the high end is much better than a 40 minute wait on the high end. It's a killer for some businesses. Unless there is a trusted third party system like coinbase or something that everyone uses that can make that a non issue I think it's a major problem.

I agree that the variance can be a major issue; but let's face it, most transactions now days are done virtually within minutes if not seconds;, which goes hand in hand with the fact that most businesses and consumers rely on fallbacks to ensure their security. Reconciling speed with the protocol will be one of the trickiest things and things may end up with a company like Coinbase acting as a "bank" intermediary.

[As a note, assuming normal block propagation times, the probability of a 10 minute LTC block is the same as a 40 minute BTC block, time duration though is drastically different with 9 hours for said LTC block and 1.5 days for the same BTC block.]

i wait for 30 minutes today to get 1 confirmations :(
the more we have hashing power, more we need to wait for confirmation, is it right?
not good if we use bitcoin for payment if we must wait for long time

Actually because the hashrate is going up at a fast rate the average confirmation time is below 10 minutes.  See:

https://blockchain.info/charts/avg-confirmation-time

The average confirmation time is actually about 8 minutes.

hmm i see
so ideally average confirmation time is 10 minutes
and then we see 8 minutes average for now, it will make we need more time to get another confirmation, right?
308764 - <1 minute
308765 - <1 minute
308766 - 9 minutes
308767 - 4 minutes
308768 - more time to wait?

Since the average confirmation time is less than 10 minutes that means the difficulty is too low. 

So what it means is that the difficulty will keep going up until the average confirmation time is 10 minutes.

Enjoy the shorter 8 minute average confirmation times while you can ;)

Eventually the growth in the hashrate will level off and the average confirmation time will be adjusted to 10 minutes where it should be.

so the difficulty based on this, i never know it ;D
if avg confirmation time is 8 minutes, the difficulty will increase to adjust avg confirmation time (to 10 minutes)
yeah i enjoy it if i made transaction on right time, i can get 3-4 confirmations easily after few minutes ;D
but if i get wrong time, i need to wait almost 30 minutes :(
thanks for your explanation

The lower confirmation times mean that the EV of mining is increased above what the difficult would indicate until the difficulty changes again

No the target time of 10 minutes per block is independent of the amount of hashing power.

And I agree that it's not good to have to wait so long for a confirmation.

Some transactions will not be confirmed in the first block after it is propagated to the network. 

Haha, indeed. Thanks for making us all others wait, jerk.

What about KGW? I know some alts got messed up with poor implementations of it but a solid implementation could make BTC better at hitting the 10 min mark.

Is this based on prioritizing the transactions by the amount of fee, or is it just that the transactions don't get put in the block in time? Or is it because the block miner is choosing to limit the amount of transactions they want to include in the block on purpose?

The miners and the pools are under no obligation to include any transactions.  They can, if they wish, and some pools and miners have n the past, just mine empty blocks.  They can cherry pick which transaction they want to include - that is their right.  They can include only transactions that have a profitable fee and drop all other transactions.  They can, if they feel like it, included a certain number of free transactions.  Luckily for "freeloaders" most of the larger pools will include a certain number of free transactions in each block they mine.

I think this is one of the flaws of Bitcoin. 

Yeah, but I'm curious the exact reason he was getting at about why some transactions won't be confirmed. It sounds like he might be hinting at another reason other than miner choice. The only other thing besides miner choice I can think of is blocksize limit. Which is why I'm wondering if there is something I'm missing.

There are indeed a large number of people who believe that the lack of ability to force other people to do thing is a flaw.

The reason Bitcoin is prospering so well is because they are wrong.

Having rules in a protocol is not really the same as 'forcing' people to do something. Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

This is not just a technical issue.  Try to propose a rule to force the miners to accept transactions.  What do you suggest?  They must include all transactions that pay a minimum fee set by???  You?  OR, they must include all transactions even if free?  Then nobody would pay a fee - or is that what you want?  They must include all transaction in the queue no mater how many?  They must include the 10 oldest?  Try it and you will find it is not a just a technical issue.

Freedom, with an economic incentive, works and is really the only solution I see.  Perhaps you are smarter than me and can come up with a way to codify your suggestion.

I didn't mean to imply that there was necessarily an issue with with the way transactions are handled by miners. I thought the original comment was conflating some sort of moral principle with an issue that's a technical one. Forcing people to do things or preventing them from doing things is the whole point of a protocol.

Free markets aren't flaws.

There are free market dynamics but its
not really a "free market" in the traditional sense.

The block rewards mean the miners
get paid regardless of the transaction fees, which
are a small part right now.  Also, if a
miner starts behaving badly, consumers
cannot choose to take their business elsewhere,
as you cannot choose which miners you want
to allow to include your transaction.  

While it is true that by excluding
transactions, a miner makes less money and
thereby becomes less competitive, it could
be done maliciously without a serious impact
on the bottom line, and certainly would be
a fatal problem if a miner ever got a 51%
monopoly.

This use of "51%" for everything under the sun is staring to really get on my nerves.  51% has nothing to do with this - at all.

What if they had only 47, 48, 49 or 50% and decided to mine only empty blocks.  SAME DAMN THING:  on average about half the blocks would contain no transactions.

10m is an average waiting time , 40m is still in the control  ::)

Was there not just a 1 hour and 15 minute block a couple hours ago?

Not really.  a 51% attacker can mine 100% of the blocks if they want by establishing the longest chain.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

This would increase the size of every copy of the blockchain and serve no purpose.

Receive almost instant payments with Bitcoin. However, there is an average delay of 10 minutes before the network starts confirm your transaction by entering the block and before you can use bitcoin you receive. A confirmation means that there is consensus on the bitcoin network that you received is not sent to the others and is still considered as your own. After your transaction has been entered in one block, it will continue to accumulate at the bottom of each block thereafter, which will exponentially consolidate this consensus and reduce the risk of aborted transactions. Each user is free to determine at which point a transaction has been confirmed, but the 6 confirmations are often considered to be safe as well as waiting 6 months on credit card transactions.

again with these super long blocks

The purpose would be to force miners to include a certain number of TX in every block they mine.

After thinking this over it sounds like it might just work.  What do some others (D&T, Greg, Gavin, etc.) think of this proposal?  I don't really see a downside to it off the top of my head.  It sounds reasonable to me, and most importantly, it does not appear to break any hardware, right?

forcing miners to put junk in? how does that force miners to include tx?

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

Yes, the size of the block is directly related to the average orphaned block cost to the miner.  The reason this proposal works is that it increases the orphan cost across the board for all miners.

Really? I thought I heard one of the devs saying it wasn't really true anymore. 
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

If it takes additional time for a pool to gather the TX and put them in the block when they find it, then there is a possibility that someone else could find a block and broadcast it to the network during that time. If a pool were to spend one additional second doing this then there would be a 1 in 600 chance that their block will be orphaned. 

I don't think that is an accurate way to describe the process.
Miners don't "put transactions into a found block."
Instead, the block itself is solved based on the merkle root of all the transactions.

I do not know if miners are selecting a
new pool of transactions periodically or
not as they are hashing, or how long it actually
takes to select transactions and calculate the Merkle
root, but these factors would give an
indication of what the bottleneck would actually be.
If it only takes one millisecond, it may not be a substantial issue.

This does not seem to work.

Don't know which dev you were talking to.  The cost of larger blocks is due to the propagation delays associated with larger blocks.  The cost formula is:


So 3.3 mBTC per kilobyte is the orphan cost.

Note that the current default fees do not cover this cost.  In other words fees already should be higher in order to cover the marginal cost of putting a transaction in a block, thus increasing the size of the block.

You can read more here:

https://bitcointalk.org/index.php?topic=339505.msg3648359#msg3648359

The whole thread is pretty interesting.

This doesn't seem to be going in a good direction for bitcoin. The transaction fees are getting too high too quickly. The block rewards are still high and adoption is just starting to take off.

High transaction fees combined with slow block times isn't very good. Wouldn't you agree?

The orphan cost is just an estimate and some other people (pool operators) have put the estimate at 50% to 90% less.   The protocol currently is rather inefficient.  For well connected nodes it would be possible to reduce the block message to just TxId which on average would reduce the orphan cost another ~95%.  If you reallllllly needed to reduce it more you could use reduced length hashes in the block message to reduce it 99.5% or more.  When you consider the cost of marginal bandwidth is continually dropping that means the orphan cost will also drop.   The orphan cost is also related to the subsidy and as the subsidy declines the orphan cost all declines.

So 3.3 mBTC is one estimate.  Other estimates are as low as 0.5 mBTC.  Lets look forward two years where available bandwidth has doubled, subsidy is halved and the protocol is using reduced length hashes in blocks (probably not necessary but since you seem worried).  That would be ~0.5 mBTC * 1/2 * 1/2 * 3/600 = 0.000625 mBTC per KB or ~6 satoshis.

So it's going to get better as the protocol evolves? That's good. Hopefully the dev team has time to work on major changes such as this.

Is ping a large factor? When two pools each solve a block is it often a matter of who has better ping as to who actually gets the reward? I don't mine so I'm not intimately familiar with these things.

Each user is free to determine at which point a transaction has been confirmed

Well we really haven't come back to the issue of how much to pass through in each block since the fork last year.  Since we appear to be slowing down on growth the blocks are going to be carrying more txns.

I've been doing quite a lot of analysis of hashing behaviour over the last couple of months and I've looked at a lot of the probabilities for various hashing events (the whole series is at http://hashingit.com)

75 minutes between blocks will happen more often that most people expect. Seeing no blocks in an hour should happen about once every 16.8 days (http://hashingit.com/analysis/27-hash-rate-headaches)

35 minutes and counting now. ::) I swear, it seem like every time I send a bitcoin payment, I'm one of the people stuck waiting an hour for a single confirmation. C'est la vie....

48 minute block time there, I was waiting for that one too. THEN the next block contains only ~500 transactions, not including mine. Now another 26 minutes and counting. Damn you, bitcorn!

40 minute BTC block time - No big deal

Actually, it is a really big deal (depending on your transaction/verifications), but this has been discussed thousands of times before:
Transactions are instant (usually even faster than credit cards), full verification/final posting takes ~1 hour, which is also much faster than credit cards.

Yep, mine missed that block as well. Now waiting 35 minutes. ::)

Just need one confirmation for my payment to Foodler, been waiting over an hour now. Like I said, every time, I'm one of these unlucky people.

As long as your transaction has been propitiated throughout the network and it includes a proper TX fee it will eventually be confirmed by the network

(propogated?)

Yes, but the point is, it's quite frustrating when a vendor requires 1+ confirmations, and you're waiting well over an hour. I'm aware that a tx with a miner's fee will eventually be confirmed. That's not the point. (Plus, tell that to those with transactions in an orphaned block!)

I've been lurking on this thread and just wanted to comment that the "No Big Deal" was meant sarcastically. I agree that it is a big deal. :)

Well that's not true. It's true that in terms of when the hash rate become too high (blocks are being found more often than every 10 minutes) there'll be an adjustment. But otherwise it doesn't matter, what 'we do'

It's only a flaw because mining has become centralized.

Centralization of mining into pools where the pool operator has incredible power of the flow is a major flaw.
It needs to be fixed.

Turned off my miner. Sorry guys

This is really bad, there have been four 2+ hour blocks in the last hour alone.

;)

Good one.

Anybody ever experience several hours?   Tried transferring .1 BTC from cryptsy to BTER  and still pending after many hours.  

I hope it goes through within 24 hours.    Searched the block chain and no activity with the address sent to.    Checked cryptsy and says  no confirmation,   pending.    

Hope this gets better.

(update)   canceled the withdrawal request as it was still pending after almost 6 - 8 hours or more.     Perhaps this is an issue with cryptsy.  Anybody else ever experience this?    We need to be more liquid than this.

I think you gave the best answer, Poisson explains it nicely. Even though it would be better for BTC if didn't happen.

Of course it was an issue with cryptsy.  If the transaction was submitted to the network, you would see it on sites monitoring the blockchain and be unable to cancel it.  Always best to manage your own wallet and not use a service.  Even then, you can easily have a problem if you send a really low priority transaction at a really busy time for the network.  I once tried to send bitcoin somewhere and forgot the fee.  They hadn't confirmed in 24 hours, so I went through the process of removing the transaction from my wallet and trying to let the network forget it only to find that it had confirmed a few hours later while I was waiting for the network to forget it.

Yeah, but we'd get 'incredibly' small block times during the next period. That's the beauty of an adapting difficulty!