FlexTrans Vs SegWit

[Hexadecibel]

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:

Feature                                          SegWit   FlexTrans
Fixes Malleability                             ✅       ✅
Linear scaling of hashing                   ✅       ✅
Hardware wallet Support                   ✅       ✅
Makes transactions smaller                ❌       ✅
Supports the Lightning Network          ✅       ✅
Signatures can be pruned (in future)   ✅       ✅
Double Spend Proofs                        ❌       ✅
Support future script versions           ✅        ✅
No "two buckets" economics              ❌       ✅


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.



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.


https://bitcoinclassic.com/devel/FlexTrans-vs-SegWit.html

As a personal note, There is nothing wrong with having multiple clients. Bitcoin Unlimited, Bitcoin Classic, and BitcoinXT even Core can work together to make bitcoin stronger.

Flexible Transactions is a better solution than SegWit. After the hard fork and the dust settles I imagine this will be where the next bout of discussion is directed.

[jonald_fyookball]

Very nice.

What stage of development is this?

Is it a whitepaper, coded, or what?

[AngryDwarf]

Available in bitcoin classic already I think.

EDIT: Looks like it was put in v1.2 beta (scroll to bottom).

https://bitcoinclassic.com/news.html

[dfd1]

Can you guys just settle already? Segwit is GOOD ENOUGH
And LN already coded

We don't need another three possible forks

[AngryDwarf]

Can you guys just settle already? Segwit is GOOD ENOUGH
And LN already coded

We don't need another three possible forks

Joseph Goebbels on his bike?

[DooMAD]

Consider me intrigued.  But while you list all the reasons why FlexTrans is better, you don't explain how it's actually achieving these grand claims.  I'll link BIP 134 here as well (that is the right one, isn't it?), which I'm only just starting to read myself.  At least that should give some detail of the inner workings of it all.

[AgentofCoin]

...  I'll link BIP 134 here as well (that is the right one, isn't it?), which I'm only just starting to read myself.  At least that should give some detail of the inner workings of it all.

From my simple reading and superficial understanding of the BIP.


1) FlexTrans uses the hardfork mechanism, so all old nodes will need to upgrade to
this version or die. SegWit tries to address some of this issues while not allowing the
old nodes to "die". Obviously, SegWit is using the softfork mechanism.


2) Also, it states "The idea is that we give each field a name and this means that
new fields can be added or optional fields can be omitted from individual
transactions.". This seems like it could introduce possible new attack vectors
that currently don't exist. New field choice could allow the creation of "clean coins",
which would render all non new flagged coins as "dirty coins" by omission. This could
assist miners in determining what txs not to mine, from data already contain within
the blockchain itself.

For example, imagine in a future world where governments mandate that your tx
can not be mined unless you place your Real Name or Government ID Number within
the new field option of your tx. Miners at this point in time, would be obligated by law
not to include your tx or face jail time or penalty. In places like China, this is a very
likely possibility and everything we should be against, if we're supporters of liberty.

Creating more "flexible options" creates more "possible attack vectors" that may not
be fully addressed or anticipated now.


3) If SegWit allows for new optional fields, I would be equally opposed based on my
same reasoning in (2).


"Security and Non-Regulatability" are more important than "Flexibility and Options".

[DooMAD]

...  I'll link BIP 134 here as well (that is the right one, isn't it?), which I'm only just starting to read myself.  At least that should give some detail of the inner workings of it all.

From my simple reading and superficial understanding of the BIP.


1) FlexTrans uses the hardfork mechanism, so all old nodes will need to upgrade to
this version or die.

2) Also, it states "The idea is that we give each field a name and this means that
new fields can be added or optional fields can be omitted from individual
transactions.". This seems like it could introduce possible new attack vectors
that currently don't exist. New field choice could allow the creation of "clean coins",
which would render all non new flagged coins as "dirty coins" by omission. This could
assist miners in determining what txs not to mine, from data already contain within
the blockchain itself.

For example, imagine in a future world where governments mandate that your tx
can not be mined unless you place your Real Name or Government ID Number within
the new field option of your tx.Miners at this point in time, would be obligated by law
not to include your tx or face jail time or penalty. In places like China, this is an very
likely possibility and everything we should be against as supporters of liberty.

Creating more "flexible options" creates more "possible attack vectors" that may not
be fully addressed or anticipated.

If SegWit allows for new optional fields, I would be equally opposed based on my
same reasoning above (except as for my (1) since SegWit uses softfork mechanism
which maintains the old nodes by tricking them until block inclusion).

Yes.  There are some interesting ideas, but some evident downsides too.  The "CMF" tag-based format may have potential attack vectors and with the change in serialisation format, all wallet software will have to support both the old and new formats for an indeterminate period, possibly forever.  There's another thread about this in Development & Technical that touches on some of the potential shortcomings.