bitcoin block size issues

[gdale]

Hello bitcoin development people,
   There is a lot of talk about block size for the ongoing network growth. I want to put forth a plan that should work for this issues. Please read this in full before commenting on this.

Current working of the network:
          Now block size is a max of 1 MB per block, and can work with x transactions per sec, but miners can change this setting to a lower value. this is an arbitrarily set number that will not be easy to change or scale with the network as needed.

Working to fix this issues:
           People seem to want a max block size 8 or more times bigger then the current block size, this is sooner then the network need this many transactions volume and will lead to some blocks being bigger then they need to be by have a large block then a few low transactions block on the block chain as block are found like clock work they are randomly found. Given this and the fact miners can change the setting I do not see this work very well.

My fix for the issues:
((((total block size sum of the last 2016 blocks) + (unconfirmed transactions size at the time of last block) / 2016)*1.03)
This will allow the block size to change as needed and reset every difficulty change. Also the setting for bitcoind should be changed to a percentage base value to allow for the variable block size.

I hope this is in the right area of the forums if not please let me know Ty can have a nice day.

[DannyHamilton]

- snip -
My fix for the issues:
((((total block size sum of the last 2016 blocks) + (unconfirmed transactions size at the time of last block) / 2016)*1.03)
This will allow the block size to change as needed and reset every difficulty change. Also the setting for bitcoind should be changed to a percentage base value to allow for the variable block size.
- snip -

It is not possible to know with any certainty what is the total "unconfirmed transactions size at the time of last block".

Additionally, this algorithm would allow a malicious miner to create blocks that are the full current size (to force the future size to continuously increase to sizes that interfere with the potential for decentralization.

It would also allow an attacker to regularly create a huge number of unconfirmed transactions just before the difficulty adjustment to force the block size to continuously increase to excessive size.

[Jet Cash]

Instead of increasing the size of the blocks, it would be better to reduce the size of the transactions inside the blocks. Hence SegWit.

[Cconvert2G36]

Instead of increasing the size of the blocks, it would be better to reduce the size of the transactions inside the blocks. Hence SegWit.

Instead In order to of increasinge the size of the blocks, it would be better to reduce the size of the transactions inside the blocks break a portion off into a separate part, and make that part cheaper to use for signature heavy transactions in preparation for LN, there is no reduction of transaction sizes of any sort. Hence SegWit.

ftfy