Bitcoin Forum

Never mind the rubbish about blocksize. I've just been looking at blockchain.info and the block at height 404043 took 31 minutes to find. In the last 2 hours only 6 blocks have been relayed. With time intervals like this, Bitcoin has got no chance of mainstream adoption in the modern electronic age.

I assume that blockchain.info is reporting acurately.

yes, the transaction is real slow. the size of the block should be increased ASAP

Did you read my post? I'm not talking about transactions, I'm talking about blocks. Increasing the block size will just make matters worse, and probably create more orphan blocks.

This is what happens when people with zero understanding of the protocol starts talking about it. If you half block generation time, u'll increase the orphan rate, reduce block halving time and ultimately end up with an alt coin.

Well lets step back and look at that statement. I don't have zero understanding of the protocol, but I do have a limited understand I'll admit. It seems that most users, and posters on this forum, are in the same position. We are here to learn, and I hope that I will get some explanations as to why I am wrong, if I am wrong. Looking at Bitcoin from a commercial point of view, an average block interval of 10 minutes is way to long. This is regarless of any technical issues.

Now lets look at the technical point you made. Block generation averages a ten minute interval. That means sometimes it is a lot longer than 10 minutes, as in the two hour period I mentioned. Now the system will need to catch up on a period when generation had a 20 minute interval. That means it will need to run with 5 minute intervals for a while. This is the current system that will have to cope with that, and it doesn't seem to create more orphans. Of course halving the block generation time will create more blocks, so you would have to adjust the miners reward to compensate for this. I don't see why this would create an alt coin. It's still Bitcoin, and it is still using the current blockchain without any alterations.

Bit of exaggeration, but yes, in general shorter block times are considered less secure. But, as proved by multiple altcoins, it can work quite well. There's nothing magical about "10 minutes" (afaik).

@OP - some old discussion which you might find useful: https://bitcointalk.org/index.php?topic=232297.msg2446457#msg2446457

halving the block time will reuslt in more orphan, we already have a % of orphan so thi is not recommended

there is a coming improvement to this known as a subchain(not to be confused with sidechain)

Here is a quote by Aaron van Wirdum in the Bitcoin magazine

https://bitcoinmagazine.com/articles/everything-need-know-proposed-changes-bitcoin-block-size-cap-1440204699

It seems that the 10 minute interval was chosen based on the computing and bandwidth resources available when Satoshi proposed Bitcoin. (rather like the blocksize). Now that technology has moved on, isn't it time to review the block interval?

You need to change a lot of rules for that, fundamental rules, mess with difficulty, immediately halve the reward and then set up the new mining reward rules, also new debates how big the block size should be, keep 1 MB or also halve the block size, it's a huge can of worms...

It's better just use litecoin.

That is not how it works. If over a period of 2016 blocks the average block time is more than 10 minutes then the difficulty will be adjusted to bring the average back to 10 minutes.  The protocol does not think "oh, those 6 blocks were a bit slow, we'd better speed up for a few hours" instead it adjusts in quite long periods. Natural variation means that some blocks will be slower and some will be shorter - adjusting difficulty every 2016 blocks means that a lot of that variability is ironed out naturally.

Even if you changed to 5 minute blocks you would still get variability and some blocks would still be more than 10 minutes - what would you want to do then?

I understand all that. My point was that the current difficulty is set to generate blocks at an average of 10 minute intervals. Because it is an average, some 10 minute "slots" will be barren, and some will have more than one block relayed. I think I saw one interval that had 4 blocks generated within the 10 minutes. My point was that if the current system can cope with a 2.5 minute generation interval as part of its normal operation, then a change to a 5 minute interval can't be as difficult as some people suggest.

Then you will also understand that "occasionally" having 5 minute blocks is much different from "always" having 5 minute blocks (on average of course).

Rather than just saying "change this, it'll be OK" why don't you:

A) analyse the current orphans and cross-reference to the actual block generation times at the point the orphan occurred and

B) show how you will maintain security given a 5 minute block interval (where security is based on the principle of proof of work)

