From: Eric Voskuil <eric@voskuil•org>
To: shaolinfry <shaolinfry@protonmail•ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Mon, 27 Feb 2017 08:50:07 -0800 [thread overview]
Message-ID: <09746CD6-10FB-4F3B-B4E1-AE12E504141B@voskuil.org> (raw)
In-Reply-To: <EMmw5p_aZLoAKdZKan47iSwAq_X9flneBX-1nOOpIpk08NzihG0yZedl0R5G2HLwlrjUCqscSa9uVTKPc83ewQIXbjKOHXSDeX-i8AV7Suw=@protonmail.ch>
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
next prev parent reply other threads:[~2017-02-27 16:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-25 23:55 shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02 ` shaolinfry
2017-02-27 16:50 ` Eric Voskuil [this message]
2017-02-28 21:20 ` Luke Dashjr
2017-03-12 15:47 ` shaolinfry
2017-03-05 14:33 Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48 ` Eric Voskuil
2017-03-05 21:31 ` Nick ODell
2017-03-06 9:18 ` David Vorick
2017-03-06 10:29 ` Edmund Edgar
2017-03-06 23:23 ` Gareth Williams
2017-03-07 1:07 ` Edmund Edgar
2017-03-07 17:37 ` Eric Voskuil
2017-03-07 9:17 ` Tom Zander
2017-03-07 18:13 ` Eric Voskuil
2017-03-07 19:13 ` Alphonse Pace
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09746CD6-10FB-4F3B-B4E1-AE12E504141B@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shaolinfry@protonmail$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox