<p>Bitcoin</p>
<ul>
<li><p>Has SegWit and it's benefits and costs:</p>
</li>
<li><p>Code complexity (of acceptable amount)</p>
</li>
<li><p>Witness data is discounted in SegWit transactions, somewhat rectifying the fact that outputs are cheaper to create than to spend.</p>
</li>
<li><p>3rd person malleability fix for SegWit transactions</p>
</li>
<li><p>RBF transactions (optional, destroys 0-conf)</p>
</li>
<li><p>Compact Blocks</p>
</li>
<li><p>Ability to soft-forks to introduce new opcodes for SegWit transactions.</p>
</li>
<li><p>Quadratic hashing fix for SegWit transactions</p>
</li>
<li><p>Bech32 address format <code>bc1...</code> for SegWit transactions.</p>
</li>
<li><p>More secure P2SH addresses is Bech32 is used (no 160-bit hash function)</p>
</li>
<li><p>Signature covers value for SegWit transactions (useful for hardware wallets)</p>
</li>
</ul>
<p>A longer list can be found <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel="nofollow noreferrer">here</a></p>
<p>Bitcoin Cash</p>
<ul>
<li><p>Larger blocksize cap</p>
</li>
<li><p>Half-yearly hardfork (so lots of work for developers)</p>
</li>
<li><p>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)</p>
</li>
<li><p>Signature covers value (useful for hardware wallets) (based on Bitcoin's segwit sighash algorithm)</p>
</li>
<li><p>220 bytes OP_RETURN (No incentive for destructive data publishing methods such as P2SH-wrapped multisig)</p>
</li>
<li><p>CTOR transaction ordering (permuting leaves of a merkle scheme is not allowed for block templates, only one possible order)</p>
</li>
<li><p>OP_CHECKDATASIG (based on a feature in the Elements Alpha project)</p>
</li>
<li><p>OP_: CAT AND OR DIV ...</p>
</li>
<li><p>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)</p>
</li>
<li><p>Banned 64-byte transactions (Merkle leaf vulnerability resolved)</p>
</li>
<li><p>CashAddr address format (a modified version of the bech32 address format used for segwit addresses in Bitcoin)</p>
</li>
<li><p>Schnorr signatures beginning with 15th of May (using a specification based on a BIP originally proposed for Bitcoin)</p>
</li>
<li><p>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)</p>
</li>
</ul>
<p>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</p>

CC BY-SA 4.0
2019-04-26T17:17:19.330Z
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
CC BY-SA 4.0
2019-04-26T17:28:58.770Z
@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
CC BY-SA 4.0
2019-04-26T17:31:51.680Z
Also what does the "not provably" mean? Third party malleability is clearly not possible for segwit inputs.
Pieter Wuille
CC BY-SA 4.0
2019-04-26T17:44:28.217Z
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
CC BY-SA 4.0
2019-04-26T18:03:29.590Z
I might have misread "Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability." ([here](https://elementsproject.org/features/schnorr-signatures))
MCCCS
CC BY-SA 4.0
2019-04-26T18:05:14.790Z
Ah yes, that's right - but in SegWit that's not relevant anymore.
Pieter Wuille
CC BY-SA 4.0
2019-04-26T21:29:53.347Z
Bitcoin: Compact Blocks, FIBRE, Satellite downlink.
Jannes
CC BY-SA 4.0
2019-04-29T15:04:14.160Z
@MCCCS, from your answer it seems that "Has SegWit" is the only main feature added only to Bitcoin and all items below are a consequence (cost or benefit?) of SegWit?
Most of the items in the Bitcoin Cash list are unclear to me, could you add some links for further reading or a brief description to the items?
Several of my original questions are still unanswered, so I'll wait with marking your answer as correct. Thank you very much anyway @MCCCS!
mplattner
CC BY-SA 4.0
2019-04-29T16:47:05.553Z
@mplattner Thanks for the feedback. In a few days I’ll add a paragraph explanations to each.
MCCCS
CC BY-SA 4.0
2019-04-26T14:28:12.030Z
2021-02-05T13:15:49.430Z
2021-02-05T13:15:49.430Z
MCCCS
<p>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?</p>

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

<p>In particular, but not exclusively, I'm interested in:</p>

<ul>
<li>Which features are only implemented in one of both chains?</li>
<li>Do the data structures differ (blocks, transactions, inputs, outputs)?</li>
<li>Is there a difference in which script instructions are supported?</li>
<li>What about addresses and address types?</li>
<li>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?</li>
<li>Overall, what's the best approach to track past and future changes in both chains? Can you recommend any resources on that issue?</li>
</ul>

<p>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 <code>git log --oneline master --reverse</code> on both chains and diffed the results to get some insight, but it's still hard to detect changes that are relevant to me.</p>

<development><bitcoin-cash><bip>
What are the major technical differences between Bitcoin and Bitcoin Cash?
mplattner
# What are the major technical differences between Bitcoin and Bitcoin Cash?

(Asked by: username_0 on 2019-04-26)

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.

**Tags:** development, bitcoin-cash, bip


---

## 1 answers

### Answer by username_1 on 2019-04-26. Score: 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](https://bitcoincore.org/en/2016/01/26/segwit-benefits/)

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

> **Comments:**
> **username_2**: 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.  
> **username_1**: @username_2 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.  
> **username_2**: Also what does the "not provably" mean? Third party malleability is clearly not possible for segwit inputs.  
> **username_2**: 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).  
> **username_1**: I might have misread "Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability." ([here](https://elementsproject.org/features/schnorr-signatures))  
> **username_2**: Ah yes, that's right - but in SegWit that's not relevant anymore.  
> **username_3**: Bitcoin: Compact Blocks, FIBRE, Satellite downlink.  
> **username_0**: @username_1, from your answer it seems that "Has SegWit" is the only main feature added only to Bitcoin and all items below are a consequence (cost or benefit?) of SegWit? Most of the items in the Bitcoin Cash list are unclear to me, could you add some links for further reading or a brief description to the items? Several of my original questions are still unanswered, so I'll wait with marking your answer as correct. Thank you very much anyway @username_1!  
> **username_1**: @username_0 Thanks for the feedback. In a few days I’ll add a paragraph explanations to each.  

---