I was rather hoping that someone who is more knowledgeable than me could prove or dispove my comment. It seems that there has been a lot of discussion about block intervals over the years, and there are quite a few people supporting the concept.

I'm looking at it from a commercial point of view. An average of 20 minute for 1 confirmation of a transaction is too long in the 21st Century. At some time it will have to be reduced or Bitcoin will never get out of the playground.

First why do you say the average is now 20 minutes? Average block time is 10 minutes, and since you won't normally submit a transaction immediately after a block is solved, your average "wait" time for a confirm should be more like 5 minutes.

Secondly if the block time is "really" a commercial issue then why isn't Litecoin with 5 minute blocks the coin of choice for commercial users?  There is a solution right there, ready to be used.

Well that answers the previous post. 20 minutes is the time to get one confirmation. ie. 2 blocks.

0 confirmation is fine for faucet earnings, but if I'm buying 5 Bitcoins for cash in McDonalds car park, I would prefer to wait for a couple of confirmations at least. The same applies if I am accepting Bitcoin for the sale of a car.

You mean copy alts like Doge and ETH?  :)

No it does not mean Copy Doge or ETH. It only means that block size should be reduced to reduce the time
between transaction. Most of the people waiting for halving and thinking it will solve the matter, but i don't think so.

Let me clarify one thing. I believe in Bitcoin, and I think it will become the Gold standard of Crypto-currencies. To get there, it need an image enhancement, and to get out of the playground where people throw their toys out if they can't get their way, It also needs faster transaction confirmations and a planned scalability. Putting all your chips on a 2Mb dice roll, isn't the way forward. There are a lot of blocksize options that have been suggested - reduce it, increase it by factors between 1.5 and 64. Make it variable dependant on the transaction pool, vary it based on the hash rate. My belief is that a 512k size is optimum, but that will need to be coupled with a number of other changes. I'm happy to change my opinion if somebody can come up with some reasoned logic. Just telling me that I know nothing, and should keep quiet, just makes me think I am right and the person criticising me knows less than I do.

Why do you keep saying 20 minutes? If your transaction gets into the next block then it's the time between broadcasting the transaction and the next block being found - on average that should be about 5 minutes (assuming 10 minute average between blocks).

I think you're having a bit of trouble with the math.

0 confirmations = 0 blocks = instant
1 confirmation = 1 block = 10 minute average
2 confirmations = 2 blocks = 20 minutes average


If you are buying 5 BTC or a car, then you can wait 10 minutes for the confirmation if you are worried about it (or use a trusted service such as Coinbase that allows immediate transfer of funds off-chain).


The average is only 10 minutes (not 20 minutes) for 1 confirmation.  The majority of confirmations occur in less than 8 minutes.


With a 10 minute average time between blocks, some blocks will take much longer, and many blocks (more than 50%) will take less than 10 minutes.  There will even occasionally be blocks that occur at nearly the exact same time (which results in an orphan block).

With a 5 minute averagetime between blocks, some blocks will still take much longer, and many blocks (more than 50%) will take less than 5 minutes.  There will be almost twice as many blocks that occur at nearly the exact same time (which results in almost double the number of orphan blocks).

So, you haven't solved the problem of long periods occasionally occurring between blocks at all, but you have increased the number of orphan blocks significantly.  Are you saying that there are times when someone would be happy to wait nearly 5 minutes for a confirmation, but that nearly 10 minutes would be so much longer that it would change their mind?

Dude let's be honest. Do you honestly think that you know better than Greg Maxwell, Adam Back, Peter Wiulle...
Unless you are one of those nutjobs that think they want to "take over Bitcoin with Blockstream" (geez..) you should go read some of their posts and realize why this "let's do this NOW" theory is not a good idea
Things are moving, there is a scaling roadmap going on done in a conservative (aka correct) way. Let's give it 6 months to reassess the situation.

^^This. Those, who are here to understand bitcoin, will end this discussion here. Those, who are here to spam signature, will drag on...

