...

[iCEBREAKER]

https://www.reddit.com/r/bitcoinxt/comments/3id0rf/slush_gets_another_bip_101_371472/cufg7bg

How am I ignoring the game theory?  I already explained why/how NotXT exacerbates the risk for defections to XT, by minimizing its chances of success.  And OrganOfCorti mathed the hell out of that, leaving no doubt those brave enough to accept XTcoins are going to have a bad time.  

What is it that you don't get? Slush is indicating support for >1MB blocks via XT/BIP101. Since no version of XT or only-bigblocks or Core will accept >1MB blocks prior to January 2016 then it doesn't matter that he hasn't updated to XT or BIP 101 mining prior to then. Is your point that the NotXTers will move to BIP101 or XT in January 2016? That seems to not quite be in the spirit of NotXT.

I read the OrganOfCorti comments - he used numbers ranging between 0.16 and 0.21 of fake voters. That's fine - if it's a small number of fakers then it doesn't matter. The more the fake votes increase, the better the chance for 'premature activation'. Go ahead...run NotXT - gamble away, but you sure can't take the moral high ground.

Moral high ground?  When did that become an issue?  This is war, not an ethics symposium!  

Corti demonstrated a small number of fakers is unlikely to matter immediately, but because XT features a perpetual election even low probabilities manifest eventually.

Your hand-waving "it doesn't matter that [slush] hasn't updated to XT" objection sounds like imaginary_username, who likewise fails to understand

If you're only pretending to run a version of bitcoin that has BIP101 implemented by changing your header version, that is spoofing, regardless of what your intentions are.

The header version is supposed to show that your nodes will actually accept a >1MB block as per BIP101, not that you support the idea of BIP101.

[erik777]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

^^-- LIKE

Bottom line, is we need to discuss our current options, before we lose those options. 

[erik777]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

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
- Redlists
- Blacklists
- Whitelists
- Coin tainting

[Muhammed Zakir]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

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
- Redlists
- Blacklists
- Whitelists
- Coin tainting

Maintainer making decisions for all code changed rather than unanimity/consensus.

[iCEBREAKER]

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
- Redlists
- Blacklists
- Whitelists
- Coin tainting

Bitcoin's CTO calls out Gavin@tla.mit.gov and Heam@sigint.google.mil for being epic shitlords:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010439.html

[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015


It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war.  Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings.  Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations.  Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented.  They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues.  (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

[sAt0sHiFanClub]

Myself and many other people warned
 Gavin a network fork "war" would start

Is he advocating "Ballot box in one hand, and an Armalite in the other"?

[HarHarHar9965]

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user and although it states that is used for blacklisting purposes, it does go against the very fundamental of bitcoin. Why is the Bitcoin XT project not being discarded by the bitcoin users then? What is making them disregard their privacy and fuel hearn's shitty attitude? WHY

[sAt0sHiFanClub]

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user

Ah, no it doesn't.  Simple words are just wrong. Have a read through the thread again.

[uxgpf]

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
- Redlists
- Blacklists
- Whitelists
- Coin tainting

Bitcoin's CTO calls out Gavin@tla.mit.gov and Heam@sigint.google.mil for being epic shitlords:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010439.html

[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015


It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war.  Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings.  Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations.  Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented.  They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues.  (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

Just for completeness, here's the reply.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010496.html

[bitcoin-dev] Bitcoin XT Fork
Mike Hearn hearn at vinumeris.com
Thu Aug 20 09:00:14 UTC 2015

>
> It is just that no one else is reckless enough to bypass the review process


I keep seeing this notion crop up.

I want to kill this idea right now:

   - There were months of public discussion leading to up the authoring of
   BIP 101, both on this mailing list and elsewhere.

   - BIP 101 was submitted for review via the normal process. Jeff Garzik
   specifically called Gavin out on Twitter and thanked him for following the
   process:

   https://twitter.com/jgarzik/status/614412097359708160

   https://github.com/bitcoin/bips/pull/163

   As you can see, other than a few minor typo fixes and a comment by sipa,
   there was no other review offered.

   - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
   request, to invoke the code review process:

   https://github.com/bitcoin/bitcoin/pull/6341

   Some minor code layout suggestions were made by Cory and incorporated.
   Peter popped up to say there was no chance it'd ever be accepted ..... and
   no further review was done.

So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.

[JorgeStolfi]

[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015

[ ... ]Myself and many other people warned Gavin
a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings. [ ... ] People can not blame bitcoin core or me,
that this then predictably  happened exactly as we said it would - it
was completely obvious and predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path. [ ... ]

The war would not have happened if Adam had not labored so hard to create it.

The NotXT fork and the DDoS attacks on XT nodes may not have been his idea, but
he does seem to think that they were "well done".

EDIT:  There are other options for a higher block limit than full BitcoinXT --
such as a patched BitcoinCore, BitcoinXT with only BIP101, or simply editing
the MAX_BLOCK_SIZE line to raise the limit on a fixed date.  Raising the limit to 8 MB
does not present any demonstrable risk, but avoids congestion and
reduces risks and consequences of spam attacks.  Adam did not start the war
for technican reasons, but only to protect Blockstream's  power grip on
the protocol. 

[tvbcof]

The war would not have happened if Adam had not labored so hard to create it.

The NotXT fork and the DDoS attacks on XT nodes may not have been his idea, but
he does seem to think that they were "well done". 

The idea of patching a client was something I thought of out of thin air and suggested in the last round of wars near the begining of the year as I recall.

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

[JorgeStolfi]

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

The BIP66 voting was inept too.  It was the ineptitude of the Core devs, not dishonest miners, that caused the two "forks of July" (6-block and 3-block long, respectively) and required broadcasting to all clients the embarrassing alert "everybody had better wait for 30 confirmations for a while".

The BIP100 voting scheme is a joke.

I think that blcokchain voting in general is a stupid idea, but the 75% of the BIP101 voting is not bad.  Any brat can set up NotXT nodes to falsify the node statistics; miners, however, will not want to play games with their revenue.  If they are against BIP101, their interest is to vote against it, to prevent the 75% trigger to happen. Why would they want to trigger a messy fork and then have it collapse?  That is the sort of puerile "cut the nose to spite the face" reprisal that only a Blockstream worker would find amusing...

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

If Adam had not been born, BitcoinCore would probably have lifted the block size limit years ago...

[canth]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

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
- Redlists
- Blacklists
- Whitelists
- 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.

[canth]

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user and although it states that is used for blacklisting purposes, it does go against the very fundamental of bitcoin. Why is the Bitcoin XT project not being discarded by the bitcoin users then? What is making them disregard their privacy and fuel hearn's shitty attitude? WHY

So let me get this straight, you think that the Tor project is tracking bitcoin users since that's where the IPs are downloaded from? Shh...don't tell anyone but Bitcoin Core has a tracking feature where the first time you launch it, it tracks your IP via the DNS seed too. Better not run that either. Damn centralization! /<sarcasm>

And as far as the IP address prioritization goes, let me ask you this. In the event that you run a node and all incoming connections are full - how do you think that connections should be prioritized? Should new connections be ignored? Should you drop some Tor IP address to make room for other connections? Hearn came up with a prioritization that you don't like - fine. Disable it or come up with something better or run Bitcoin Core or run only-bigblocks. Lots of options and yet you choose to spread misinformation.

[canth]

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

It's amazing - Bitcoiners out of one side of their mouth talk about decentralization and freedom. On the otherside, they really seem to not like it so much when there's decentralization on the decision and development process. Doesn't that sound strange to you? It's fine that you don't like Hearn or Gavin, but why not just say that? It can't be that you really think that Bitcoin is the Blockstream Company or nothing, do you?

[erik777]

Just for completeness, here's the reply.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010496.html

[bitcoin-dev] Bitcoin XT Fork
Mike Hearn hearn at vinumeris.com
Thu Aug 20 09:00:14 UTC 2015

>
> It is just that no one else is reckless enough to bypass the review process


I keep seeing this notion crop up.

I want to kill this idea right now:

   - There were months of public discussion leading to up the authoring of
   BIP 101, both on this mailing list and elsewhere.

   - BIP 101 was submitted for review via the normal process. Jeff Garzik
   specifically called Gavin out on Twitter and thanked him for following the
   process:

   https://twitter.com/jgarzik/status/614412097359708160

   https://github.com/bitcoin/bips/pull/163

   As you can see, other than a few minor typo fixes and a comment by sipa,
   there was no other review offered.

   - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
   request, to invoke the code review process:

   https://github.com/bitcoin/bitcoin/pull/6341

   Some minor code layout suggestions were made by Cory and incorporated.
   Peter popped up to say there was no chance it'd ever be accepted ..... and
   no further review was done.

So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.

Just for completeness, here's Peter's reply to Mike

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010497.html

[bitcoin-dev] Bitcoin XT Fork
Peter Todd pete at petertodd.org
Thu Aug 20 09:13:34 UTC 2015

...

No, I said there was no chance it'd be accepted "due to a number of
BIP-level issues in addition to debate about the patch itself. For
instance, Gavin has never given any details about testing; at minimum
we'd need a BIP16 style quality assurance document. We also frown on
writing software with building expiration dates, let alone expiration
dates that trigger non-deterministically. (Note how my recently merged
CLTV considered the year 2038 problem to avoid needing a hard fork at
that date)"

Of course no further review was done - issues were identified and they
didn't get fixed. Why would we do further review on something that was
broken whose author wasn't interested in fixing even non-controversial
and obvious problems?

The process is to do review, fix issues identified, and repeat until all
issues are fixed.

[tvbcof]

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

It's amazing - Bitcoiners out of one side of their mouth talk about decentralization and freedom. On the otherside, they really seem to not like it so much when there's decentralization on the decision and development process. Doesn't that sound strange to you? It's fine that you don't like Hearn or Gavin, but why not just say that? It can't be that you really think that Bitcoin is the Blockstream Company or nothing, do you?

Let it be known that I do not like Mike and Gavin.  Signed: ~tvbcof

I'm not talking about on a personal level since I don't know them.  Given their attitudes about certain things as reflected in their actions and activities, I probably would not like them on a variety of personal levels either though.

[erik777]

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
- Redlists
- Blacklists
- Whitelists
- 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?

[snarlpill]

Wow, this is fucked up and props to turtlehurricane for disclosing this Very important piece of information!

I have not read the whole thread yet, don't hate, I just came here after seeing BayAreaCoin's signature. Had to post to follow along with it in my subscribed threads and so I can catch up and read through what I've missed. Damn, drama on BitcoinTalk is so time consuming with 2 kids sometimes, but I always love to follow along and "be in the know"!

[wxa7115]

This is another nail in coffin of Bitcoin XT, its anti privacy and hostility measures have reached a point of no return for me. So I suppose the only thing left is to fork and see how it goes from there