Hard fork contingency plans and SegWit readiness - a challenge to solution evangelists
Currently, the biggest discussion in the Bitcoin community concerns the possible forks we might see this year - Bitcoin Unlimited and SegWit. Whether those forks should or should not be activated and whether they will create a network split is an important discussion, but what is less discussed is the risk mitigation in case either of those forks happen. I would like to post a challenge to the various solution evangelists to see if their software is ready for any outcome.
Note - some questions apply to more than one scenario. Duplicates have been omitted for conciseness.
Lets say SegWit activates before Bitcoin Unlimited or any other block scaling solution takes place.
First, some questions to the Core team:
How much extra transaction throughput are you expecting to see with this solution?
Do you have any estimates as to how many transactions should move off-chain in the near future? When do you expect this solution to start reaching critical mass to alleviate the block congestion?
How many of the big Bitcoin companies will be ready for SegWit?
This important question is somewhat answered by a handy spreadsheet or two. Let's have a look and see if some important players are missing... Coinbase is "planned" so far. BitPay is nowhere to be seen. BitGo is "wip". Top exchanges - Poloniex, bitFlyer, BTC-E, OKCoin are missing. For the wallets - Armory, BreadWallet are wip, Bither, Exodus and Multibit HD are planned.
All in all, the coverage looks good, but some top players still need to get on board.
What are the fees users should be expecting?
A large pressure for the increase in the network capacity comes from the high fees to the average user. What fees should the users expect under SegWit? I've seen mention that on-chain fees will drop from 0.5BTC/block to about 0.2BTC/block, but some numbers on the off-chain fees would also be interesting.
What is the block scaling plan going forward?
Are you planning on changing the block size following SegWit? If so, when are we likely to see the size change and what would it be?
And a big question for the Bitcoin Unlimited team:
Is your client SegWit ready?
Are you ready to integrate SegWit into your client? Will it have some issues in case SegWit activates?
In this scenario, Bitcoin Unlimited activates first and the network splits itself into Bitcoin Core and Bitcoin Unlimited.
Question to both sides:
How are you mitigating the damages of the split for your users?
There are many things that need to be considered when the network splits. How are you mitigating the cross-split replay vulnerability? How will you avoid the confusion when it comes to addresses being the same on both networks?
Bitcoin Unlimited devs:
Is your code ready to be pulled to Bitcoin Core?
A lot of people consider Bitcoin Core to be the "gold standard" when it comes to Bitcoin clients. Developing a different client without allowing the options to be pulled into Bitcoin Core cleanly will only make the adoption of your client harder.
So, is your code ready to create a pull request to Bitcoin Core? Do you have a branch that is up-to-date with the latest commits to Core, or will you need to catch up? If you don't have these ready, it is almost inviting a network split, rather than working on keeping the network unified.
Will you be activating SegWit on your network?
There are some good use cases for off-chain transactions - will you be activating SegWit or other soft forks required to run off-chain transactions on your network anytime soon?
How are you planning to convince more exchanges to adopt Bitcoin Unlimited?
Some developers have sworn off BU completely - for example, BitGo (and thus indirectly - BitStamp, OKCoin, Kraken, etc.), while others might be on the fence. Do you have any plans on convincing them to start supporting your software?
Bitcoin Core devs:
Will you make your client opt-in compatible with Bitcoin Unlimited?
This question was originally asked by Gavin - since "Bitcoin Core does not want to and does not make decisions on Bitcoin’s consensus rules", is Bitcoin Core prepared to let the users op-in to be able to connect to the Bitcoin Unlimited network? It shouldn't be that much work to add a flag disabling the block size check at the very least.
In this scenario, Bitcoin Unlimited activates first, the network splits, but the minority chain gets attacked by miners in hopes of preserving only one side of the fork.
Bitcoin Core devs:
What is your contingency plan for such an attack?
As I understand, the current plan is to change the PoW algorithm in a hardfork. Is that hard fork already in the works? Is the new PoW algorithm decided on yet? Has the hardfork been tested? It is a large change - you don't want to be scrambling around trying to figure this out while an attack is ongoing. Do you have your legal side of things covered? Will you be coordinating actions with important Bitcoin players, such as exchanges?
Since hardforks don't come as often, are you planning on implementing any of the hardfork wishlist items while you're at it? Will the hardfork also include SegWit?
Bitcoin Unlimited devs:
What is your plan for such an outcome?
Will you be endorsing the attack, or will you be disowning it? Are you prepared for potential legal, community, etc. backlash you might receive if the attack takes place (even if it's not of your own doing)?
There are many important questions that need to be addressed early on before Bitcoin starts forking. While we might still have some time before either fork activates, it's better to mitigate the potential risks early on than to scramble when they actually take place. I'm looking forward to developers from either of the sides sharing their thoughts on the issues raised here.
Note - some questions apply to more than one scenario. Duplicates have been omitted for conciseness.
Scenario 1 - SegWit activates before Bitcoin Unlimited
Lets say SegWit activates before Bitcoin Unlimited or any other block scaling solution takes place.
First, some questions to the Core team:
How much extra transaction throughput are you expecting to see with this solution?
Do you have any estimates as to how many transactions should move off-chain in the near future? When do you expect this solution to start reaching critical mass to alleviate the block congestion?
How many of the big Bitcoin companies will be ready for SegWit?
This important question is somewhat answered by a handy spreadsheet or two. Let's have a look and see if some important players are missing... Coinbase is "planned" so far. BitPay is nowhere to be seen. BitGo is "wip". Top exchanges - Poloniex, bitFlyer, BTC-E, OKCoin are missing. For the wallets - Armory, BreadWallet are wip, Bither, Exodus and Multibit HD are planned.
All in all, the coverage looks good, but some top players still need to get on board.
What are the fees users should be expecting?
A large pressure for the increase in the network capacity comes from the high fees to the average user. What fees should the users expect under SegWit? I've seen mention that on-chain fees will drop from 0.5BTC/block to about 0.2BTC/block, but some numbers on the off-chain fees would also be interesting.
What is the block scaling plan going forward?
Are you planning on changing the block size following SegWit? If so, when are we likely to see the size change and what would it be?
And a big question for the Bitcoin Unlimited team:
Is your client SegWit ready?
Are you ready to integrate SegWit into your client? Will it have some issues in case SegWit activates?
Scenario 2 - Bitcoin Unlimited activates first, network splits
In this scenario, Bitcoin Unlimited activates first and the network splits itself into Bitcoin Core and Bitcoin Unlimited.
Question to both sides:
How are you mitigating the damages of the split for your users?
There are many things that need to be considered when the network splits. How are you mitigating the cross-split replay vulnerability? How will you avoid the confusion when it comes to addresses being the same on both networks?
Bitcoin Unlimited devs:
Is your code ready to be pulled to Bitcoin Core?
A lot of people consider Bitcoin Core to be the "gold standard" when it comes to Bitcoin clients. Developing a different client without allowing the options to be pulled into Bitcoin Core cleanly will only make the adoption of your client harder.
So, is your code ready to create a pull request to Bitcoin Core? Do you have a branch that is up-to-date with the latest commits to Core, or will you need to catch up? If you don't have these ready, it is almost inviting a network split, rather than working on keeping the network unified.
Will you be activating SegWit on your network?
There are some good use cases for off-chain transactions - will you be activating SegWit or other soft forks required to run off-chain transactions on your network anytime soon?
How are you planning to convince more exchanges to adopt Bitcoin Unlimited?
Some developers have sworn off BU completely - for example, BitGo (and thus indirectly - BitStamp, OKCoin, Kraken, etc.), while others might be on the fence. Do you have any plans on convincing them to start supporting your software?
Bitcoin Core devs:
Will you make your client opt-in compatible with Bitcoin Unlimited?
This question was originally asked by Gavin - since "Bitcoin Core does not want to and does not make decisions on Bitcoin’s consensus rules", is Bitcoin Core prepared to let the users op-in to be able to connect to the Bitcoin Unlimited network? It shouldn't be that much work to add a flag disabling the block size check at the very least.
Scenario 3 - Bitcoin Unlimited activates first, minority network gets attacked
In this scenario, Bitcoin Unlimited activates first, the network splits, but the minority chain gets attacked by miners in hopes of preserving only one side of the fork.
Bitcoin Core devs:
What is your contingency plan for such an attack?
As I understand, the current plan is to change the PoW algorithm in a hardfork. Is that hard fork already in the works? Is the new PoW algorithm decided on yet? Has the hardfork been tested? It is a large change - you don't want to be scrambling around trying to figure this out while an attack is ongoing. Do you have your legal side of things covered? Will you be coordinating actions with important Bitcoin players, such as exchanges?
Since hardforks don't come as often, are you planning on implementing any of the hardfork wishlist items while you're at it? Will the hardfork also include SegWit?
Bitcoin Unlimited devs:
What is your plan for such an outcome?
Will you be endorsing the attack, or will you be disowning it? Are you prepared for potential legal, community, etc. backlash you might receive if the attack takes place (even if it's not of your own doing)?
Conclusions
There are many important questions that need to be addressed early on before Bitcoin starts forking. While we might still have some time before either fork activates, it's better to mitigate the potential risks early on than to scramble when they actually take place. I'm looking forward to developers from either of the sides sharing their thoughts on the issues raised here.
0 Response to "Hard fork contingency plans and SegWit readiness - a challenge to solution evangelists"
Posting Komentar