BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap

[RocketSingh]

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.

[DumbFruit]

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.

[RocketSingh]

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/

[Carlton Banks]

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/

That's much better. good work, upal

[skang]

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/

And the top comments state the problems which are exactly what I have said about it here and other thread.

[CounterEntropy]

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.

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.

[ZephramC]

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?

[upal]

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 ?

[DumbFruit]

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.

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.

I was not calculating transaction fees in cents, I was referring to the value of the transaction using an arbitrary exchange rate (USD) rather than the actual quantity of bitcoins in the transaction fee.

The point is that the rising value of Bitcoin could make transaction fee amounts in bitcoins appear to go down, even if the value of transaction fees is actually going up. This would deadlock this algorithm over the period of increasing value.

Looking at a different problem with the new proposal, the new checks were designed so that it would make sure transaction fees were going up before a block size increase took place, but it only considers the last ~4000 blocks (~27 days), so if transaction fees fall to any degree over a 27 day period and then rise, the check can be passed. In that way nodes would still consolidate to compete at lower transaction fees and larger blocks.
This could easily be gamed by paying huge transaction fees to oneself at the ending of this period, which costs a miner virtually nothing.

[ZephramC]

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 ?

Yes, that is what I mean.
BTW, I tried to contribute to your redit thread, but the formating and linebreaks there are mess, I hed to redelet my post 4 times :-). So I hope I did not cause any problems.

[upal]

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 ?

Yes, that is what I mean.
BTW, I tried to contribute to your redit thread, but the formating and linebreaks there are mess, I hed to redelet my post 4 times :-). So I hope I did not cause any problems.

Well, upalc.com is my personal blog and there are many common sections in the article pages. Hence I coded them in PHP.

Regarding the reddit post, it is not mine. I posted the BIP draft in bitcoin dev-list as per GMaxwell's suggestion. Someone read it there and posted it in reddit. But, I dont think, posting and editing your own post will create any problem for anyone.

[achow101]

Have you submitted this to gmaxwell yet for bip number assignment? If you did, what was his response?

[upal]

Have you submitted this to gmaxwell yet for bip number assignment? If you did, what was his response?

I did. On August 18, 2015 he said that normal procedure is to allow some time for discussion on the list and asked me to post the draft text as well. I did not have the draft text ready by then. As you'll see the draft (https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki) was made on August 24, 2015. So, after posting the draft text, I contacted him again for BIP no. Since then, I have not heard of him.

[CounterEntropy]

I was not calculating transaction fees in cents, I was referring to the value of the transaction using an arbitrary exchange rate (USD) rather than the actual quantity of bitcoins in the transaction fee.

The point is that the rising value of Bitcoin could make transaction fee amounts in bitcoins appear to go down, even if the value of transaction fees is actually going up. This would deadlock this algorithm over the period of increasing value.

Users can always spend what they feel correct to include their Tx in block. On ther other hand, miners can always chose which Tx they'll add. Now, if Tx fee goes down, but FIAT value of Tx fee goes up, then market will decide whether they'll still lower Tx fee or not. Bitcoin protocol do have this freedom and this proposal does not seem to block that either. So, I dont see any deadlock situation to arise.

Looking at a different problem with the new proposal, the new checks were designed so that it would make sure transaction fees were going up before a block size increase took place, but it only considers the last ~4000 blocks (~27 days), so if transaction fees fall to any degree over a 27 day period and then rise, the check can be passed. In that way nodes would still consolidate to compete at lower transaction fees and larger blocks.
This could easily be gamed by paying huge transaction fees to oneself at the ending of this period, which costs a miner virtually nothing.

Can not be gamed so easily, because this is not the only one check in proposal 2. There are two other checks as well and when all the three checks are satisfied over a period of time, then you can safely assume that the Tx volume is really increasing and max block size increase is happening due to market demand. Even if all these three parameters are gamed, miners have to keep burning an increasing amount of money to keep max block size cap up. If it is artificially increased, it'll automatically come down in coming difficulties, as soon as miners stop burning their money.

