Bitcoin Forum
July 16, 2024, 07:10:42 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap  (Read 9341 times)
goatpig
Legendary
*
Online Online

Activity: 3696
Merit: 1356

Armory Developer


View Profile
August 29, 2015, 04:07:40 PM
 #61

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).

I have no experience with network design so I can't alone come up with a proposal that accounts for the entire engineering scope the metric affects. Maybe I would be more motivated to run with my own proposal and implementation if I did.

btcdrak
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile
September 02, 2015, 12:20:49 AM
 #62

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.

Did you formally request the BIP number? Can I suggest you open a PR in the bips repository and gmaxwell can assign you a number there. That's how I got mine for BIP 105.
CounterEntropy
Full Member
***
Offline Offline

Activity: 214
Merit: 278


View Profile
September 02, 2015, 12:42:56 AM
 #63

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.

Did you formally request the BIP number? Can I suggest you open a PR in the bips repository and gmaxwell can assign you a number there. That's how I got mine for BIP 105.

Wont BIP 105 be included under https://github.com/bitcoin/bips/ like BIP 101 ?
btcdrak
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile
September 02, 2015, 07:17:17 AM
 #64

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.

Did you formally request the BIP number? Can I suggest you open a PR in the bips repository and gmaxwell can assign you a number there. That's how I got mine for BIP 105.

Wont BIP 105 be included under https://github.com/bitcoin/bips/ like BIP 101 ?

It's there as a pull request for the time being: https://github.com/bitcoin/bips/pull/187. I think there's still plenty room for some discussions.
juiceayres
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
September 02, 2015, 10:44:30 PM
 #65

Good job OP! I've seen this discussion about dynamic block size about 2 years ago, but no one was able to introduce it formally.

I would prefer the proposal 1 (keep it simple) with some modifications, in order to not have a unnecessary block size. Imagine an actual block size of 20mb. The next jump would be 40mb to just use maybe 22mb.

I suggest to sum a discrete amount to Maxblock size (e.g 12.5%) up to doubling it the current day (~next 144 blocks).

Code:
If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
    MaxBlockSize = MaxBlockSize+ 12.5%
    Limit = Double MaxBlockSize_last_144

I think increasing by discrete amounts can damp the system, making the block size more predicable and reducing the tx fee gambling.

The same principle can be added to cut block size.

 


upal (OP)
Full Member
***
Offline Offline

Activity: 165
Merit: 102


View Profile
September 05, 2015, 09:35:01 PM
 #66

This BIP has now been assigned a BIP number and pulled into BIP repository on Github.

BIP 106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki
CounterEntropy
Full Member
***
Offline Offline

Activity: 214
Merit: 278


View Profile
September 06, 2015, 12:12:23 AM
 #67

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.

As I can see, you have talked about various numbers, like 66~75%, 20% etc. These appears to be magic number to me, like BIP 101's 8mb or BIP 103's 4.4% & 17.7%. How do you derive them ?
goatpig
Legendary
*
Online Online

Activity: 3696
Merit: 1356

Armory Developer


View Profile
September 06, 2015, 07:49:30 AM
 #68

As I can see, you have talked about various numbers, like 66~75%, 20% etc. These appears to be magic number to me, like BIP 101's 8mb or BIP 103's 4.4% & 17.7%. How do you derive them ?

I've said stated all these figures need to be discussed. I believe these thresholds need to exist, but a decent value or a decent way to compute these values needs to be discussed. I can give you the reason these values need to exists but I have not done the research to determine which figures are the most appropriate, of it there is a way to set these dynamically as well.

The 66~75% figure is a proposal for the block space usage threshold at which a resizing should be tested against secondary conditions. The rationale is that organic market growth will always burst through any threshold (until it hits a hard cap eventually), whereas an attacker won't necessarily. Raising the space usage threshold increases the effort required by ill intentioned parties, and doesn't change a thing for natural market growth. As a reminder, the current threshold is 50%.

The 20% figure denotes the fee growth threshold, i.e. a resizing should only occur if fees have gone X% either way compared to the previous period. Currently there is no such threshold, making it trivial for any attacker to push up the block size and maintain it high.

As long as these thresholds are in place and tight enough, an effective decay function can be implemented. The goal is to distinguish between organic growth in demand and spam attacks, and use a safety net mechanism (the decay function) to correct all growth that is not supported by actual demand. It would actually mimic commodity prices in a speculative market: large speculators can pump the price for a while but eventually the market will always correct itself, with the valid demand as its baseline.

The first threshold is not very important. It will always be reached first when demand climbs, so its particular value is not all that important. It could be 90% for all I care, because fees won't start climbing until blocks are nearing max capacity. It needs to be > 50% to make room for the decay function.

The threshold that needs to be truly discussed is the second one. It can't be low enough that an attacker can throw a couple extra BTC at the network and trigger a size growth on the cheap under the right conditions. It can't be so big the network will get clogged with a massive backlog before it resizes. However, an increase in fee subsidy is an increase in revenue, which will translate into an increase mining power eventually. It can be expected that such tight thresholds will result in bursty cap growths, which is another reason for a decay function, but generally I believe we are better with high values than low ones.

Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!