[TD-Linux]

As someone who will never run BU, I'd rather have segwit activate, which will bump the blocksize to ~2.1MB and also enable a lot of better payment channel implementations, like lightning, that can lessen the demand.

It seems very clear to me that simply increasing the block size forever to keep under some arbitrary fee isn't going to work, though the reasons I have against running BU are mostly to do with its implementation.

[kristianp]

Hmm, I didn't realise that segwit also changes the blocksize, but apparently it does:

https://medium.com/@SegWit.co/is-segregated-witness-a-block-...

[ktta]

I'm interested. Why aren't you going to run BU?

[TD-Linux]

BU doesn't implement a hard fork but rather potentially infinite hard forks, depending on two user controlled parameters. If the AD parameter is low (the default), then it will just be a long orphan chain, with effectively miner selected block size, but in kind of a gross way (for miners to limit block size they need to orphan other miners' blocks... but they might all have different settings, so it's a risky deal). You also don't know when a chain fork will happen. To avoid this, all users are supposed to coordinate their 'EB' parameter via some side channel, like Reddit. In my opinion this is very error prone, and maintaining consensus is the job of the software, not the user. Earlier hard fork proposals like BIP-100, BIP-101, etc which had BIP9 style voting, or even just a flag day that activate on a certain height, are far safer.

It also doesn't help that BU forked from an old version of Bitcoin Core, which means it's missing some new features and is slower.