This is not a good logic at all, because in the opposite side there are Gavin, Jeff and big companies like BitPay, CoinBase. Let's argue on technical basis, not on how heavyweight which side is. For thousands of years the citizen of the world believed the world is flat, till Galileo pointed out that it is not.

Here's the really awkward thing about random processes...

The average time from when you create your transaction until the next block is solved will be 10 minutes.

It doesn't matter how long ago the previous block was solved.

If you always wait until there has been a 9 minute gap between your transaction and the most recent block before you transmit your transaction, you will find that on average you wait 10 minutes to get your first confirmation.

If you always wait until there has been a 1 second gap between your transaction and the most recent block before you transmit your transaction, you will find that on average you wait 10 minutes to get your first confirmation.

If you always wait until there has been a 15 minute gap between your transaction and the most recent block before you transmit your transaction, you will find that on average you wait 10 minutes to get your first confirmation.

It isn't immediately intuitive for most people, but the thing to remember is that since that gap has already passed, you're already skipping over all the block times that would have been less than that gap. Therefore you miss out on all those faster blocks that pull down the average.

OK maybe I am missing something here. This is the way I thought it worked. I submit a transaction, and it gets into the next available block, this could take 10 minutes. At this point it is unconfimed because that block could be an orphan. So I wait for the next block, that could take another 10 minutes. That's where I get the 20 minutes. What is wrong with my logic? Of course it gets worse if the block is orphaned, and some of the heavyweights seem to think that increasing the blocksize will create more orphans. I posted the link about this.

First of all, please recognize that what you are saying it "needs" is just an opinion.  There is no verifiable proof that any of those things are "needed".  What you are saying is "I want, because I feel it is important."

That being said, I hope you realize that this discussion isn't likely to actually accomplish any of the changes you are asking for.  The things you are suggesting have been suggested MANY times in the past 8 years, and there have ALWAYS been a significant number of people that are against these ideas.  Since bitcoin is a consensus system, it is extremely difficult to make any change that doesn't have support from an overwhelming majority of the users.  If these ideas had that sort of consensus support, they'd already have been implemented.  You're going to need to come up with some new and very convincing reasons to convince enough people to change their minds.

Just a few of the most common reasons presented that have all already failed to convince enough people to change:

• People won't want to wait that long for confirmations.
• It's too slow for daily face-to-face transactions (such as coffee, or groceries, or McDonald's, etc)
• There's more incentive for more pools and solo-miners since rewards occur more often (better decentralization)
• It increases the capacity of transactions per unit of time that can be confirmed

You are right, that is extremely hard to get one's head around, and I apologise if I was misleading.

Are you able to point me to a complete explanation?

Nope.  That's not how it works.

You broadcast a transaction to your peers, and they relay it to their peers, and they relay it to their peers, and so on.

At this point is in unconfirmed because it is not yet in a block.

Some people feel that an unconfirmed transaction is sufficient to feel confident that the transaction is secure and are willing to provide goods or services in exchange for the transaction at this time, others are concerned that there may be a competing transaction that they haven't seen yet and want to wait for more confirmations.

Eventually someone that is a peer with a mining pool (or solo miner) relays your transaction to that pool (or miner).  The miners that hear about your transaction may or may not choose to add your transaction to the block they are working on.

At this point is in unconfirmed because it is not yet in a block.

Eventually a miner that has chosen to include your transaction in their block succeeds in solving the block.  They broadcast the block to their peers, and they relay it to their peers, and they relay it to their peers, and so on.

At this point, anyone that has received the block (and has not first received any competing block at the same block height) sees your transaction as having 1 confirmation.  If this block gets relayed to you and the recipient of your transaction, then you both see it as having 1 confirmation.

Some people feel that 1 confirmation is sufficient to feel confident that the transaction is secure and are willing to provide goods or services in exchange for the transaction at this time, others are concerned that there may be a competing transaction with 1 confirmation in a competing block that they haven't seen yet and want to wait for more confirmations.

