@AdrianX :
Does this make "developer defined consensus" for changes to the bitcoin protocol easier for developers?
Developers can propose changes to the protocol as usual, but BIP9 / BIP135 gives them a framework within which to express the deployment parts, and so reduces the need for developers to re-invent a fairly boring wheel over and over.
It still requires miners (hashpower) to signal for activating the changes.
The easiest protocol change for a developer is one where they do not worry at all about activating in a synchronized way. To take a simple example - just change the "1" into a "2" , compile and run.
BIP9 and similar schemes exist because developers realize that activation of new rules depends on hashpower.
Why do you think changes should be easier to deploy?
Today, if you wish to safely deploy a hard fork with e.g. a supermajority like 75% (like Bitcoin Classic used to have for its proposed 2MB fork), as a developer you have a few poor choices:
a) allocate a bit that's not used in the BIP9 "standard machinery", and implement your own percentage threshold and grace period
b) override one of BIP9 bits and the explicit 95% threshold on it, violating one of the more or less accepted specifications of Bitcoin
c) implement some signaling completely outside the versionbits, or use something like a fixed height threshold or some other criteria that you derive from the chain state
None of these are really great options - they add complication, often without good technical reason.
I except some novel forms of signaling involving coordination on the parameters of the deployment, e.g. the blocksize coordination proposals like EC, BUIP055, BUIP056 etc. I think these are good developments to progress toward a rapid resolution on that front.
What are the positive impacts of making changes easier for developers in your opinion?
A common deployment activation framework like BIP135 reduces the need for custom code that is mostly one-off and must often be thrown away after a deployment activates, otherwise it results in code bloat. Less custom code means less opportunity for costly activation errors due to slightly different, perhaps not always well-tested activation implementations.
The "one-size-fits-all" approach of BIP9 has clearly not worked for a simple block size upgrade nor even SegWit, resulting in a plethora of different response proposals on both sides (EB+AD, BIP100, UASF etc.)
I don't think this is necessarily a good development - the more activation methods become used, the more complex every implementation needs to become if it wants to keep in sync with deployment activations.
Developers should be able to offer Bitcoin changes as hard forks. Soft-forks only results in potential for more coercion through miners. Developers need to maintain and evolve Bitcoin, even if it is just to scale it technologically without changing anything else about its fundamentals.
What are the negative implications of making changes to the bitcoin protocol easier for developers?
More choice can be confusing. That is the only downside I see.
I'd rather face that choice though, than see the currency decline due to inability to progress technically.
Do you see any way a state sponsored mining facility could benefit from this BIP in a way that gave them an advantage over rule changes?
No - this BIP still requires deployments (bits) to be announced in order for the market to support them, and does not change anything about the fundamental Nakamoto consensus.
Also, it preserves use of the versionbits field - precluding its use in overt AsicBoost if that's what you are referring to.
What incentive or economic impacts of such a BIP have you explored?
I've observed the ability of other cryptocurrencies to scale and upgrade through hard forks.
Their recent relative economic success compared to Bitcoin's observable market share decline have led me to assess that Bitcoin needs a BIP which provides an expressed way for hard forks to also happen (not saying soft forks are always bad - sometimes I think they are suitable).
