Why not implement Bitpay's adaptive block size fork instead of the 2MB Classic?

InTheWoods

InTheWoods

Well-known member
Foundation Member
Code is available here https://github.com/bitpay/bitcore

Here you can find more about it straight from Bitpay's CEO https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.ccofqduk0

This is the best fork Bitcoin proposal to date. 2MB increase is silly when you think about it. It will require another fork in the not so distant future at some point. Some Bitcoin devs wanted an 8MB fork to be more future proof. The proposal Bitpay came up with is even better.

Why not implement this cool adaptive block size right now? I know we've voted for it already but it's not set in stone. Why not call another vote for a cooler adaptive block size implementation?
 
If it truly is a better solution....... I'd jump on...


When you say, "adaptive block size"
Do you mean that the 'block size' is dynamic?
If so... Yep - I like it...

[until somebody has a better argument as to why it would be a bad thing...]
 
InTheWoods said:
Code is available here https://github.com/bitpay/bitcore

Here you can find more about it straight from Bitpay's CEO https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.ccofqduk0

This is the best fork Bitcoin proposal to date. 2MB increase is silly when you think about it. It will require another fork in the not so distant future at some point. Some Bitcoin devs wanted an 8MB fork to be more future proof. The proposal Bitpay came up with is even better.

Why not implement this cool adaptive block size right now? I know we've voted for it already but it's not set in stone. Why not call another vote for a cooler adaptive block size implementation?
Click to expand...
Adaptive block size is unproven technology that could open vulnerabilities.

Since we have a block every 2,5 min, with 2MB blocks we would already have the same throughput as bitcoin with 8MB blocks. For it to be a problem we would need to be "bigger" than bitcoin expects to be. I think it can wait.
 
Not sure there's any
lynx said:
Adaptive block size is unproven technology that could open vulnerabilities.

Since we have a block every 2,5 min, with 2MB blocks we would already have the same throughput as bitcoin with 8MB blocks. For it to be a problem we would need to be "bigger" than bitcoin expects to be. I think it can wait.
Click to expand...
Not sure there's any risk here really. A discussion on the topic https://www.reddit.com/r/btc/comments/3zw3xj/bitpay_has_just_released_a_fork_of_bitcoin_core/
 
Oh, I think that vote was simply to show that we can make a decision on any issue super fast. When this is ready to be implemented, we don't have to stick to the one vote, we can vote again, saying "should we implement the adjustable block size solution or stick to the previously voted 2 mb blocksize increase?" and again, a new direction will be set. Basically, this was a PR demonstration, taken at an opportune time.

I've always seen Dark Gravity Wave as a precursor to an adjustable block size. Add a little buffer, and ya got it, nice and smooth :)
 
BolehVPN said:
Let's just wait and see how Bitcoin plays out with their current issues so we can learn from them. Dash is in no desperate need to consider this at the moment.
Click to expand...

You can say same thing about implementing a 2 MB block size, right? So since we gonna pick a path why not pick the best path and make the best choice? Also, consider that DASH is still young and hard forks are easy to implement at this point without much disruption but it won't be so easy once Dash grows and the network is widely used. Prevention is better than the cure. So I say let's make the right choice right now.
 
I still maintain the 2MB blocksize vote was a publicity stunt to show off the power of Blockchain Governance. No actual budget was approved through it and thus no binding agreement has been created imho.
We have to keep in mind that blocks do not magically all become 2MB just because we voted them to be so. It's a limit. A ceiling for how large blocks can not "must" become. If the transactional demand just isn't there, they'll remain at a few kilobytes. 1MB, 2MB or flexible size: doesn't matter without huge surge in tx volume.

Therefore I concur with those saying that we should wait for now and observe how the "Fork Wars" in the Bitcoin ecosystem play out. A "flexcap" sure sounds interesting but let's see what possible dangers might arise.
 
How will the miners get paid when the block reward approaches zero?

The original Bitcoin design factored this in: the fees would increase with adoption, while the mining subsidy decreases. If the block size is infinitely adjustable, then the competition for transaction priority is gone. Any change like this would probably have to a complex fee mechanism to incentivize mining such that it continues to scale along with adoption when the block reward decreases.
 
InTheWoods said:
You can say same thing about implementing a 2 MB block size, right? So since we gonna pick a path why not pick the best path and make the best choice? Also, consider that DASH is still young and hard forks are easy to implement at this point without much disruption but it won't be so easy once Dash grows and the network is widely used. Prevention is better than the cure. So I say let's make the right choice right now.
Click to expand...

What you say makes a lot of sense, but at the same time you have to be careful because that's how Bitcoin got into this mess to start with. A significant portion of the community is blocking consensus by urging that no action at all be taken until the "perfect" solution reveals itself. The best is always the enemy of the good, and anybody waiting for perfection will be waiting awihle.

Our blockchain already has 4x the capacity of Bitcoin's due to our faster block time, and we are of course a fraction of their size. I think we have time to wait and see what approach works, or to go ahead and go to 2 MB and then move from there when needed. It's very important to remember that Bitcoin doesn't have a spork system whereas we do. A hard fork in Bitcoin is rife with terrible possibilities if anything goes wrong. For us, it wouldn't really be a big deal, since the spork code can simply revert the changes.

Bridgewater said:
How will the miners get paid when the block reward approaches zero?

The original Bitcoin design factored this in: the fees would increase with adoption, while the mining subsidy decreases. If the block size is infinitely adjustable, then the competition for transaction priority is gone. Any change like this would probably have to a complex fee mechanism to incentivize mining such that it continues to scale along with adoption when the block reward decreases.
Click to expand...

This is a good point. Somewhere down the line, they're going to have to hardcode some sort of minimum transaction fee in order to incentivize network maintenance. Then again, Bitcoin's community seems to thing that full nodes should be run for free, so who knows!
 
Bridgewater said:
How will the miners get paid when the block reward approaches zero?

The original Bitcoin design factored this in: the fees would increase with adoption, while the mining subsidy decreases. If the block size is infinitely adjustable, then the competition for transaction priority is gone. Any change like this would probably have to a complex fee mechanism to incentivize mining such that it continues to scale along with adoption when the block reward decreases.
Click to expand...

Actually, that's not how it was supposed to work. Miners can set a minimum transaction fee, and they generally did (it was generally the suggested fee in the wallet) And the growth in usage was supposed to increase fee collection. Not raise the price to use Bitcoin, but earn more Bitcoin because more people were transacting and thus more fees would be received. That was the plan. There is no need to squeeze more coins out of people trying to use the network if you can get more people using the network.

1,000,000 transactions charged 0.0001 BTC = 100 BTC

Just as

1000 transactions being charged 0.1 BTC

This isn't about earning fees, it's about winning the block, and those in China have a crappy internet connection and they'd be slowed down only slightly with lag if they have to receive 8mb of information from the network to make a block (or something like that) and that is what this is about. The big mining farms are in China and they don't want to lose their edge, but for some technical reasons, they lose their edge with larger block sizes.
 
You must log in or register to reply here.
Back
Top