Can we get this translated into Chinese for the benefit of f2pool, before they do something foolish and regrettable?
https://t.co/3IY2PKIjsXThe Scaling Announcement Bitcoin Core Should Have MadeBy the Bitcoin Core Developers (a complete list of signers can be found below)
We’re here to talk about scaling and the roadmap we’ve set for Bitcoin Core.
As with any roadmap, we’ve heard your feedback and we want to continue to hear it, so please keep it coming.
We’ve had extensive conversations with all of you — from the miners to the wallets and exchanges to everyday community members — and want to make it clear that we’ve listened to everything you have to say with regards to the growth of the bitcoin blockchain and evolution of Bitcoin core.
We feel we have a fair grasp of what your needs are and are well-equipped to examine them against the constraints of the Bitcoin network and the software that powers it, and determine how best we can make everyone happy and ensure that the system is fully operational and is able to scale.
Part of this work means looking at a variety of increases to the Bitcoin block size and doing extensive analysis and testing to determine the effects that each of these increases would have.
As many of you may be aware, we have to be aware of two facts:
Increasing the capacity of the bitcoin blockchain is critical. Bitcoin needs to grow and support more and more users, and each of these users needs to have access to relatively low transaction fees.
Block size increases should not be taken lightly and it is imperative they be carefully tested beforehand. Block size increases impact many aspects of the Bitcoin network and do have the potential to reduce decentralization and network stability.
It is clear that both of these are largely in conflict with one another, and so they will have to be weighed against one another and a compromise will need to be reached.
Just because we have the need to support certain levels of usage, doesn’t mean we should dare to compromise either the stability of the system or the level of decentralization that makes Bitcoin so unique and powerful. And just because we have a fear of the effects of block size increases does not mean that we should fail to subject such increases to real world tests and do everything we can to increase the system-wide capacity.
Bitcoin will scale, but it will require a combination of efforts and it will be a gradual process. So we need to come together and agree on the tradeoffs we’re making and we need to be patient.
Last, we need to be civil and respectful of one another and make sure we all come together to push Bitcoin forward.
We’ve done some extensive real world testing on many global test beds, including Princeton University’s Planet Lab, the largest in the world. From this we’ve concluded that 8MB blocks are simply too large to be considered safe for the network at this point in time, considering the current global bandwidth levels.
So while many of us may want to shoot for the stars, we must agree that it is more important to ensure that the network remains healthy and strong.
At the same time, it is important that we push for an increase that is as big as we can safely handle, and we believe that Adam Back’s 2–4–8 proposal that scales the block size to 4MB after 2 years and then to 8MB after 4 years is the plan of action that is the most ambitious while still being safe.
In addition, it seems we can do even better in terms of performance by sticking with 2–4–8 but allowing non-fully-validating nodes to ignore approximately half of this data. This would be a big improvement that would alleviate the pressure that we’ll be putting nodes by scaling the block size. The improvement is being called Segregated Witness and involves separating signatures out from the main block and putting them into a Merkle tree that only fully-validating nodes have to see.
We want to roll this plan out slowly and carefully, and we believe the best course of action is to first roll out Segregated Witness so we can get a quick win on an approximately 2x data capacity increase. This would involve removing signatures from the main portion of blocks, which would double the number of transactions that can be fit into the current 1MB limit (this means the effective limit would be 2MB).
Next, we plan on shifting gears to prepare for the hard fork that would put Adam Back’s 2–4–8 proposal into place alongside Segregated Witness, where the limits would be scaled to account for the optimizations made by Segregated Witness (the limits would be approximate limits that would continue to include signature data).
Beyond this, in order to prepare for the two bumps over the next 4 years and ensure that orphan rates don’t increase, we’re working on integrating efficient relay techniques like the relay network and IBLT, so that most block data is disseminated throughout the network even before a block is found.
Further, we’ll be working hard on preparing for the hard fork that will need to come with the second increase. We’ve bought a bit of time considering that the cleverness of Segregated Witness will allow us to do the first doubling with just a soft fork, which will reduce risk in the short run. And of course, this hard fork should not be taken lightly as hard forks in general do pose a significant risk of network fracturing, which could result in a significant monetary loss for stakeholders.
In summary, this roadmap is meant to do the best possible job to address the growth needs felt by all Bitcoin stakeholders, while ensuring the stability and decentralization of the Bitcoin ecosystem.
We want to stress that Bitcoin Core is comprised of a group of volunteers that don’t always agree themselves and many discussions amongst us and Bitcoin stakeholders were required to get us all on the same page.
We have thought long and hard about this proposal and think it is the best of both worlds. But we still want to hear from you about this roadmap and get your input. We are committed to continuing to engaged fully and publicly with the wider community.
The future of Bitcoin is about all of us and we need to work together to push it forward.
Thank you,
The Bitcoin Core Developers
read the link.
this is from Ryan Shea, not the core devs.
Show Posts
