Why not increase the number of block mined?

[Jet Cash]

OK - here's a real newbie question. Instead of fighting over blocksize, and trying to force a hard fork, why not allow an increase in the number of blocks mined? Doubling the number of blocks would allow the whole Bitcoin environment to expand.

[AliceWonderMiscreations]

Not really.

Doubling the block rate has no advantage over doubling the block size.

Changing the rate though does have impact on coin production and that would be seen as a bad thing to many and potentially cause a loss of faith in the currency.

It also would decrease the difficulty in finding a block which has some other implications, some double spend attacks are only possible if you find a block first but don't release it before pulling off your double spend attack.

[xhomerx10]

It would not longer be bitcoin, it would be Neoscoin and there would be mass panic and chaos.
Would you also cut the reward in half, allow more that 21million coins to be mined or simply shorten the time to get to 21million coins by only decreasing the block time?

[DannyHamilton]

OK - here's a real newbie question. Instead of fighting over blocksize, and trying to force a hard fork, why not allow an increase in the number of blocks mined? Doubling the number of blocks would allow the whole Bitcoin environment to expand.

It's not clear what you mean.

There are currently an infinite number of blocks allowed by the protocol.  If you double that, you still have an infinite amount allowed.  There isn't any increase.

I assume that you mean to change the difficulty adjustment so that the average time between blocks is 5 minutes instead of 10 minutes.  This would also be a hard fork, since nodes that run the new software would accept blocks with an easier hash target than nodes with the old software.  Additionally, this isn't a long term solution.  Eventually, the transaction volume would grow to be more than double what it is today, and you'd need another hard fork (to increase block size? To cut the average time between blocks again?  Some other solution?).  That would mean we'd have to have this whole debate all over again with even more participants and even more newbies, and even more opinions, and even more risk (since the bitcoin economy would be twice as big as it currently is).

Furthermore, decreasing the average time between blocks would mean that orphan blocks would occur more frequently. It would also amplify the effects of delays between when a block is solved and when a miner hears about the solved block.  Miners that have slower connections (such as in China) would likely be against such a change.

If you didn't decrease the block subsidy and increase the number of blocks between halvings at the same time, then the remaining bitcoins to be created would be created in half the time.  This would be a significant change in inflation rate, and would be a difficult thing to get people to accept.

[Jet Cash]

Thanks for the explanations. I was thinking that if the block creation time was reduced to 5 minutes at the same time as rewards were halved, then the new coin creation rate would still be roughly the same. Obviously this would allow for the processing of more transactions per minute, and I thought it might allow for a reduction in the size of the UTXO pool. I didn't appreciate the orphan creation problem though.  Also, I wasn't aware of the need to change the difficulty in finding hash targets. I assumed that hardware improvements had made target discovery much faster, and the 10 minute limit was a policy restriction. I guess I need to read up on the hashing logic.

[AliceWonderMiscreations]

Thanks for the explanations. I was thinking that if the block creation time was reduced to 5 minutes at the same time as rewards were halved, then the new coin creation rate would still be roughly the same. Obviously this would allow for the processing of more transactions per minute, and I thought it might allow for a reduction in the size of the UTXO pool. I didn't appreciate the orphan creation problem though.  Also, I wasn't aware of the need to change the difficulty in finding hash targets. I assumed that hardware improvements had made target discovery much faster, and the 10 minute limit was a policy restriction. I guess I need to read up on the hashing logic.

If you are properly set up, most transactions can be accepted with 0 confirmations.

Just make sure your client uses several well connected nodes for where it gets its transactions from, and do not accept incoming connections.

That makes the race attack very difficult because the transaction you see for a given input then likely becomes the same transaction the miners see and any double spend attempt will be rejected.

Most of the other double spend attacks require that the attacker be someone who has the hash rate to create blocks, and are very very hard to pull off - as in not worth trying for relatively small amounts of money.

The transaction confirmation problem really isn't one. Sure it may take hours sometimes for a given TX with a low fee to make it into the blockchain, but double spending on that TX is really hard unless you are a miner yourself. Even then it is hard.

[adamstgBit]

Thanks for the explanations. I was thinking that if the block creation time was reduced to 5 minutes at the same time as rewards were halved, then the new coin creation rate would still be roughly the same. Obviously this would allow for the processing of more transactions per minute, and I thought it might allow for a reduction in the size of the UTXO pool. I didn't appreciate the orphan creation problem though.  Also, I wasn't aware of the need to change the difficulty in finding hash targets. I assumed that hardware improvements had made target discovery much faster, and the 10 minute limit was a policy restriction. I guess I need to read up on the hashing logic.

If you are properly set up, most transactions can be accepted with 0 confirmations.

Just make sure your client uses several well connected nodes for where it gets its transactions from, and do not accept incoming connections.

That makes the race attack very difficult because the transaction you see for a given input then likely becomes the same transaction the miners see and any double spend attempt will be rejected.

Most of the other double spend attacks require that the attacker be someone who has the hash rate to create blocks, and are very very hard to pull off - as in not worth trying for relatively small amounts of money.

The transaction confirmation problem really isn't one. Sure it may take hours sometimes for a given TX with a low fee to make it into the blockchain, but double spending on that TX is really hard unless you are a miner yourself. Even then it is hard.

you can send your TX with a fee so small it won't get included in a block
you'll see it come up as a 0 conf.  and never get confirmed.
then you resend the same bitcoin 12 days later with a fee that will get accepted.
conclusion, you'll also need to make sure you check the fee is appropriate if your going to accept 0 conf.

[AliceWonderMiscreations]

Thanks for the explanations. I was thinking that if the block creation time was reduced to 5 minutes at the same time as rewards were halved, then the new coin creation rate would still be roughly the same. Obviously this would allow for the processing of more transactions per minute, and I thought it might allow for a reduction in the size of the UTXO pool. I didn't appreciate the orphan creation problem though.  Also, I wasn't aware of the need to change the difficulty in finding hash targets. I assumed that hardware improvements had made target discovery much faster, and the 10 minute limit was a policy restriction. I guess I need to read up on the hashing logic.

If you are properly set up, most transactions can be accepted with 0 confirmations.

Just make sure your client uses several well connected nodes for where it gets its transactions from, and do not accept incoming connections.

That makes the race attack very difficult because the transaction you see for a given input then likely becomes the same transaction the miners see and any double spend attempt will be rejected.

Most of the other double spend attacks require that the attacker be someone who has the hash rate to create blocks, and are very very hard to pull off - as in not worth trying for relatively small amounts of money.

The transaction confirmation problem really isn't one. Sure it may take hours sometimes for a given TX with a low fee to make it into the blockchain, but double spending on that TX is really hard unless you are a miner yourself. Even then it is hard.

you can send your TX with a fee so small it won't get included in a block
you'll see it come up as a 0 conf.  and never get confirmed.
then you resend the same bitcoin 12 days later with a fee that will get accepted.
conclusion, you'll also need to make sure you check the fee is appropriate if your going to accept 0 conf.

But if you send it with a fee that small it will likely never get relayed to the vendor.

That's why as a vendor, your client should never accept direct connections - so that the double spender can't connect directly to your node to deliver the TX but instead has to get a TX that will get to the vendor by being relayed.

[ranochigo]

Thanks for the explanations. I was thinking that if the block creation time was reduced to 5 minutes at the same time as rewards were halved, then the new coin creation rate would still be roughly the same. Obviously this would allow for the processing of more transactions per minute, and I thought it might allow for a reduction in the size of the UTXO pool. I didn't appreciate the orphan creation problem though.  Also, I wasn't aware of the need to change the difficulty in finding hash targets. I assumed that hardware improvements had made target discovery much faster, and the 10 minute limit was a policy restriction. I guess I need to read up on the hashing logic.

If you are properly set up, most transactions can be accepted with 0 confirmations.

Just make sure your client uses several well connected nodes for where it gets its transactions from, and do not accept incoming connections.

That makes the race attack very difficult because the transaction you see for a given input then likely becomes the same transaction the miners see and any double spend attempt will be rejected.

Most of the other double spend attacks require that the attacker be someone who has the hash rate to create blocks, and are very very hard to pull off - as in not worth trying for relatively small amounts of money.

The transaction confirmation problem really isn't one. Sure it may take hours sometimes for a given TX with a low fee to make it into the blockchain, but double spending on that TX is really hard unless you are a miner yourself. Even then it is hard.

you can send your TX with a fee so small it won't get included in a block
you'll see it come up as a 0 conf.  and never get confirmed.
then you resend the same bitcoin 12 days later with a fee that will get accepted.
conclusion, you'll also need to make sure you check the fee is appropriate if your going to accept 0 conf.

