Hacker News Reader

Comment by alexro | Hacker News Reader

"Economic majority" of bitcoin space have already agreed not to follow BU, that's why not many talk about it.

Btw, I checked how you arrived at the conclusion that 'economic majority' have agreed not to follow BU. And I must say that I'm skeptical of your claim. Do you have any links?

With the addition of AntPool, the total hash rate for BU is up to 38% now. So this seems to suggest otherwise. Unless your definition of economic majority is some entirely different.

"38%" is still a minority, isn't it? Besides, this is counting miners, but what about businesses - almost none are interested.

Well, the confirmation time problem and the transaction fees problems aren't going to go away anytime soon right? They're only going to get worse. So what's the opinion of people who have agreed not to follow BU? Let the transaction fees increase till transactions <$10 will be stupid to make?

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.

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-...

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

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.

Lightning is supposed to reduce transaction fees whenever it finally gets released.

Well, that doesn't make the problem that's been snowballing since the last year go away. It is really hurting the adoption of Bitcoin. I usually use it for small transactions <$10 for situations where I don't want to give out my personal billing details.

If this continues for another year, I'll have to say bitcoin has severely failed to follow up on the promises it made, one of which is low transaction fees. Not >5%

I stopped following the politics of the scaling debate some time ago, but it appears at a glance that BU has a good trajectory for next iteration protocol: http://xtnodes.com/#all_nodes

Reply on news.ycombinator.com