Topic: Why not increase the number of block mined? (Read 1122 times)

Because it would alter the entire pattern that Bitcoin has been associated with for years.

Confirming own transactions is a bad thing anyway. Could sb think of a permission system for not allowing that as a winning side effect?

This would have, in effect, the same problem as described above. 

You seem to be suggesting that when there are more transactions you would reduce the difficulty in order to get more blocks and thus more capacity for more transactions?  In that case miners would be incentivised to simply pack every block with their own transactions. Driving difficulty towards zero.

The 10 minute target block time, managed by adjusting difficulty every 2016 blocks, together with the steadily reducing emission schedule is fundamental to ensuring a controlled emission of new coins and (hopefully) a manageable transition to a fees based reward model.

(Though as an aside, I'm not convinced that will actually happen - I did some calculations and fees are so low, transactions so few and the capacity for transactions so constrained, that I can't see how they can possibly replace the coinbase reward at the halving.)

OK - I begin to see the problems. I thought the 21M Bitcoins was hard coded, so that is a different issue. The problem of underutilised blocks seems to be present in all solutions, and is probably greater in the 2Mb blocksize solution. Maybe the answer would be a variable reward based on block utilisation. Transaction fees should solve this when all coins are mined. Maybe the finders reward should be variable until then, but I suspect it is too late to change that.

Blocks aren't really a measure of activity, transactions are. How difficult would it be to use the number of transactions to vary the difficulty rather than the number of blocks? I appreciate that this is a massive change, but if Bitcoin is going to expand exponentially, it will need to address the empty blocks and the time delay problems. Increasing the size of already under-utilised blocks will not be a solution.

Funny I just had the same idea and posted that in the tech blog...

I'd also just think of a very slight Modifikation in the recommended hash threshold, just that much that miners ensure to really pack as much as possible  transactions into a block (1 or 2 MB i dont care yet).

But finally stay to the average of 10min ( maybe 9.5 then) and there would appear no empty blocks any more.

I have not done the math but how much transactions were there over last week? I suppose they still can be included in that 10 min and 1MB frame yet , but than slghtly better...

If you increase and decrease the difficulty at will without adjusting block rewards, the total supply would vary from close to 21 million. It is also hard to see how much transactions are in the mempool of the node(it resets every time the client restarts) and adjusting the difficulty. Remember, the faster the blocks, the higher the orphan rate. Due to this, miners would be likely to mine blocks with little to no transactions.

The problem with self regulating in a decentralized system is that there is too much information that is impossible to know reliably.  Without a reliable source of that information, the self-regulating system can be manipulated and can't make useful decisions.

There is no way for the protocol to know what the current global hash power is at any given time, therefore it's impossible to choose a difficulty that will result in a known average block time for the next block.  Instead, what bitcoin does is look at the total time for 2016 blocks to occur based on inaccurate timestamps in the blocks.  If that total time was greater than 20160 minutes, then blocks (on average) are occurring too slowly and the difficulty needs to be adjusted so that blocks can be solved more easily.  If that total time was less than 20160 minutes, then blocks (on average) are occurring too quickly and the difficulty needs to be adjusted so that blocks can be solved more easily.

Now you are suggesting that the protocol somehow be aware if there is a demand for more frequent blocks.  I assume your plan is to look at the total percent that the past 2016 blocks are filled, and adjust the difficulty even further if the blocks are filled above or below some specified value?  If so, then miners can simply create their own transactions to fill their blocks 100% every time.  With 2016 blocks all filled 100%, how much would you suggest decreasing the difficulty?  Should it be cut in half so blocks occur on average every 5 minutes? reduced 90% so they occur every minute?  Now what if the blocks are still 100% full 2016 blocks later.  Are you going to do the same again, so that blocks occur every 6 seconds?  And if they are still 100% full, should we have blocks every 0.6 seconds?

What if the miners don't create their own transactions to fill their blocks 100% every time? If the blocks aren't 100% full, should difficulty be increased even more so the blocks come slower? How much should it be increased?  If we double the difficulty then we'll get blocks every 20 minutes.  If the next 2016 blocks still aren't full, should we double again to every 40 minutes?  How long do we continue that?  If at least on miner creates 1 empty block then the blocks will never be 100% full.  That single miner with enough hash power to mine at least 1 block every 2 weeks would  continue to double the block interval, 80 minutes, 160 minutes, 320 minutes?

Sorry guys, I don't think I explained myself very well. I was suggesting a permanently fixed block size of 1Mb, but the regulation of the unconfirmed transaction pool size by changing the hashing difficulty. This would mean that in a busy time, the number of blocks would increase, but when it quietened down, the difficulty would increase, thus reducing the number of blocks created. This could provide an incentive to miners to populate the blocks.

I can see one danger though. Selfish miners could submit unpopulated blocks to increase the pool, and thus allow them to create more blocks for higher rewards.

The size of blocks could be increased in a DOS attack by flooding the network with transactions sent from one address the attacker controls to another address the attacker controls.

That kind of thing already happens causing some of the congestion people complain about, but the fee structure makes it fairly easy to get your transaction to have priority because the spam transactions never have very big fees.

But with a block size that self regulates, the spam transactions would cause the block size to grow when growth isn't needed for legitimate transactions.

It is better for valid non-spam transactions with low fees to wait for confirmation in a spam attack than to have the size of blocks grow in response to tx spam attacks. In my opinion.

A self regulated system (if you're talking about dynamic block size limit) needs to use certain factors in order to determine how to regulate itself. If improperly implemented, those factors could be exploited. This is the simplest explanation that I can come up with. People don't understand the complexity of such changes and seem to think that it is easy to develop/implemented (safely).

I don't agree with if to doubling the block rate has no benefit rather than to double the size of block.
There is problem to search a block which may decrease in this way perhaps.

I'm having difficulty in understanding why a self regulating block rate would be a disadvantage. There must be a lot of advantages in staying with a fixed blocksize of 1Mb, partially populated blocks is just one factor. With a self-regulating system, then transactions could double without requiring any further changes. It would also cope with the situation when all coins have been mined, and miners rely on transaction fees to provide their income.

thanks for this clarification

now which nodes are trustworthy?

Not necessarily, you can easily balance it out by dropping the supply per block by 50%. This means that the supply per day would remain constant and we'd have a 5 minute block interval. However, this also requires a HF and is potentially risky in other unexplored ways.

No. The day that you increase the supply is the day that the confidence in the set rules is lost and the system starts falling apart. I'd be among the first to sell everything and leave. Fees should be adequate enough in the future to provide a steady income for the miners. However, you need not worry about events that are so far in the future.

The total supply is increasing - or is it? Quite a lot of coins seem to be getting lost. It would just mean that the 21M cap would arrive sooner. Now what will happen when that arrives? Will miners say that we need a hard fork to raise the cap to 42M. Looking at the blocksize conflicts that seems likely.

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

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.

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.

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

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.