[achow101]

So one thing that people have pointed out in other threads that also mention this proposal is that a someone can spam transactions which fill blocks and forces the block limit up. Miners can also lower the block limit to an infinitely small amount. I think you should also add in upper and lower bounds on what the block size limit can be. Perhaps 1 MB and 32 MB to prevent this kind of thing from happening.

[99Percent]

It has come to my understanding (please correct me if I am wrong and why) that miners can inject bogus transactions in their blocks.

If that is true then this proposal is crap: miners can put whatever transactions with whatever fees to inflate the statistic to suit whatever new block size they target.

I firmly believe miners will do whatever it takes to make the blocksize as large as they can make it, via whatever mechanism allowed (includingi BIP100) since it will give them maximum flexibiility to decide. They can always soft limit if they choose after all.

[goatpig]

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 would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.

I will repeat my point: the status quo path, where the current size is maintained if no increase/decrease is triggered is damaging in that it becomes trivial to maintain a size increase after a spam attack or in case a miner wants to game the system. At the same time a decrease becomes quasi impossible with the current thresholds.

An increase should be triggered at 66~75% capacity, not ~50%, and the fees should be at least 20% superior to the cumulated subsidy of the previous period. This is critical as it forces an attacker to compound his effort to inflict several unnatural increase on the network instead of simply giving the network a nudge and maintaining the increase trivially.

The goal of this proposal is to automatically adapt the max block size to the demand, not to offer a voting mechanism where spammers and large miners alike can pump up the block size and keep it there at minimal cost. If this is what you are aiming for, then Garzik's approach makes more sense.

In order to dynamically resize the block ceiling, the algorithm needs to distinguish between spam/attacks and organic growth. The simplest way to one from the other is that spam is acute, organic growth is chronic (or long lasting if you prefer). This means natural growth will always eventually trigger an increase, which is why tighter thresholds make sense. Natural growth will always manage to get to a sane threshold, but the higher the threshold, the more expensive it is to game the system.

However, in case the attacker is willing to pay the price for an upscaling, the effect of that attack should fade once the attack is over, which why we should have a decay function instead of a status quo condition. Only organic growth will be powerful enough to maintain a ceiling increase. With proper thresholds, an attacker would have to keep on spending more fees and increasing the difficultly significantly to keep the ceiling on growing, which is the only way he'd have to force in a lasting effect. At this point he is better off just mining for profit as a sane market actor, which is what a PoW blockchain relies on to begin with: there is more profit in participating to the network than to attack it.

[RocketSingh]

I would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.

Assuming all your suggestions are implemented by OP, will Armory publicly come out in support of this proposal ? I am having a feeling that without support from any major player BIPs are just meaningless. Moreover, if the proposal is not from a core dev, it would get a hard time in getting even a BIP no.

[goatpig]

I would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.

Assuming all your suggestions are implemented by OP, will Armory publicly come out in support of this proposal ? I am having a feeling that without support from any major player BIPs are just meaningless. Moreover, if the proposal is not from a core dev, it would get a hard time in getting even a BIP no.

No, I speak for myself in all these matters. Etotheipi sets the technical stance for Armory. I've been a bitcointalk member since before Armory even existed, I believe that is sufficient a distinction to signify that my position is personal and does not reflect what Armory as a business believes is the better route.

If this proposal gets enough discussion and refinement, I may implement it myself to speed up the BIP number processing. Historically, Armory has been pretty neutral in consensus discussions, so I do not believe it makes us a big player in this particular field or that my voice as an Armory employee carries more than any other poster in D&DT.

If I believed I had some authority in this matter, I would just go ahead and implement my own proposal.

[Carlton Banks]

If I believed I had some authority in this matter, I would just go ahead and implement my own proposal.

Be fair on yourself. You have a more authoritative view than most others, seeing as your work (designing & implementing the block handling + storage for a major Bitcoin wallet) deals with both the subtle details and the overarching dynamics of this very topic (at least in respect of how Bitcoin works now).