7

For a research project I'm trying to detect the major technical differences between Bitcoin and Bitcoin Cash. I know that BCH uses a larger block size and does not support SegWit. But what other differences are there?

I know this is a broad question - I'm looking for an overview only, not an exhaustive, detailed list.

In particular, but not exclusively, I'm interested in:

  • Which features are only implemented in one of both chains?
  • Do the data structures differ (blocks, transactions, inputs, outputs)?
  • Is there a difference in which script instructions are supported?
  • What about addresses and address types?
  • Do both chains commonly implement the same BIPs or are BIPs usually exclusive to one chain? Is there a list of which BIPs are implemented in which chain?
  • Overall, what's the best approach to track past and future changes in both chains? Can you recommend any resources on that issue?

Finding differences by looking at the code does not seem practical to me given the time it'd take me to pinpoint and understand all changes. I used git log --oneline master --reverse on both chains and diffed the results to get some insight, but it's still hard to detect changes that are relevant to me.

Improve this question

1 Answer 1

Reset to default
6

Bitcoin

  • Has SegWit and it's benefits and costs:

  • Code complexity (of acceptable amount)

  • Witness data is discounted in SegWit transactions, somewhat rectifying the fact that outputs are cheaper to create than to spend.

  • 3rd person malleability fix for SegWit transactions

  • RBF transactions (optional, destroys 0-conf)

  • Compact Blocks

  • Ability to soft-forks to introduce new opcodes for SegWit transactions.

  • Quadratic hashing fix for SegWit transactions

  • Bech32 address format bc1... for SegWit transactions.

  • More secure P2SH addresses is Bech32 is used (no 160-bit hash function)

  • Signature covers value for SegWit transactions (useful for hardware wallets)

A longer list can be found here

Bitcoin Cash

  • Larger blocksize cap

  • Half-yearly hardfork (so lots of work for developers)

  • Obligatory quadratic-hashing solution (based on Bitcoin's segwit sighash algorithm) (In Bitcoin, it's opt-in, because SegWit is, hence Bitcoin doesn't solve the attack vector)

  • Signature covers value (useful for hardware wallets) (based on Bitcoin's segwit sighash algorithm)

  • 220 bytes OP_RETURN (No incentive for destructive data publishing methods such as P2SH-wrapped multisig)

  • CTOR transaction ordering (permuting leaves of a merkle scheme is not allowed for block templates, only one possible order)

  • OP_CHECKDATASIG (based on a feature in the Elements Alpha project)

  • OP_: CAT AND OR DIV ...

  • Custom difficulty adjustment algorithm (This isn't feature. Little coins like BCH need more time-sensitive algorithms while large ones like Bitcoin need more precise ones that work over large time intervals)

  • Banned 64-byte transactions (Merkle leaf vulnerability resolved)

  • CashAddr address format (a modified version of the bech32 address format used for segwit addresses in Bitcoin)

  • Schnorr signatures beginning with 15th of May (using a specification based on a BIP originally proposed for Bitcoin)

  • Graphene, which is Compact Blocks but much more efficient since CTOR was introduced (it may work on Bitcoin too, this isn't a protocol feature)

And the larger difference is Bitcoin favors off-chain scaling while BCH favors on-chain. It won't matter in the long term, because off-chain protocols such as Lightning will come to BCH anyway while off-chain scaling needs on-chain scaling as well in the long term

Improve this answer
9
  • Maybe you want to group some of the items as sub-bulletpoints under segwit (malleability fix, quadratic hashing fix, and sig covers value are all mandatory fixes for segwit transactions; and there is also an address format for them called bech32, which cashaddr is based on). If you feel like listing who invented what, Blockstream should also be credited for the quadratic hashing fix, signature covers value, Schnorr signature specification, and the BCH-code based addresses. I don't think mottos or hearsay about decentralization count as technical differences.
    – Pieter Wuille
    Commented Apr 26, 2019 at 17:17
  • @PieterWuille Thanks pwuille, I had forgotten about a few of the SegWit's advantages, it seems much more neutral now. I've also made it community wiki.
    – MCCCS
    Commented Apr 26, 2019 at 17:28
  • Also what does the "not provably" mean? Third party malleability is clearly not possible for segwit inputs.
    – Pieter Wuille
    Commented Apr 26, 2019 at 17:31
  • 1
    I've made a few changes, and changes the explicit authorship attribution to just mentioning what features are based on (as authorship is hard to attribute exactly).
    – Pieter Wuille
    Commented Apr 26, 2019 at 17:44
  • 1
    @mplattner Thanks for the feedback. In a few days I’ll add a paragraph explanations to each.
    – MCCCS
    Commented Apr 29, 2019 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.