"TL;DR:
The Flexible Transaction upgrade proposal should be considered by anyone who cares about the protocol stability because:
Its risk of failures during or after upgrading is several magnitudes lower than SegWit;
It removes technical debt, allowing us to innovate better into the future.
https://zander.github.io/posts/Flexible_Transactions/
There is currently a lot of interest and discussion about upgrading Bitcoin to solve various problems (eg: fixing transaction malleability, providing modest on-chain scaling, reducing SigOps complexity. etc.).
One proposal is Blockstream/Core's SegWit-as-a-soft-fork (SWSF) - which most people - including myself - have expressed support for.
However, over the past few months, closer inspection of SegWit reveals several serious and avoidable flaws (possibly due to certain less-visible political / economic power struggles) - leading to the conclusion that that SegWit is inferior in several ways when compared with other, similar proposals - such as Flexible Transations.
Why is Flexible Transactions better than SegWit?
It is true that SegWit would introduce make Bitcoin better in many important ways.
But it also true that SegWit would introduce make Bitcoin worse in many other important ways - all of which are due to Core/Blockstream's mysterious (selfish?) insistence on doing SegWit-as-a-soft-fork.
Why is it better to hard-fork rather than soft-fork Bitcoin at this time?
There are 3 clear and easy-to-understand reasons why most people would agree that a hard fork is better than a soft fork for Bitcoin right now. This is because a hard fork is:
simpler and more powerful
safer
more future-proof
than a soft fork.
Further explanations on these three points are detailed below.
(1) Why is a hard fork simpler and more powerful than a soft fork?
By definition, a soft fork imposes additional restrictions in order to ensure backwards compatibility - because a soft fork cannot change any existing data structures.
Instead, a soft fork must use existing data structures as-is - while adding (optional) semantics to them - which only newer clients can understand and use, and older clients simply ignore.
This restriction (which applies only to soft forks, not to hard forks) severely limits the freedom of developers, making soft forks more complicated and less powerful than hard forks:
Some improvements must be implemented using overly complicated code - in order to "shoe-horn" or "force" them into existing data-structures.
Some improvements must be entirely abandoned - because there is not way to "shoe-horn" or "force" them into existing data-structures.
https://zander.github.io/posts/Flexible_Transactions/
SegWit wants to keep the data-structure of the transaction unchanged and it tries to fix the data structure of the transaction. This causes friction as you can't do both at the same time, so there will be a non-ideal situation and hacks are to be expected.
The problem, then, is that SegWit introduces more technical debt, a term software developers use to say the system-design isn't done and needs significant more work. And the term 'debt' is accurate as over time everyone that uses transactions will have to understand the defects to work with this properly. Which is quite similar to paying interest.
(2) Why is a hard fork safer than a soft fork?
Ironically, supporters of "soft forks" claim that their approach is "backwards-compatible" - but this claim is not really true in the real world, because:
If non-upgraded nodes are no longer able to validate transactions...
And If non-upgraded nodes don't even know that they're no longer able to validate transactions...
Then this is in many ways actually worse than simply requiring an explicit hard-fork upgrade (where at least everyone is required to explicitly upgrade - and nodes that do not upgrade "know" that they're no longer validating transactions).
It is good to explicitly incentivize and require all nodes to be in consensus regarding what software they should be running - by using a hard fork. This is similar to how Nakamoto consensus works (incentivize and require all nodes to be in consensus regarding the longest valid chain) - and it is also in line with Satoshi's suggestions for upgrading the network.
So, when SegWit supporters claim "a soft-fork is backwards-compatible", they are either (unconsciously) wrong or (consciously) lying.
With SegWit, non-upgraded nodes would no no longer be able to validate transactions - and wouldn't even know that they're no longer able to validate transactions - which is obviously more dangerous than simply requiring all nodes to explicitly upgrade.
https://zander.github.io/posts/Flexible_Transactions/
Using a Soft fork means old clients will stop being able to validate transactions, or even parse them fully. But these old clients are themselves convinced they are doing full validation.
(3) Why is Flexible Transactions more future-proof than SegWit?
https://zander.github.io/posts/Flexible_Transactions/
Using a tagged format for a transaction is a one time hard fork to upgrade the protocol and allow many more changes to be made with much lower impact on the system in the future.
Where SegWit tries to adjust a static memory-format by re-purposing existing fields, Flexible transactions presents a coherent simple design that removes lots of conflicting concepts.
Most importantly, years after Flexible transactions has been introduced we can continue to benefit from the tagged system to extend and fix issues we find then we haven't thought of today. In the same, consistent, concepts.
The basic idea is to change the transaction to be much more like modern systems like JSON, HTML and XML. Its a 'tag' based format and has various advantages over the closed binary-blob format.
For instance if you add a new field, much like tags in HTML, your old browser will just ignore that field making it backwards compatible and friendly to future upgrades.
Conclusions: Flexible Transactions is simpler, safer, more powerful and more future-proof (and even provides more scaling) than SegWit
SegWit has some good ideas and some needed fixes. Stealing all the good ideas and improving on them can be done, but require a hard fork.
Flexible Transactions lowers the amount of changes required in the entire ecosystem.
After SegWit has been in the design stage for a year and still we find show-stopping issues, delaying the release, dropping the requirement of staying backwards-compatible should be on the table.
The introduction of the Flexible Transaction upgrade has big benefits because the transaction design becomes extensible. A hardfork is done once to allow us to do soft upgrades in the future.
[Flexible transactions] introduces a tagged data structure. Conceptually like JSON and XML in that it is flexible, but the proposal is a compact and fast binary format.
Using the Flexible Transaction data format allows many future innovations to be done cleanly in a consistent and, at a later stage, a more backwards compatible manner than SegWit is able to do, even if given much more time.
On size, SegWit proposes to gain 60% space. Which is by removing the signatures minus the overhead introduced. Flexible transactions showed 75% gain." -
ydtm
" - rockymc
" - blockologist
