Author: Eric Voskuil 2017-02-27 16:50:07
Published on: 2017-02-27T16:50:07+00:00
On the Bitcoin-dev mailing list, a discussion was had regarding the scalability of mining pool operator complexity with regards to soft forks. The concern was raised that if there are multiple soft forks and a pool does not want to opt-in to any of them, they may have to run multiple "chained" border nodes across different software implementations. However, it was noted that it is unlikely that there would be a high number of active parallel deployments at any given time. Additionally, conflicting soft forks would not meet consensus from the technical community on the basis of safety and sanity. The relationship between a codebase and chain fork implementations is similar to vendor lock-in and has been utilized in a similar manner. While it is not the norm, libbitcoin now utilizes an approach where a single codebase implements all forks and exposes the option to apply any non-conflicting combination of them. Currently, the options to apply any activated Bitcoin forks are exposed via config. The implementation of non-activated forks is not a priority at this point.There was also discussion surrounding BIP90, which is presented as a code simplification and performance optimization. It was shown that it was neither, but the additional code was implemented regardless and users have the option to apply it or not. Its application produces no performance benefit, but it ensures that the choice of forks remains in the hands of the user.
Updated on: 2023-06-11T21:54:36.057856+00:00