We have "block purning" which allow you to have full node and use about 1-2GB disk space (instead of 40GB+). It have some limitations, but it will be "fixed" soon.
When "UTXO consensus database" will be finished, fresh full node will sync in matter of minutes (on good connection).
Max block size need to be limited, also we can not raise it rapidly because of technological limitations we have.
In auto-adjusting mode I described, it will raise on demand. I also getting +-20% of CURRENT block size, so if need, max block size will double in 4 months. I think, it is rapid enough.
Also, we start from 2MB, which is double that we have today. If someone want to spam network, he need spent more BTC to cover necessary fees.
Topic: Max block size - another proposal (Read 1129 times)
I find the idea simple yet effective.
However the "max raise" limits should me infinite.
You can't always predict how much people will suddenly rush into bitcoin making the 20% inefficient.
Additionally, I think that before considering raising the blocksize,
why not just try to not exceed the 1mb limit?
Sadly, there are spamming attemps on a dialy basis.
These malicious attacks on the network take up much of the blocksize, and eventually
overweighting the blockchain.
We need to realise that this model is simply NOT sustainable in the far future.
Any technological advancement can't keep the pace of the mosterously
frowing blockchain(Now we get 100mb per day!).
However the "max raise" limits should me infinite.
You can't always predict how much people will suddenly rush into bitcoin making the 20% inefficient.
Additionally, I think that before considering raising the blocksize,
why not just try to not exceed the 1mb limit?
Sadly, there are spamming attemps on a dialy basis.
These malicious attacks on the network take up much of the blocksize, and eventually
overweighting the blockchain.
We need to realise that this model is simply NOT sustainable in the far future.
Any technological advancement can't keep the pace of the mosterously
frowing blockchain(Now we get 100mb per day!).
What you mean after hard fork every month ?
No, there would be only one hard fork, major change in protocol.After this, all changes would be within parameters set in hard fork, no more code updates need.
Just like difficulty calculation works.
I think rav3n_pl means that max block size will be recalculated every month.
There will be only 1 hardfork
Good idea, in my oppinion.
There will be only 1 hardfork
Good idea, in my oppinion.
What you mean after hard fork every month ?
Looking on BIP 100,101 and 102 it seems, that we have no consensus about how to raise max block size.
It is need ASAP, it need hard fork. But what later?
There is my idea, how to make it:
Looks legit?
It is need ASAP, it need hard fork. But what later?
There is my idea, how to make it:
- we hardfork on 11. September (looks like it is 1st possible date)
- hardfork immediately raise max block size to 2MB
- min limit will be 1MB, max 32MB like it is now
- after hardfork, every month (4 320 blocks) max block size will be recalculated based on current demand
- there will be 3 possible things when recalculate:
- no change
- raise
- reduce
- max change will be +-20% of current size
- change will be done only, if:
- raise, if last 4320 block average filled in more than 90%
- reduce, if last 4320 blocks average filled in less than 50%
- no change in other cases
- we not count 50 top and low sized blocks (ignore some of "empty" blocks)
Looks legit?
Jump to: