How do SegWit and FlexTrans compare?

Flexible Transactions was started as an alternative solution when it became apparent that Segregated Witness was not going to be a viable protocol upgrade.

This document attempts to describe the reasons why this is the case and how the two solutions compare and where they are completely different.

The reader should realise that the two solutions were both started with a single goal in mind which is to solve the Malleability issue. Where FlexTrans aimed to keep it simple and small, SegWit had as a goal to avoid at all costs making changes that would get the new transactions rejected by old nodes. The reason for this is cited to be that old wallets and nodes have no need to upgrade after SegWit becomes operational.

The reality of the situation is that people will need to upgrade their wallet anyway. As Bitcoin gets its value from networking we can see that networking will cause a ripple effect of upgrades. People that receive a payment from a SegWit user will not have any progress reports of that payment unless they have a SegWit wallet. Users pay more to users that don't have a SegWit wallet. The networked basis of money makes it a certainty that practically all people need to upgrade. And that begs the question if there really is a benefit to the SegWit solution.

Lets start by looking at the end result. What did the implementations actually accomplish.

Features

In the last row this is about an economics issue where SegWit introduces "Two Buckets" with new pricing and new fee bidding. In the design of SegWit the signatures part of a transaction are to be charged 75% less than the rest, making two buckets of data. The designers of SegWit decided that the miners should incur the cost where miners do up to 4 times the work, for the same pay. This is an anti-feature where technical design is trying to gain an influence on economic policy and thus very much worth putting a cross in the SegWit column for.

Technical-debt-matrix;

This is about the cost of the design. As the term 'technical debt' implies, this is not a one time cost, this is an actual debt that needs to be paid off over time with more engineering cleanup. The actual cost paid is thus in future productivity and stability of the system.

Like any company or household, if you don't pay off your debt, you will eventually work for nothing other than keeping afloat and not make any progress.

Change	Segregated Witness	Flexible Transactions
Changes how transaction-signatures are found. They can't be assumed to be in the transaction anymore.
Changes how transactions are transferred over the network. Old clients won't receive the signatures.
Changes how block security is done, the merkletree is no longer enough, there is a second now.
Changes how block size calculations are done (two buckets). Blocks can't use all space.
Changes how sigop limits are calculated.
Changes how transactions are stored, there are now two parts
Changes how transactions can be created securely to avoid new malleability issues that SegWit introduced. Affects all bitcoin implementations.
Changes fundamentally how signatures are validated.

Future growth

Bitcoin is meant to be around for many years, even decades. People want a stable money.

SegWit has as its only feature for the future that it allows the Lightning Network to be deployed. The capacity increase is a joke compared to the needs of the network right now. It certainly is not a capacity that can be used in the future. Even with Lightning on top, the capacity allowed in a SegWit world will not allow Bitcoin to grow as peer to peer cash.

Flexible Transactions is not a capacity increase, it is a separate solution that can be combined very well with any capacity increase.
Additionally, it is a format that is made to be extended. Adding fields to the format is expected and can be done safely. FlexTrans even dictates in the specification the allocation of various forwards compatible fields which can be used for soft upgrades.

Deployment

The main drive for SegWit was to avoid forcing people to upgade. What we see today is that the same authors are pushing people really hard to upgrade to the latest version, even before SegWit is out. Their client refuses to connect to non-segwit peers for half the connections. They even used the alert system to get people to upgrade their client.

All this means that in actual fact the 'safe' upgrade strategy of SegWit is not happening. The natural conclusion is that the complexity introduced to avoid making people upgrade was wasted and there is no real benefit in their architecture over FlexTrans.

The Flexible Transactions deployment is a protocol upgrade that has as of today not been planned. The likely method is to decide that at a specific time (counted in blocks) in the far future this upgrade will become active. Allowing everyone many months to upgrade.
If a user did not upgrade before the date hits his client will give a warning and he will be told to upgrade. Until he does there will be no service. This will guarantee no loss in funds and no loss in security or privacy.

Conclusion

The Flexible Transactions solution solves all problems that SegWit solves. On top of the features that SegWit has it lists some more which are essential to a healthy on-chain future growth for Bitcoin.

Flexible Transactions cost a fraction of SegWit, both in code written and future work to keep the network running.

The goal of SegWit that it would be easier to deploy, allowing people to not upgrade should they not want it, turns out to not be reached and it ends up dictating economic policy which is a sure sign of bad design.

There is no reason to choose SegWit over Flexible Transactions.