Why Flexible Transactions is a hard fork?


Mar 16, 2016
Could @Tom Zander explain why, please? Does adding a new transaction type by having a different transaction version will always cause a hard fork?
Last edited:


Active Member
Aug 28, 2015
@HelloGuy try to ping him on Classic or BU Slack cause he sometimes has problems acceding the forum through for.


Staff member
Aug 28, 2015
yes flexible transactions requires a hard fork, or use of an extended block in a manner similar to the SegWit soft fork.

If flex transactions appear in a mainchain block, an old client cannot understand or validate them so sees the block as invalid. Therefore we have a "hard fork".

To implement it as a soft fork you'd place a "placebo" transaction in the 1MB block, similar to SW today, and then put the actual flex tx in an extended block. However, since flex tx is intended to simplify transaction structure, this defeats the purpose.

However, one cool feature of it is that the flexible transaction format is open ended so it could be used to create a system where Bitcoin can be extended yet remain compatible with old clients. So we would not have to hard fork for as many reasons in the future.

The rule is:

the majority chain can never soft fork a new transaction format that can reverse the payments of any other transaction format.

So let's say you are running an old client. You receive a payment, of a format you understand. You look back in that coin's history and see a txout that you did NOT understand. But that's ok (from an SPV sense -- i.e. you are trusting the miners and the blockchain depth to ensure that the txn is not completely invalid), because you received a txn that you do understand, and so you know that it is as irreversible as BTC transactions are today (i.e. you have to unwind the blockchain).
Last edited: