What are the positives and negatives of Bitcoin Classic's Flexible Transactions? (related BIP 134)

Why aren't they used instead of Segwit? It seems that they solve the exact same issues as Segwit, in a more clear way.

The only issue I can think of is hard-fork vs. soft-fork, which is indeed an important issue, but if the code was cleaner, it's probably better to hard-fork. Also there are plans to hard-fork anyway by some miners, why aren't those for flextrans instead of segwit+large blocks?

Classic people themselves write There is no reason to choose SegWit over Flexible Transactions here


1 Answer 1


Why aren't they used instead of Segwit? It seems that they solve the exact same issues as Segwit, in a more clear way.

Segwit existed long before FlexTrans first came out and was almost ready for release by the time FlexTrans was even conceived. It has received far more testing and review than FlexTrans. In order to deploy FlexTrans, it would need to have much more testing, and have much more review.

Furthermore, FlexTrans requires a hard fork and for wallet developers to completely rewrite their serializers and deserializers to understand the FlexTrans format. Since Segwit is really just an extension of the current transaction format, it only needs a soft fork. This means that people can upgrade their software when they are ready and wallet developers only need to slightly modify their software in order to support segwit. They can also do so at their own pace. FlexTrans would require every wallet developer to perform a full rewrite or a new addition to their code which adds complexity and is more error prone. The FlexTrans format itself is also exotic and much more complex than the current format, and that can lead to potentially disastrous bugs.

Lastly, a hard fork to FlexTrans only transactions would completely break every single transaction in-flight at the time of the fork. It would make every single unconfirmed transaction that uses the current format invalid by the new hard fork rules, so every single unconfirmed transaction would need to be remade in the FlexTrans format. This also causes issues for transactions that have a lock time and the private keys necessary to spend those lock-timed coins have been lost/thrown away.

If a FlexTrans hard fork were to allow the current transaction format, then it wouldn't solve any problems. People would just keep using the current transaction format since using FlexTrans has no requirements to switch to using it. At least with segwit, if you have segwit outputs and want to spend from them, you must use the segwit transaction format. There is no such requirement to use FlexTrans. Furthermore wallet developers would then have even more complexity as now they need to have code that figures out when to use the current transaction format and when to use FlexTrans for serializing and deserializing a transaction. That is additional complexity and possibility for failure.

Therefore Segwit is preferred over FlexTrans. Segwit breaks less things, is easier to implement, and is backwards compatible, all of which FlexTrans is not.

  • 1
    Can you please note in the answer that the serialization format (CMF - sort-of-binary XML) is exotic and adds complexity (and possible bugs)? It's what sticks the most to me when I am reading the specs and the discussion around it. Jul 2, 2017 at 18:45

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.