TXes will eventually get included into a block if you continually rebroadcast it and the priority gets high enough. Even with a high fee, if mining pools have differing policy, they may not accept the TX into their mempool even if the network does. The merchant should try to ensure that majority of the mining pools have seen it.

[Amph]

basically you want that bitcoin go in reverse trend and instead of an halving there will be a doubling, no sense

since two block every 10 mins, would be double the coins produced, also more dumping from miners that will be overwhelmed with a high profit

[Jet Cash]

basically you want that bitcoin go in reverse trend and instead of an halving there will be a doubling, no sense

since two block every 10 mins, would be double the coins produced, also more dumping from miners that will be overwhelmed with a high profit

I don't understand your post. If you halve the reward, but double the volume, then you are basically staying the same. However, you would run out of coins sooner. If you ignore the envelope, then 2 x 1Mb blocks are broadly the same as 1 x 2Mb block in capacity.

[franky1]

halving the difficulty and halving the reward is more complicated than just increasing the block limit buffer.

there are other ramifications too. such as reduced security because currently at the 10minute average some miners have the hash power/luck to make blocks in under 2 minutes. so halving the difficulty means that miners could with enough power/luck solve blocks even faster then that which opens up more risk of nefarious block creation.

there are other things that are affected with a halving of difficulty and reward, that are not affected by just increasing the blocksize limit buffer. so its much simpler to just increase the block limit buffer.

[Jet Cash]

I think there is a basic flaw in my knowledge. I didn't realise that the 10 minute level is imposed by the level of difficulty. I thought it was some temporal restriction. I guess I need to try to understand the mining algorithm.

Thanks once again for the explanations.

[AliceWonderMiscreations]

I think there is a basic flaw in my knowledge. I didn't realise that the 10 minute level is imposed by the level of difficulty. I thought it was some temporal restriction. I guess I need to try to understand the mining algorithm.

Thanks once again for the explanations.

The difficulty adjusts based upon the current hash rate so that as the hash rate increases, so does the difficulty, to target 10 minutes.

Any individual block may take more or less time than the target, but on average it is about 10 minutes.

[Kprawn]

Yea, We should not mess around with the fundamental core of the protocol that has nothing to do with the scalability. If we mess around with that,

what will be next, the 21 000 000 cap? Investors in this technology are sure about the principles and they invested because they know where it's

going or how far it can go. Let's just keep with what is working for now... 

[Jet Cash]

Well you could say that investors are aware of 1Mb blocks, so why mess around with that.

With regards to scalability - is a 10 minute limit the correct one to fix given the improvements in processing powerr and bandwidth. I looked at this page -

https://bitcoinwisdom.com/bitcoin/difficulty

and I noticed that the difficulty can decrease as well as increase. So should the difficulty be varied to cope with transaction rate, UTXO size or some other factor, rather than just compensating for increased computer power.

[Amph]

basically you want that bitcoin go in reverse trend and instead of an halving there will be a doubling, no sense

since two block every 10 mins, would be double the coins produced, also more dumping from miners that will be overwhelmed with a high profit

I don't understand your post. If you halve the reward, but double the volume, then you are basically staying the same. However, you would run out of coins sooner. If you ignore the envelope, then 2 x 1Mb blocks are broadly the same as 1 x 2Mb block in capacity.

they would mine more coins early and yes like you said the fee era will begin quickly, this is not good, because there is one reason why satoshi wanted 4 years between each halving

to give enough time to the adoption, and to not increase too much the pressure from the miners, while we wait for it

[Jet Cash]

The pressure seems to come from the users rather thaan the miners.

On reflection, I'm still not sure why locking block creation to an average of 10 minutes is essential. It seems that it's possible to have a burst of blocks added to the chain, and the software seems to cope with that. A system with automatic scalability, would need to be orientated around the users far more than the miners. At the moment scalability seems to be based on political infighting and vested interests rather than software design.

[Odien]

Increasing that would mean increasing the total supply of Bitcoin. If the total supply is increased, then you can wait for the price to be destroyed.

[Amph]

The pressure seems to come from the users rather thaan the miners.

On reflection, I'm still not sure why locking block creation to an average of 10 minutes is essential. It seems that it's possible to have a burst of blocks added to the chain, and the software seems to cope with that. A system with automatic scalability, would need to be orientated around the users far more than the miners. At the moment scalability seems to be based on political infighting and vested interests rather than software design.

well "users" are helped by the miners, the other supply is simply being matched against the demand, but it's the additional supply that is created that can lead to the dumping, and especially the manipulations done by the miners