On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 3) In terms of complexity for mining pool operators, how well does this >> model scale if there are N soft forks and the pool doesn't want to opt-in to >> any of them? Couldn't this result in those pool operators having to run not >> just one border node, but a multitude of "chained" border nodes if the soft >> forks are spread across different software implementations? > > While BIP9 allows for 29 parallel deployments I think it is unrealistic to > expect there would be such a high number of active parallel deployments at > any one time: History shows soft forks take a minimum of 6 months design, > consensus building, coding and testing before deployment. With such a high > bar, I do not envisage more than a couple of parallel deployments at any > given time. I also do not envisage "conflicting" soft forks, as that would > not meet consensus from the technical community on the basis of safety and > sanity. In any case, the deployment strategy of each soft fork should be > considered on a case by case basis. The relationship between a codebase and chain fork implementations is similar to vendor lock-in, and is being used in a similar manner. There is nothing preventing a single codebase from implementing all forks and exposing the option to apply any non-conflicting combination of them. While this has not been the norm libbitcoin now utilizes this approach. Currently the options to apply any activated Bitcoin forks are exposed via config. I personally am not working to implement non-activated forks at this point, but that's just prioritization. Recently I objected to BIP90. This hard fork is presented as a code simplification and a performance optimization. I showed in the discussion that it was neither. Nevertheless we implemented this additional code and give the user the option to apply it or not. It's application produces no performance benefit, but it ensures that the choice of forks remains in the hands of the user. e _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
