Halve the block generation interval now!

[thejaytiesto]

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.

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.

[GermanGiant]

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.

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.

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

Dude let's be honest. Do you honestly think that you know better than Greg Maxwell, Adam Back, Peter Wiulle...

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.

[DannyHamilton]

on average that should be about 5 minutes (assuming 10 minute average between blocks).

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.

[Jet Cash]

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.

[DannyHamilton]

Let me clarify one thing. I believe in Bitcoin, and I think it will become the Gold standard of Crypto-currencies.
- snip -
it need
- snip -
It also needs
- snip -
that will need to be
- snip -

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

[tertius993]

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.

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?

[DannyHamilton]

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.

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.

[DannyHamilton]

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?

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.

[Jet Cash]

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.

[DannyHamilton]

I ignored the fact that a transaction had been submitted, and thought confimations were related solely to blocks.

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

So if I can relate this to a fiat bank payment

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

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

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

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

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

To feel comfortable about a transaction I need 2 confirmations, and that takes an average of 20 minutes, and that is too long for some applications.

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?

[Jet Cash]

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.

[tertius993]

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

[NUFCrichard]

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.

[Jet Cash]

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.

[tertius993]

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?

[Jet Cash]

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.

[Lauda]

no increase in the propagation delays resulting from larger blocks
no change to the blockchain structure

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.

and a few others.

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

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:

However, the lesson of Fastcoin should be considered here. We recently uninstalled Fastcoin from our pool because it simply required too much CPU to run. Compared to dogecoin or bitcoin, it was using 20 times as much CPU because it received so many blocks that it had to validate all of them. We have only restarted the daemon server twice since July 2014, but when we did, Fastcoin took 100% CPU for hours after the restart.

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.