If this block is orphaned, and a block with a competing transaction becomes part of the main chain, then they could lose their funds to the scammer.

Eventually this block is either orphaned or another block is mined on top of this block by a miner somewhere. They broadcast the block to their peers, and they relay it to their peers, and they relay it to their peers, and so on.

If the block with your transaction was not orphaned by this block, then anyone that has received the block sees your transaction as having 2 confirmations.  If this block gets relayed to you and the recipient of your transaction, then you both see it as having 2 confirmations.

Some people feel that 2 confirmations are sufficient to feel confident that the transaction is secure and are willing to provide goods or services in exchange for the transaction at this time, others are concerned that there may be a competing transaction  in a competing set of two blocks that they haven't seen yet and want to wait for more confirmations.

If this set of 2 blocks is orphaned, and a different set of 3 blocks with a competing transaction becomes part of the main chain, then they could lose their funds to the scammer.

Eventually thisset of 2 blocks is either orphaned or another block is mined on top of this block by a miner somewhere. They broadcast the block to their peers, and they relay it to their peers, and they relay it to their peers, and so on.

If the block with your transaction was not orphaned by this block, then anyone that has received the block sees your transaction as having 3 confirmations.  If this block gets relayed to you and the recipient of your transaction, then you both see it as having 3 confirmations.

Some people feel that 3 confirmations are sufficient to feel confident that the transaction is secure and are willing to provide goods or services in exchange for the transaction at this time, others are concerned that there may be a competing transaction  in a competing set of 3 blocks that they haven't seen yet and want to wait for more confirmations.

If this set of 3 blocks is orphaned, and a different set of 4 blocks with a competing transaction becomes part of the main chain, then they could lose their funds to the scammer.

This process continues with more and more blocks being added to the chain until the recipient feels that they have seen enough new blocks that the risk of orphaning the entire stack is acceptable to them.

I don't want to hijack this thread and turn it into a discussion about statistical averages regarding an effectively random process.

If you want to open a new thread (perhaps in the "off topic" sub-forum), and send me a message pointing me to your thread, I'd be happy to discuss it with you in further detail there.

Thanks for that explanation Danny, and I have been under a misaprehension about confirmations. I ignored the fact that a transaction had been submitted, and thought confimations were related solely to blocks. So if I can relate this to a fiat bank payment, the system is like this.

A transaction is sent to the transaction pool ( The cheque is in the post)
The transaction has been added to a block ( The cheque has been paid into a bank account)
The block has been confirmed by a subsequent block ( The funds have cleared ).

So it looks as if my error was in saying 1 confirmation, what I should have said was 2 confirmations - apologies.

Of course anything I say is my opinion, and is based on my limited, and recently aquired, knowledge. However, some times a fresh mind can point out the obvious that those immersed in the technology overlook. Two things have become apparent to me. Unsophisticated users who mistrust on-line wallets need a GUI to use core, and I started a separate thread about that. To feel comfortable about a transaction you need 2 confirmations, and that takes an average of 20 minutes, and that is too long for some applications.

"Confirmations" are related solely to blocks.

1 confirmation means that the user sees the transaction in the most recent block added to their blockchain.
2 confirmations means that the user sees the the transaction in a block in their blockchain, and that there is only 1 additional block added to their blockchain after that.
3 confirmations means that the user sees the the transaction in a block in their blockchain, and that there are only 2 additional blocks added to their blockchain after that.
4 confirmations means that the user sees the the transaction in a block in their blockchain, and that there are only 3 additional blocks added to their blockchain after that.
99 confirmations means that the user sees the the transaction in a block in their blockchain, and that there are only 98 additional blocks added to their blockchain after that.


You really can't.  It isn't much like a fiat bank payment at all.


You can choose to look at it like that if you want to, but it doesn't mean others will look at the same way.  I prefer to look at it like this:

• A transaction is broadcast to peers (The credit card is swiped at the cash register)
• The transaction finds it's way to a significant percentage of the mining hashpower (The payment processor has informed the cash register that the transaction is valid)
• The transaction is confirmed in a block (The merchant completes their daily settlement with the payment processor and the funds are deposited into their account)
• The transaction is buried 1 block deeper into the blockchain (A month has gone by and the merchant hasn't received a chargeback notification from the payment processor yet)
• The transaction is buried another block deeper into the blockchain (Another month has gone by and the merchant hasn't received a chargeback notification from the payment processor yet)
• The transaction is buried another block deeper into the blockchain (Another month has gone by and the merchant hasn't received a chargeback notification from the payment processor yet)
• etc...

Correct.  The average time for one confirmation is 10 minutes.  20 minutes would be the average time for 2 confirmations.


I fixed that for you.  You might want 2 confirmations, but that doesn't mean that I do or that others do.

2 confirmations are not needed for everyone or for every situation.  Sometimes 0 confirmations will be perfectly fine.  Other times 2 confirmations won't be enough.  It depends on who is engaged in the transaction and the specific conditions of the transaction.  When you purchase something from a grocery store and pay with a credit card, do you wait in the store until they complete their daily settlement with the payment processor at the end of the day before leaving with your merchandise?  Do you wait in the store for an entire month until they are certain that you won't be filing a chargeback claim with the payment processor?

So really it comes down to the trust you have in the other party, but one of the central tenets of Bitcoin is that it is trustless. I agree that it is difficult to equate Bitcoin to any fiat payment service, and that is a big part of its appeal. All of the comments so far seem to confirm that you have to wait for at least 2 blocks to be generated to feel comfortable with the transaction, unless you introduce an element of trust of course. The possibility of a hard fork means that the situation may become worse during the period of the forking and its resolution.

I forgot to add that credit cards and most fiat payment services have an administering body, and this gives them a point of appeal when a transaction goes wrong. This is not present with Bitcoin.

I don't think that is right but I am not really sure what you are arguing now.

1. You seem to be applying your view (2 blocks required) to a general requirement - where is that said?

2. Just because the next block is an orphan does not mean that any transactions in it will not subsequently get into a valid block

Now I'm not clear if you are concerned about malice (the other party trying to defraud you), chance (the transaction happened to be in a block that was subsequently orphaned) or delay (the time it takes for some arbitrary number of transactions)?

could you technically have a block every 5 minutes, but only half of the block are rewarded?
That wouldn't change too many of the general principals of Bitcoin, but would speed things up a lot.

Orphans aren't a major problem with 5 minute blocks, with 30 second blocks yes, LTC seems to get by ok.

That was more or less what I was suggesting at first. After quite a lot of reading, I came to the conclusion that 3 minute intervals with a 4 Bitcoin reward might be better. It could be introduced at the time of the halving without too much interruption of the blockchain. Those figures might need to have a few fractions added, as it represents a small loss to the miners.

@tertius - nothing is a general requirement. Everything depends on the beliefs and attitudes of the participants. I would apply different rules if I was transferring funds between my own wallets, receiving money from a long standing friend, or accepting payment from a known PayPal scammer.

"better" for what though?  If you halve the block time, and halve the difficulty, then surely the "work" required to secure two 5 minute blocks is the same as the work previously required to secure one 10 minute block?

The advantages are -

reduced confirmation time.
no increase in the propagation delays resulting from larger blocks
no change to the blockchain structure
increased capacity to allow for further growth.

and a few others.

This change coupled with the others proposed by core, would take Bitcoin well into the future.

These aren't advantages of this proposal. You seem to misuse the word 'advantage'. This is also quite a heavy change that you're proposing.

You need to look at both the pros and cons of such a proposal. You can't just look at the pros and come to a conclusion that this is the right path to go by. How about listing the disadvantages as well?

---

---

While an exact generation time of 5 minutes requires analysis for concrete examples of potential problems, here's something that I've found:
It might be wise to run tests first and try talking to the developers (IRC might help). The question was why was 10 minutes chosen or was it arbitrary.

---

---

So: Increase CPU usage (due to more blocks), increase orphan rate, more confirmations needed for security.