Difficulty is unpredictable as well

Too bad that the devs from XT don't give a f*ck about it and you have to compile on your own or trust someone other than Gavin or Mike.

One thing that I don't understand is why does Bitcoin XT have the other features, such as auto-dropping of TOR nodes?  And can the Bitcoin XT node be forced into the 'quiet' node format?  From what I have found out, it looks like it leaks the node's IP address while it's supposed to be hidden.

As for the big block mod.  I guess I just don't see the value in it. jumping to 8megs on start, then auto-adjusting for transaction volumes would undermine the transaction fee market that is supposed to develop to priortize transactions.

Next, we examine the size of confirmed blocks that were involved in an orphan race relative to period averages. The chart below suggests that blocks in an orphan race are, on average, ~100kb / 20% larger than regular blocks that are not part of such races. This is likely the result of larger blocks taking longer to relay.

too bad they ruined it with all the extra code, now no one wants to trust XT.

No, it doesn't. Any miner can create a full block by generating their own transactions for free.

Next, we examine the size of confirmed blocks that were involved in an orphan race relative to period averages. The chart below suggests that blocks in an orphan race are, on average, ~100kb / 20% larger than regular blocks that are not part of such races. This is likely the result of larger blocks taking longer to relay.

It's hard coded that way in XT, not BIP101 itself. BIP101 could be implemented in Core overnight. Or am I mistaken?

BIP 100 isn't currently implemented. I guess we'd put together some more concrete thoughts if and when it is coded up.

My initial thoughts are that I prefer BIP 101 because:
The BIP 100 voting mechanism doesn't seem fully thought out. A majority of miners can always win any vote because they can just orphan blocks that contain votes for something they don't like. So the more complex approach doesn't seem really robust.

But that'd require special code. If most miners just adopt the defaults, then it's possible for a minority of hash power to drag the block size down to nearly nothing.

It's quite common for miners to just accept whatever the defaults are, regardless of whether they make sense. That's why we still see 750kb blocks sometimes when the network is actually backlogged (XT fixes this).

I think the reason is that miners, not unreasonable, assume the Bitcoin Core developers are selecting default behaviour in sensible ways. Alas it's not the case anymore, because they feel choosing opinionated defaults is "centralising". This is why the XT manifesto specifically states we will pick defaults as we think best.

The BIP100 default is 1 megabyte. Thus by default miners would be voting for no change. However what we need is change!

It gives miners additional power to modify the system for no obviously good reason beyond "some miners are saying they'd like more power". Miners are not the only stakeholders. Users, merchants, exchanges, etc matter too - if not more!

The upper limit is meant to be a kind of DoS limit, to stop troll miners generating giant mega-blocks. It's not meant to be a stick that miners can use to beat important but voteless economic players.

There's a risk that someone comes up with a business plan like this:   we will build a giant ASIC farm in the middle of a desert at the end of a piece of string and tin can (i.e. no bandwidth). This will be super cheap because of abundant land/solar/wind/whatever and the lack of bandwidth won't matter because we can just drag down the block size limit to ensure tiny blocks.

This would of course hurt the entire ecosystem for their own short term benefit, but BIP 100 would let them do that with just a small amount of the overall hash power.

Miners have just one job: order transactions by time. They shouldn't be doing anything else, and arguably, people already freak out about the concentration of power in the hands of big mining pools. BIP 100 would make this issue worse.

So these are my initial thoughts.

But i guess XT devs may not be out to destroy Bitcoin. (Maybe, always best to assume everyone's out to get you!)

Has it not been made clear enough that they stand to lose absolutely nothing by increasing the block size?

@joe_ekine a sensible & safe proposal. my money's on flexcap or pragmatic 2MB step then 4, 8MB over 4 years to have space for lightning r&d

I shall not support XT if it blacklists some ip address.

Of course not. But in typical dictator fashion they have managed to use their authority, PR & industry relations to instill false expectations into more simple users and steer the masses to get behind them against a "common enemy" on the premise of "inclusion" and general abuse of the sever misunderstanding of your typical redditor.

They absolutely have a right to release different code but it should stand on its own and not require a complete propaganda campaign.

A totalitarian power grab for the governance of Bitcoin. Not the proposition of a new implementation but an attempt a hijacking the consensus code behind political motives

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?

I have no idea what would be the effect on the network if a portion of the network did not use the default and used -disableipprio instead.