SegWit, Lightning, RBF…in Dash?

The community and newcomers to Dash keep asking about the future of Dash when it comes to technologies and solutions which are often discussed in other Cryptocurrencies. We’ve seen these questions appear in our forums, Reddit, Discord and also in real-life meetings with other Dash and crypto fans.

This blog post is my personal understanding and opinion on these topics. However, from the many discussions we had internally, I feel that most Dash developers would agree and that we have some consensus on this.

It is understandable that these topics get so much attention from the outside. Many of these solutions were sold as the next big thing which would solve many of the seen problems and limitations in cryptocurrencies, especially in Bitcoin. It is, however, important to acknowledge that we are not Bitcoin and our priorities and strategy differ in some important aspects. Our priority and strategy is to fix the underlying problems instead of offering solutions or workarounds for the symptoms.

The underlying problems in Bitcoin are very often rooted in the 1MB block size limit which constrains the maximum throughput of transactions in the network. The symptoms seen by users and merchants are high fees, slow confirmation times and transactions getting stuck in the network for very long times. Without the limitation on block size, all these symptoms would not manifest in the network.

We plan to scale on-chain, meaning that we will increase the maximum block size as needed and thus completely avoid the symptoms. This is our priority, and we are confident that this is achievable. We are confident in this because we have a large network of incentivized Masternodes, which are economically motivated to scale as well. The rewards gained by running a Masternode are high enough to afford proper hardware and still having room for a decent profit. This is very different to Bitcoin, where running full nodes is mostly on a volunteer basis and thus forces the network to scale at a much slower pace. Regular users will not be required to run full nodes in Dash as they can use SPV or light clients. Evolution is the next step in this, as from the users perspective its SPV on steroids.

Some Cryptocurrencies also have seen big price movement related to implementing these technologies. Please note that price increases are not our first priority and we will not make technical decisions based exclusively on that. Increases in price will happen naturally, because we deliver what is good for the network, users and merchants.

SegWit

SegWit is probably the most controversial change made in Bitcoin. It is so controversial that it resulted in a complete split of the Bitcoin community. It ended in Bitcoin being forked into 2 chains, one with SegWit (BTC) and one without SegWit (BCH). These two camps are now in a state that can only be described as war.

There are multiple reasons why SegWit resulted in this split. Many of these are technical and many seem to be political. It is not in the scope of this post to go into the details of the arguments from both camps.

There is however one conclusion that I’d like to make for Dash: We should not blindly adopt SegWit in its current form, simply because of the controversial nature of this technology. The controversy did not come out of thin air, both camps had very good reasons to follow and fight for one of the two sides. We should evaluate very carefully why we would need SegWit and if there are alternative solutions which would solve the same problems.

Lightning Network / Off-chain Networks

Some people also ask for Dash and Lightning. This question very often comes packaged with SegWit as they seem to be seen as one thing or at least highly dependent on each other. These are however two different technologies, independent from each other. SegWit makes implementing Lightning (and other off-chain networks) easier, as it removes many of the burdens caused by transaction malleability, this would however also be true for any other malleability fix.

Lightning promises to reduce fees to a minimum, to enable instant transactions and at the same time remove the load from the Blockchain and the P2P network.

High fees and slow transactions are however a direct consequence of too small blocks. It forces miners to act economically when they assemble new blocks, meaning that they prefer to only include transactions with the highest fees, leaving out all low fee transactions. This means, that if we manage to scale on-chain (increase maximum block size), these two use cases from Lightning become neglectable. As already written in the introduction, this is our first priority.

At the same time Dash already has InstantSend, which today can already easily compete with the promised speed of Lightning. There are some known limitations with InstantSend, which we are aware of. Fixing these will also have a higher priority than an off-chain solution. And we have some ideas in our pockets to fix these problems and improve the experience with InstantSend.

Reducing the load on the Blockchain and the P2P network is not enough for us to justify a higher priority on implementing Lightning. Scaling on-chain will always be of higher priority, which does not only include block size increases, but might also include other solutions to reduce transaction sizes.

Lightning is also far away from being bulletproof. There are still many open issues which directly have an influence on user experience. For example, it requires you to lock funds in channels and stay online 24/7 to make sure you actually receive a payment. This is unacceptable in a world were most users will need a functioning mobile wallet or want to use a web based wallet. This is not compatible to what we strive for with Evolution.

RBF (Replace by fee)

