Why not increase the number of block mined?

[Jet Cash]

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

[Lauda]

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.

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.

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.

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.

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

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.

thanks for this clarification

now which nodes are trustworthy?

[Jet Cash]

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.

[ekoice]

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.

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.

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.

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.

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.

[Lauda]

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.

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

[AliceWonderMiscreations]

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.

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.

[Jet Cash]

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.

[DannyHamilton]

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

[ranochigo]

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.

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.

[hv_]

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

[Jet Cash]

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.

[tertius993]

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.

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

[hv_]

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

[PakistanHockeyfan]

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