Quote from: anth0ny on December 02, 2013, 01:48:46 AM

Quote from: Saturn7 on December 01, 2013, 03:58:55 PM

Quote from: anth0ny on December 01, 2013, 03:17:44 PM

Quote from: Saturn7 on December 01, 2013, 03:03:58 PM

Difficulty adjustment already provides a mechanism to adjust a variable value with consensus. Why not just treat block size the same?
For example if the average size of the last 2016 blocks in 80% full then the block size would double.

In the last 2016 blocks, or in the 2016 blocks which make up the previous difficulty calculation? (I think the latter would probably be a better choice.)

What, if anything, is the mechanism to shrink the blocks back down again? (Halve if the average size of the last 2016 blocks is 20% full, with a hard minimum of 1 meg?)

I suspect this might be vulnerable to blockchain-forking attacks which near-simultaneously release very differently sized blocks, but it's hard to say without a full specification.

Depending on your answer to the second question, it also might increase the incentives for miners to release blocks with as few transactions as possible.

It also generally makes the design of mining software more complicated and thus more vulnerable to attack. Being able to statically allocate the size of a block is a definite advantage, though I don't know off hand how the reference implementation handles this. I'd say some hard maximum is necessary, even if it's ridiculously huge. But then what's the advantage of not just setting the maximum at whatever that hard maximum is?

In the end this might be viable, but I'd want a lot more details.

I would say the 2016 blocks which make up the previous difficulty calculation.

I don't think it should shrink, there may be periods where blocks are not fully utilised but if that became an ongoing trend it would only mean people stopped using bitcoin.

That definitely solves a lot of problems.

Except that ISN'T the problem. If miners can make a positive return by producing larger blocks ... they will. They want money, more money is always better. However tonight you could flip the network to 1 GB blocks and ACTUAL block sizes aren't going to change at all.

Miners actually are including most paying txs. Take a look at the memory pool, remove tx seen after the last block and 90%+ of the remaining tx are:
* no fee txs.
* txs with unconfirmed outputs.
* double spends or other tx problems.

Implementing child pays parent will improve the second category, the third category probably should just be excluded. That leaves essentially free txs. Miners aren't going to produce 20 GB blocks of free txs just because users want something for nothing. That is never going to happen so as the correct titles says "Blocks are NOT full. What is the plan?".

The good news is there is something which can be done to make blocks larger and reduce confirmation delays:
1) The default bitcoind has a rule where fees double as blocks get larger. It looks like most major pools have stripped that out otherwise we wouldn't see blocks >500 KB however that rule should probably go. It no longer really serves any purpose. The nice thing is it is a client side change so it requires no protocol change or fork.

2) Education. Until recently a company as big and old as MtGox was creating free txs. For something as timely as exchange cashouts that is just stupid. Sorry it is. They should know better. If you want to send your friend Bob some coins and want to be cheap that is one thing but major commercial enterprises should really be favoring reliability over trying to save pennies.

3) Child pays parent. Currently the way bitcoind prioritizes txs it does not include paying tx with unconfirmed outputs in the next block. So someone sends you coins with no fee, or possibly a bunch of dust spam and you try to resend them and include a fee and it looks like miners are screwing you over. The tx selection algorithm needs to be improved so if tx B has as an input an output for tx A and tx A has no fee and is unconfirmed but tx B has a fee the miners will include BOTH A & B in the block. This would also allow users to fix stuck txs and allow merchants to get confirmations on payments faster by respending them.

3) Improve block message format. Currently all block messages are the same old blocks back to the genesis block and the newest found block are transmitted as header + list of txs. For new blocks, nodes that are up to date likely already have most (and probably all) txs so a simple change to create a block header + tx hash message would reduce the bandwidth requires by ~90%. A 1Mb "header + hash only" block message would be smaller than a 100 KB full tx block message is now.