Comparison between Segregated Witness and Elastic Transactions

Elastic Transactions was initially proposed as an alternative solution to SegWit, as it was clear that it was not a viable protocol upgrade.

This article attempts to explain why this is the case, compare the two solutions, and point out where they are completely different.

The reader should be aware that both solutions were originally designed to solve the same goal, which is to solve the scalability problem. Elastic Transactions aims to keep transactions simple and keep transaction size small, while Segregated Witness aims to avoid changes that cause old nodes to reject new transactions at all costs. Some people believe that it does this because after using Segregated Witness, old wallet nodes do not need to be upgraded.

The reality is that people will need to upgrade their wallets anyway. Bitcoin derives its value from the network, and we will see a ripple effect of upgrades from the network. Someone receiving a payment from a Segwit user will not have any progress reports on that payment unless they have a Segwit wallet. Users without Segwit wallets pay more. The networkization of the currency makes it necessary for almost everyone to upgrade. This raises the question, is the benefit of upgrading really there for the Segwit scheme?

Let’s first look at the end results to see what both solutions actually achieve.

characteristic

The last line is about an economic problem. With new pricing and new fee bidding, SegWit introduces a "two-track" economy. In the SegWit design, the signature portion of a transaction takes 75% less space than the rest, creating "two kinds" of data. The designers of SegWit decided that miners should pay 4 times more for the same salary. This is an anti-feature, where technical design attempts to influence economic policy, so it is very necessary to cross out the SegWit column.

Technical Debt Matrix

This section talks about design costs. As the term "technical debt" implies, it is not a one-time cost, but a real debt that requires more engineering cleanup work over time. Therefore, the actual cost that needs to be paid is reflected in the future production process and system stability.

Like any business or family, if you don't pay down your debts, you won't end up stabilizing and instead just running around without making any progress.

Future Development

Bitcoin is destined to exist for many years, even decades, because people want a stable currency.

In the future, SegWit will have only one function, which is to allow the Lightning Network to be deployed. The added capacity of SegWit is a joke compared to the current needs of the network. Even if the Lightning Network is successful, the added capacity of SegWit will not allow Bitcoin to grow as peer-to-peer cash.

Flex Trading is not a solution to increase capacity, it is a separate solution that combines well with any other capacity increase solution.

Additionally, FlexTransactions is an extensible format. Adding new fields to the format in the future is expected, and with FlexTransactions it can be done safely. FlexTransactions even specifies various forward-compatible fields in the specification to facilitate future deployment of soft (fork) upgrades.

deploy

The main impetus for SegWit was to avoid forcing people to upgrade. 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 of this means that there is in fact no "safe" Segwit upgrade strategy. The natural conclusion is that the complexity introduced to avoid forcing people to upgrade is wasteful, for no substantive benefit. This Segwit strategy is no better than elastic transactions.

Elastic Trading has not yet deployed an upgrade. The likely approach is that at a specific time in the distant future (in blocks), this upgrade will be activated, giving everyone a few months to upgrade before activation.

If the user does not upgrade by the deadline, his client will give a warning and he will be informed to upgrade. There will be no warning until the user upgrades. This will ensure that there is no loss of funds, security or privacy.

in conclusion

Elastic Transactions solve all the problems that SegWit aims to solve. In addition to the features that SegWit has, it also has some other features that are critical to the future healthy development of the Bitcoin chain.

In terms of the cost of keeping the network up and running, Resilience Transactions are far less expensive than SegWit in terms of both code writing and future work.

The goal of SegWit was to make it easier to deploy and allow people not to upgrade if they didn’t want to, but that goal was not achieved, and the resulting complex economic policy is simply bad design.

There is no reason to reject flexible transactions in favor of SegWit.