Is it legit to claim that Bitcoin Unlimited is Core-compitable?

[Jihan]

I just want to listen to your thought on this question.

 

[Jihan]

If the Bitcoin Unlimited miner nodes set the max block size at 1MB, so it will accept blocks that is mined by Core nodes, and Core nodes should accept the block mined by Unlimited nodes.

 

[sickpig]

I'm not @theZerg, but BU if correctly configured could mine bitcoin core "compatible" blocks. Of course the same apply to the relaying of incoming blocks mined by core.

I let @theZerg explains setting in more details, though.

 

[cypherdoc]

If the Bitcoin Unlimited miner nodes set the max block size at 1MB, so it will accept blocks that is mined by Core nodes, and Core nodes should accept the block mined by Unlimited nodes.

yes, this is correct.

the only difference in the latest version of BU is that RBF is not enabled.

 

[solex]

I believe that it is correct to call BU compatible with Core.

The reason is that when something is delivered to a customer it has an "out-of-the-box" state. As long as the customer does not change anything then it has a defined behavior. For BU it is to be the same as Core (except no RBF, plus it has Xtreme thinblocks etc which are features not affecting compatibility).

A miner using BU has a GUI option to change his mined block limit. This affects compatibility, however Core also allows this limit to be changed by suppling software which can be changed and recompiled. So the only difference in compatibility for mining is that BU has an easier way of changing the block limit. Core allows it but it requires technical skill.

Incompatibility can happen when blocks larger than 1MB are being made by a 3rd application, like Classic, then BU will follow the more powerful chain-fork. In this scenario Core would be a minority implementation for hashing-power and we can say that BU is not behaving the same as Core. Yet, if Core later regained a majority of hashing power and the blocks were <1MB again, then BU would once again be compatible with Core, joining the Core fork and leaving the weak fork.

So, the answer is that BU is compatible with Core while the 1MB limit is effective on the chain with the most proof-of-work.

It would be interesting to read @Zangelbert Bingledack's opinion too.

 

[theZerg]

I think that solex answered this question about as perfectly as it can be answered.

 

[Zangelbert Bingledack]

I also agree with @solex's answer.

 

[Christoph Bergmann]

I also agree with the answers. To put it short:
- BU is compatible with Core,
- if Classic forks, it will stay compatible (which maybe is the best part)
- it is essentially core 0.12 with some changes
- most importantly it provides thinblocks, what could massively speed up block propagation in the whole network
- it doesn't include rbf

 

[freetrader]

Is there a need to elaborate on how exactly BU deals with RBF vs the Core implementation?

Or is it sufficient to assume that it neither validates nor relays opted-in RBF transactions?

My question is probably quite hypothetical given that RBF needs huge market acceptance before it can actually work reliably.

 

[Aquent]

Yes, BU is fully compatible with Core. RBF is not a consensus affecting setting, it is a policy, which has nothing to do with compatibility in my view. A miner can have rbf on or off and still be fully compatible. Same thing with Xthinblocks, that's just an added benefit for miners as it reduces bandwidth, but nothing that affects compatibility, or consensus code. Same with libsec. They have nothing to do with compatibility or consensus code.

So, technically, a miner using the BU client to mine blocks right now is very much the same as using a core client the two so being fully compatible.