RBF in Bitcoin tried to solve the “transaction-forever-stuck-in-mempool” problem which Bitcoin faces everytime the blocks get full. The problem manifests when you send a transaction to the network which gets inserted into every nodes/miners mempool but at the same time has a fee that is not profitable for a miner to include it in a block.

The result is that the transaction stays there unconfirmed for a very long time, making it impossible for you to use the same inputs/funds on another transaction. Your funds are basically locked in that case. RBF solves this by allowing you to globally replace this transaction with a transaction that spends the same inputs with additional inputs to include more fees.

We believe that this is trying to tackle the problem not by its root, but by its symptoms. The symptom is the stuck transaction, but the root is actually the blocks being full and miners having no incentive to include low-fee transactions when there are transactions with higher fees available. The solution that we prefer is to not get to this point, and scale accordingly on-chain, as already written in the introduction.

And even if we get to this problem, Bitcoin 0.14 introduced a feature called “transaction packages”, which will also be included in Dash 12.3. This feature changes the way miners calculate the profitability of transactions. Instead of calculating the fee on a single transaction basis, miners create “packages” of chained transactions and calculate the fee of the whole package. This means, that if a miner has 2 transactions where the second one spends an output of the first one (chained transactions), it will sum up the size and fees and calculate the fee-per-byte based on this.

If unforeseen network demand ever results in full blocks and network congestion, you can still rescue your stuck transaction by sending another transaction which spends the change output of the stuck transaction. This second transaction would then include a higher than usual fee to also cover the fees for the first transaction. This immediately makes the first transaction, which has a too low fee on its own, profitable again.

As an alternative, merchants could pay your fees by relying on packaged transactions. They can simply create another transaction that spends the output of your transaction, which he can do because the output is designated to him. And they would increase the packages fee-per-byte the same way as if you would do it in the above example. Merchants might even be incentivized to do so as they are the ones waiting for the funds to settle.

This pattern is called CPFP (Child Pays For Parent) and is a good alternative to RBF. Both solutions require paying some extra fees as both add new inputs and outputs which need to be paid for. RBF does this in the first transaction while CPFP does this in a new transaction. CPFP thus requires a few bytes more (for the transaction header), but the resulting increase in fee is neglectable.

Schnorr Signatures

We’ve put some time into research of Schnorr signatures and actually found some good use cases for it, especially in some of the Evolution-related functionality.

It however turned out there might be an even better alternative: BLS (Boneh–Lynn–Shacham) signatures. It currently looks like we can implement the same functionality with BLS signature in an easier and more flexible way. Some properties of BLS signatures would also allow us to use them for many other use cases. For example, BLS signatures are deterministic and unique, meaning that for each signed message (e.g. a transaction), there is only one valid signature. This property even holds for aggregate and threshold signatures, which opens many new possibilities. Stay tuned for upcoming DIPs which will propose some ideas.

Transaction malleability

Transaction malleability is the possibility to change a transaction in a way that results in a changed transaction hash while the transaction itself remains valid.

This is mainly a problem for two reasons. The first one is that merchants, exchanges and other parties might rely on the transaction hash to verify that the transaction was confirmed on-chain. If the transaction gets confirmed with a different hash then the original transaction, this might give false-negatives. The most prominent case was MtGox, which failed to verify that outgoing transactions were confirmed and then resent new transactions to “fix” this.

The second problem occurs when chained transactions are being pre-built that rely on the second transaction spending outputs from the first transaction. Some schemes, for example as used in atomic swaps, require publishing the second transaction before publishing the first one. If the first transaction gets confirmed in a malleated form, the second transaction gets invalid.

There are multiple known ways to malleate a transaction.

Malformed signatures

In earlier versions of Bitcoin and Dash, the encoded signature could be modified so that the signature itself was still valid, but the encoding was malformed. Bitcoin and Dash ignored the malformed encoding but still used the correct signature when verification happened. This allowed anyone to modify a transaction and broadcast the modified version to the network.

This is fixed in Dash since block 245817 (2. April 2015). The fix is the same as used in Bitcoin (BIP66).

scriptSig malleability

A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY resulted in consumption of an unused value from the stack. As this value was not checked/used at all, it could be modified by anyone without invalidating the transaction.

For some time, Bitcoin and Dash had a soft rule that didn’t allow to relay transactions which had a non-zero value on the stack. This way only malicious miners were able to exploit this malleability type.

