That is a positive scenario we are all hoping for, should BIP 101 succeed. The concern is what % of clients XT will represent in this scenario. If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.
Based on Hearn's previous proposals, and his complete control over XT, potential features include:
- Automatic updates
- Coin tainting
You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect. It is not possible to force anyone to run specific client code as long as there are alternatives, which there will be. If you're worried about fungibility then please, let's work on useful things like stealth addresses or built-in mixing or gmaxwell's privacy features based on ring signatures.
I assure you that any sort of coin address lists included in a bitcoin wallet software as you've suggested will not happen or they will be soundly rejected by the community. Devs are going to leave the policing up to the coinbases and chainalysises of the world. There's absolutely no reason to include those features in the wallets - users don't want it, miners don't want it and law enforcement doesn't need it.
For the record, I'd jump ship if any of the above happened.
It isn't completely theoretical when you consider his previous proposals. He has proposed repeatedly putting central trust-based control into Bitcoin, and he has complete irrevocable control over XT. Yes, it is possible he won't do all this bad stuff in XT. But, you have to consider how he could do this BEFORE he does it in order to avoid it, because control is a sneaky thing that can creap in over time.
Here is a possible plan that could create an irreversible situation, one where you cannot just escape by quitting using XT:
1. Obtains a critical mass of clients. Let's say 75% of miners are running XT code.
2. Introduces automatic updates for "security reasons". This will help relieve the pesky decision making progress with upgrades.
3. Introduces ability to identify XT clients.
4. Puts in DoS code based on blacklists and prioritization that are distributed and signed by XT nodes, giving a higher priority to XT connections. This effectively de-prioritizes non-XT nodes. Can also easily adds non-XT nodes to lower priority lists (blacklists). He already put the code into XT, with documented plans to make it utilize more node coordination. Clearly, the only nodes that are candidates for doing this coordination today are XT nodes, as Core rejected this proposal.
5. In order to "combat crime", introduces coin tainting (another one of his famous ideas) that can revoke the wealth of those who object, with a negative bias towards non-conforming (non-XT) nodes.
Now, people wake up and realize this is bad stuff. What happens when you use a non-XT client? At this point, it is too late to undo. Technically, you can accomplish all of this without changing the Bitcoin protocol, although this would presumably require different chains and protocols. With 75% critical mass, however, one could just as easily change the consensus protocol to make it more irreversible. He's already proved he is willing to do that.
Yes, there is theory here, as we are talking about a possible future. Yet, given past proposals to add centralized control to Bitcoin, and his completely control over XT, this is not out of the realm of possibility. The core risk of Mike's previous proposals which he has become known for is the introduction of central control and trust to our decentralized trust-less Bitcoin. So, the better question is why would he not use XT to implement his vision?
"2. Introduces automatic updates for "security reasons". This will help relieve the pesky decision making progress with upgrades."
Dude...I stopped reading after this. If any developer were to attempt to introduce auto-updates, it'll get rejected right off the bat.