Topic: Halve the block generation interval now! (Read 1282 times)

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.

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.

"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?

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.

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.

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)?

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.

"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?

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.

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.

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.

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?

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

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.

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.

^^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.

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.

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?

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).

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.