The next Dash version (12.3), will deploy a new rule to enforce the nulldummy value on-chain, meaning that not even miners will be able to exploit it. This is the same fix that Bitcoin deployed as part of the SegWit deployment and is specified by BIP147. We are however deploying this as an independent deployment (as we don’t deploy SegWit).

Malleability by re-signing

ECDSA signatures are not unique, meaning that for a single message (e.g. transaction), multiple valid signatures can be created. The owner of the private keys can thus simply re-sign the same transaction, which will result in a completely new signature and a new hash. This can only be exploited by the creator of the initial transaction, as possession of the private key is a requirement.

Fixing this type of malleability turns out to be much harder than the first 2 types and would require a solution that deterministically generates unique ECDSA signatures. Determinism can be ensured while signing, but the determinism can’t be validated when the signature is later validated.

Using non-ECDSA based signature schemes might turn out to be an easier fix. For example, BLS ensures determinism and uniqueness without any additional effort needed. Using BLS has other advantages, allowing other use cases which have higher priority than a malleability fix. But we’d happily accept the positive side effects of this ?

This type of malleability is technically, in some reduced way, like a double spend. The difference is that this “double spend” spends to the same outputs. So the same rules and limitations apply to this, for example the “first-seen-relayed-and-mined” rule, which reduces the risks of this malleability form to the same degree as a double spend.

Conclusion

The most serious forms are the first two forms, as these allow any external party to modify an observed transaction and relay it after modification. After the release of Dash 12.3., both will be prohibited on the Dash network.

The third form will be fixed in the future, but a fix is not of very high priority at the moment. Merchants and exchanges can actually already protect themself against this type of malleability, simply by not relying on the transaction hash and instead only relying on the inputs and output.

The MtGox example that is often brought up is not possible with the third form of malleability. It can only be exploited by the sender of the transaction and not by the receiver. In the MtGox case, the sender was MtGox itself and one of the two other malleability forms was used.

IPv6 support in Dash

There seems to be a misunderstanding about this topic in the community, as some community members seem to believe that Dash deliberately disabled/removed/broke IPv6 support in Dash.

IPv6 was never touched when it comes to normal p2p and node operations. Everyone can connect to the network with IPv6, with all the standard p2p functionally (e.g. transaction and block propagation) is working as expected. It’s even possible to run a full-node with IPv6.

There is however a requirement that only applies to masternodes: they must announce themself with an IPv4 address and must be able to serve connections with IPv4. If masternodes would not be required to do so, IPv4 clients/nodes would not be able to connect to these masternodes. Please note that IPv6 nodes with a IPv4/IPv6 dualstack are always able to connect to IPv4 nodes, it’s just the other way around that’s not possible.

Masternodes are meant to serve the whole network and all users. This is what they get rewards for, and we believe that this requirement is acceptable for masternodes as otherwise they would not fully fulfill their duties.

If IPv6 adoption ever gets to a point were IPv4 only clients can be neglected, we might reconsider the requirement on masternodes.

Staying up-to-date with Bitcoin code

Dash has an interesting history when it comes to the code base. It was initially forked from the Litecoin code base (which was a Bitcoin code fork). As Litecoin development ceased shortly after that time, Dash was re-forked from Bitcoin and due to lack of time and resources, further updates of the code base were done very sporadically, resulting in Dash staying on a quite old version of Bitcoin.

Recent history of updates and backports:

1. Until Dash 12.1, our code base was solely based on Bitcoin 0.12
2. Dash 12.2 included backports of a huge network refactoring from Bitcoin 0.13–0.14, which resulted in stability and performance improvements.
3. Dash 12.2.3 backported the “per-utxo” patch, which closed a critical and publicly known DDoS attack vector known as “Corebleed”. This brought a critical part of the code base up-to-date with Bitcoin 0.15
4. Dash 12.3 will include all improvements from Bitcoin 0.13 and 0.14, excluding SegWit and RBF related changes. This is already finished and can be found on Github in the develop branch. The new version will be released soon.

As you can see, we’ve put a lot of effort into updating our code base recently — we backported more then 800 Pull Requests and thousands of commits. We plan to continually perform more updates and backports, until we reach a point where it doesn’t make any sense anymore to continue doing this. This will be the case when Bitcoin and Dash diverge too much in it’s goals and priorities, which is already happening slowly. For example, Bitcoin has concentrated a lot of effort into SegWit for Bitcoin 0.15 and 0.16. At the same time we concentrate more and more on Evolution related features.

Author: Alexander Block
Original link: https://blog.dash.org/segwit-lighting-rbf-in-dash-9536868ca861