I have a meta-question... why the details (in the first OP post) are a (dynamic) PHP page?
Do you mean http://upalc.com/maxblocksize.php ?
Topic: BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap - page 2. (Read 9419 times)
Do you mean http://upalc.com/maxblocksize.php ?
I like this proposal. It creates predictable system with feedback with neutral rules. Specific parameters and issues have to be fine-tuned, of course. But it needs both miners and Bicoin users to agree and to actually "act like change is needed".
Like stated elsewhere: Miners decide what is the longest chain. Full nodes decide what is the valid chain. Bitcoin is the longest valid chain. So it needs both. And block size change proposal and mechanism should reflect that.
I have a meta-question... why the details (in the first OP post) are a (dynamic) PHP page?
Like stated elsewhere: Miners decide what is the longest chain. Full nodes decide what is the valid chain. Bitcoin is the longest valid chain. So it needs both. And block size change proposal and mechanism should reflect that.
I have a meta-question... why the details (in the first OP post) are a (dynamic) PHP page?
Oh, I didn't realize a second different algorithm was made.
One problem with the new one is that it presumes that Bitcoin transaction fees, in bitcoins, should always go up with a block size increase, which isn't always the case.
I dont see it is assumed anywhere. Tx fee has just been added as an extra filter criteria. Max block cap will rise, only if both block size & Tx fee increases.One problem with the new one is that it presumes that Bitcoin transaction fees, in bitcoins, should always go up with a block size increase, which isn't always the case.
If 1 TPS costs 1 cent to fund a healthy network, and a bitcoin costs 1 cent, then 1 TPS would cost 1 bitcoin to move.
If the network grows to 2 TPS, and bitcoin's value triples to 3 cents, then 2 TPS would cost .66 bitcoin to move.
So you could have the case where transaction fees could be bid up to .9 bitcoin, well into healthy territory, but it would appear that transaction fees, in bitcoin, have actually gone down substantially.
This is a wrong way to create fictitious situation. Tx fee shold not be calculated in cent. Do it in bitcoin and you'll have your answer. No one will pay 1 BTC to move 1 BTC. Do you see anyone paying 10000 satoshi to move 10000 satoshi ? But, if you want to move 10000 satoshi you still have to pay 10000 satoshi or 0.0001 BTC. If you remove economics and only discuss technology, then bitcoin is a fallacy. If the network grows to 2 TPS, and bitcoin's value triples to 3 cents, then 2 TPS would cost .66 bitcoin to move.
So you could have the case where transaction fees could be bid up to .9 bitcoin, well into healthy territory, but it would appear that transaction fees, in bitcoin, have actually gone down substantially.
As I can see, the proposal is now being discussed on the front page of www.reddit.com/r/bitcoin... interesting 
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
And the top comments state the problems which are exactly what I have said about it here and other thread.
As I can see, the proposal is now being discussed on the front page of www.reddit.com/r/bitcoin... interesting
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
That's much better. good work, upal
As I can see, the proposal is now being discussed on the front page of www.reddit.com/r/bitcoin... interesting
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
https://www.reddit.com/r/Bitcoin/comments/3iblg7/bipdraft_dynamically_controlled_bitcoin_block/
Oh, I didn't realize a second different algorithm was made.
One problem with the new one is that it presumes that Bitcoin transaction fees, in bitcoins, should always go up with a block size increase, which isn't always the case.
If 1 TPS costs 1 cent to fund a healthy network, and a bitcoin costs 1 cent, then 1 TPS would cost 1 bitcoin to move.
If the network grows to 2 TPS, and bitcoin's value triples to 3 cents, then 2 TPS would cost .66 bitcoin to move.
So you could have the case where transaction fees could be bid up to .9 bitcoin, well into healthy territory, but it would appear that transaction fees, in bitcoin, have actually gone down substantially.
One problem with the new one is that it presumes that Bitcoin transaction fees, in bitcoins, should always go up with a block size increase, which isn't always the case.
If 1 TPS costs 1 cent to fund a healthy network, and a bitcoin costs 1 cent, then 1 TPS would cost 1 bitcoin to move.
If the network grows to 2 TPS, and bitcoin's value triples to 3 cents, then 2 TPS would cost .66 bitcoin to move.
So you could have the case where transaction fees could be bid up to .9 bitcoin, well into healthy territory, but it would appear that transaction fees, in bitcoin, have actually gone down substantially.
While this proposal is my second preference, I'd suggest getting a move on and coding it into existence if this is your first choice for how the network should be run. Public support seems to be rallying around other proposals, namely BIP101 and BIP100. If you want a dynamic blocksize, you need to get this out in the open pretty quick to make it viable.
Public is totally confused and devs are clearly trying to do round about BIP 100, 101 & 103 as all are coming from existing core devs. Core devs seem to be ignoring proposals from outsider without weighing their merits. This is really unfortunate. I can smell, celebrity culture is taking over bitcoin development.
While this proposal is my second preference, I'd suggest getting a move on and coding it into existence if this is your first choice for how the network should be run. Public support seems to be rallying around other proposals, namely BIP101 and BIP100. If you want a dynamic blocksize, you need to get this out in the open pretty quick to make it viable.
legendary
Activity: 2884
Merit: 1115
Leading Crypto Sports Betting & Casino Platform
I like these proposals as they factor in growth alongside transaction fees
Setting a dynamically adjusted max cap is the true solution to blocksize problems as it allows for a right size fits all in all cases puts the issue to rest
and is the best middle ground in my opinion it will have a lot less polarization as it makes sense to me and likely others that blocksize growth should match demand with a dynamic margin that grows or shrinks alongside usage in the future.
That said a setting in addition to a dynamic max cap would be a recommended minimum for client installations as it would address concerns about nodes not having the needed resources, adding into that a warning if a node approaches a limit where it would not be able to optimally function in the future.
Setting a dynamically adjusted max cap is the true solution to blocksize problems as it allows for a right size fits all in all cases puts the issue to rest
and is the best middle ground in my opinion it will have a lot less polarization as it makes sense to me and likely others that blocksize growth should match demand with a dynamic margin that grows or shrinks alongside usage in the future.
That said a setting in addition to a dynamic max cap would be a recommended minimum for client installations as it would address concerns about nodes not having the needed resources, adding into that a warning if a node approaches a limit where it would not be able to optimally function in the future.
The better way, in my opinion, is to take signals from the network itself as proposed by OP.
That's what my proposal for Soft Limit does too and not just signals but a way for the miners to even shrink the block size if they have consensus on that with large enough hashrate:Example 50% of the miners want to keep the block size - they mine ~40% full blocks and the size will not change even if the rest of the network mines full blocks and there are enough transactions to fill them all.
If they want it lower - they mine even smaller blocks (non empty as they are simply ignored), but knowing that they miss some fees. At 10% full blocks from 50% of the miners it is guaranteed that the new size will be less than 83% of the current size and with 1% full blocks - 75% of the current
Now where 66% came from ...
See this charts again {1}, {2} and {3} and also {4}
Including days destroyed ( {2} ) to ignore short time extreme volumes will be a good idea, but no idea how exactly (EDIT: how to do it properly, so better not to do it at all).
See this charts again {1}, {2} and {3} and also {4}
- Now pick any two nearby min and max from {1} - it's close to 2:3 proportion
- Check July's attack on {1} - it's close to 1:2 and the fees on {3} are close to 1:2 too, but actual average size in {4} is also 2:3
Including days destroyed ( {2} ) to ignore short time extreme volumes will be a good idea, but no idea how exactly (EDIT: how to do it properly, so better not to do it at all).
Deriving a number relying on previous chart might work well for the short term, but it probably is not a good solution for the long run, because the chart will behave absolutely differently for a bubble, a spam attack or a tech innovation. In fact, that is the reason I do not like BIP 101, though I support bigger blocks. Gavin has derived 20mb and then 8mb relying on previous statistics. The better way, in my opinion, is to take signals from the network itself as proposed by OP.
I was about to post a similar suggestion too. I think this is a great idea.
I hope the core devs take a serious look at it.
I hope the core devs take a serious look at it.
Now where 66% came from ...
See this charts again {1}, {2} and {3} and also {4}
Including days destroyed ( {2} ) to ignore short time extreme volumes will be a good idea, but no idea how exactly (EDIT: how to do it properly, so better not to do it at all).
See this charts again {1}, {2} and {3} and also {4}
- Now pick any two nearby min and max from {1} - it's close to 2:3 proportion
- Check July's attack on {1} - it's close to 1:2 and the fees on {3} are close to 1:2 too, but actual average size in {4} is also 2:3
Including days destroyed ( {2} ) to ignore short time extreme volumes will be a good idea, but no idea how exactly (EDIT: how to do it properly, so better not to do it at all).
Why 66% and not 75% or 80% ? Where from this magic figure is coming ?
Good question and I will explain it in my next post.As I can see, as per OP's Proposal 2 network is chosing everything. Where did u find fixed compensation in Proposal 2 ? (Proposal 1 does no take care of mining fee, so question of compensation is not coming.)
Network is choosing, but based on fixed rules, which can easily be cheated for both. Half and double for Proposal 1 may seem OK for now, but think about 10M and 20M blocks it's a 40k+ of transactions per block added - you ruin the need of fees for quite a while or cause the size to flip-flop between 10M and 20M each timeHave you considered my suggestion here about 66% full blocks target of 1 month moving average and soft limit configured from the client?
Why 66% and not 75% or 80% ? Where from this magic figure is coming ? It is like Gavin's 8MB. He first suggested 20MB and then to get Chinese miner's support agreed upon to 8MB. These magic figures should not be pillar of a robust system which can scale with time.I don't like the idea to force some fixed compensation for the fee - the network should choose that and it is enough to give it the (right) triggers to do so.
As I can see, as per OP's Proposal 2 network is chosing everything. Where did u find fixed compensation in Proposal 2 ? (Proposal 1 does no take care of mining fee, so question of compensation is not coming.)
Have you considered my suggestion here about 66% full blocks target of 1 month moving average and soft limit configured from the client?
I don't like the idea to force some fixed compensation for the fee - the network should choose that and it is enough to give it the (right) triggers to do so.
I will use tl121's sentence here
By having (an easy to set) Soft limit allows the miners and pools to hold the block size growth in case of technical limitations. Yes, the usage will be limited (and more expensive) too, but if/until that doesn't cover the expenses for the bandwidth, space and CPU power required it is better to limit the network instead of crashing it completely with overwhelming requirements
I don't like the idea to force some fixed compensation for the fee - the network should choose that and it is enough to give it the (right) triggers to do so.
I will use tl121's sentence here
A dynamic algorithm can not magically instantiate the needed resources.
just change that to 'increased fees can not ...'By having (an easy to set) Soft limit allows the miners and pools to hold the block size growth in case of technical limitations. Yes, the usage will be limited (and more expensive) too, but if/until that doesn't cover the expenses for the bandwidth, space and CPU power required it is better to limit the network instead of crashing it completely with overwhelming requirements
Thanks to everyone for providing good arguements for improvement of the proposal. I have derived a second proposal and updated OP accordingly. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php
I don't thing it is a good idea to include TX fees in the calculation.See this charts {1}, {2} and {3}
Now consider and old miner consolidating his coins and a spammer attacking the network - both will cause increased volume of transactions (more or less in {1}) for a short period, but to succeed in the attack, the spammer (see 10 July and after) will include larger fees {3} and have less days destroyed {2}, while the old miner may 'donate' larger fees (as on 27 April) or use the fact that he may transfer them without fees (end of November), because they are old enough.
With your proposal of including the fees in the calculation the block size after 10 July will increase, thus helping the attacker even more, as it will keep increasing the block size (even now), just because others add more fees to mitigate the attack and prioritise their own transactions.
Thanks for your input. I was thinking the same and hence modified Proposal 2. This time the max cap increase is depndent on block size increase, but still Tx fee is taken care of, so that miners can be compensated for with decreasing block reward. Please check both Proposal 1 & 2 and share your opinion. It is good if someone can do a simulation with Proposal 1 & 2 and from Block 1 and share the result for both against last difficulty change.
Thanks to everyone for providing good arguements for improvement of the proposal. I have derived a second proposal and updated OP accordingly. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php
I don't thing it is a good idea to include TX fees in the calculation.See this charts {1}, {2} and {3}
Now consider and old miner consolidating his coins and a spammer attacking the network - both will cause increased volume of transactions (more or less in {1}) for a short period, but to succeed in the attack, the spammer (see 10 July and after) will include larger fees {3} and have less days destroyed {2}, while the old miner may 'donate' larger fees (as on 27 April) or use the fact that he may transfer them without fees (end of November), because they are old enough.
With your proposal of including the fees in the calculation the block size after 10 July will increase, thus helping the attacker even more, as it will keep increasing the block size (even now), just because others add more fees to mitigate the attack and prioritise their own transactions.
IMHO , the first proposal is good, if, we target for example a x% of average block's capacity.
For example, if on average blocks are 50% full and we target 66% then reduce block size,
if blocks are 70% full then increase block capacity. Let it test and see how affects the fee market.
The best thing about this is that, now we can target an average fee per block! :
if we are targeting 1btc per block in fees, and fees rise too much, lower the % full target, if fees decline rise the target.
There you go! Now people can vote for block increase by simply including higher fees!
For example, if on average blocks are 50% full and we target 66% then reduce block size,
if blocks are 70% full then increase block capacity. Let it test and see how affects the fee market.
The best thing about this is that, now we can target an average fee per block! :
if we are targeting 1btc per block in fees, and fees rise too much, lower the % full target, if fees decline rise the target.
There you go! Now people can vote for block increase by simply including higher fees!
I liked the points about handling the type of inertia that will manifest itself in a dynamic re-sizing scheme, particularly when the limit is sidling around in a narrow band. Any scheme should be able to respond to those circumstances in a way that promotes a healthy fee market, yet simultaneously disincentivise spammers. A decay function sounds like a good idea on that basis.
Jump to: