How to support as many coins as possible (while avoiding transaction malleability attacks).

Arwen is cross-blockchain layer-two protocol that allows traders to enjoy the liquidity and speed of a centralized exchange, while maintaining custody of their coins. Because Arwen is specifically designed for the trading use case, Arwen is designed to support as many blockchains and coins as possible. This include essentially all “Bitcoin derived” coins (Bitcoin, Bitcoin Cash, Litecoin, Zcash, etc), Ethereum and ERC-20 tokens.

Arwen is compatible even with the “lowest common denominator’’ of blockchains: specifically, those blockchains (like Bitcoin Cash, Zcash, and others) that are vulnerable to transaction malleability attacks. Transaction malleability attacks are an issue that typically affect layer-two protocols. In this post, we describe transaction malleability attacks and explain how Arwen avoids them.

Malleability!

Layer-two protocols

Arwen is layer-two blockchain protocol that falls into the same class of protocols as the Lightning Network. The Lightning Network only supports blockchains that have SegWit support, such as Bitcoin and Litecoin; this is because Lightning does not withstand transaction mallaebility attacks. Meanwhile, Arwen withstands transaction malleability attacks, and thus can support a larger number of blockchains, most notably Bitcoin Cash.

In a blockchain layer-two protocol, parties first lock up their coins in an on-blockchain smart contract. The coins locked in the smart contracts are then transferred between the parties via interactions that take place off-blockchain. Finally, the smart contract is closed on the blockchain, reflecting the parties’ balance, consolidated across all the off-blockchain transfers.

Our CEO describes transaction malleability attacks at the Fidelity Layer2 Blockchain Summit in Boston.

Transaction malleability attacks

“Bitcoin-derived” blockchains that lack SegWit support are vulnerable to transaction malleability attacks. Withstanding transaction malleability allows Arwen to support more Bitcoin-derived blockchains. We now dive into the transaction malleability vulnerability, and explain why it is an issue for layer-two blockchain protocols.

Consider a UTXO transaction T2 that spends the output of a transaction T1. T2 must therefore contain a pointer to T1. This pointer is called the TXID. The TXID is malleable: before the transaction is confirmed by the blockchain, it can be changed (“mauled’’) by anyone, without affecting the validity or contents of transaction T1.

Why is the TXID malleable? This follows because the TXID of T1 is the hash of (essentially) the entire transaction T1, including any digital signatures on T1.

Most “Bitcoin derived’’ blockchains use elliptic curve digital signatures, which are not deterministic. (Thus, a random value r is used to compute the signature sigma on message m.) This means that a party that holds the secret signing key can easily produce multiple valid signatures sigma1, sigma2, … on a single message m. Worse yet, even a party that does not know the secret signing key can take a valid signature sigma on a message m, and maul sigma to obtain a different valid signature sigma1 on m. Now, because TXID is the hash of (essentially) the entire T1, mauling the signatures on T1 results in a completely different TXID for T1.

Additionally, some parts of the transaction that are included in the TXID hash are not covered by the signature on the transaction, which creates an additional malleability problem.

Enter SegWit

SegWit solves the transaction malleability problem. With SegWit, the TXID hash is not computed over the signatures on the transaction. This solves the malleability problem, because now mauling the signature has no effect on the TXID. SegWit also removes other malleability vectors (i.e., parts of the transaction that are not covered by the signature).

Malleability and layer-two protocols.

Transaction malleability only affects layer-two protocols.

To see why, note that if T1 is already reliably confirmed on the blockchain, the security of the blockchain ensures that no one call maul the signatures on T1, and transaction malleability is irrelevant.

Meanwhile, consider a layer-two protocol where Alice holds the transaction T1, an off-blockchain transaction that spends an on-blockchain transaction T0. Next suppose that Alice transfers coins to Bob by sending Bob an off-blockchain transaction T2 that is signed by Alice and contains a pointer to T1.

Transaction malleability makes Alice’s signature on T2 is completely useless.

This follows because Alice can break the TXID pointing from T2 to T1 by mauling the signatures on T1; this means that T2 becomes an invalid transaction while T1 remains valid. Thus, T2 is useless for Bob.

This is exact reason why the Lightning Network, as currently designed, only works with blockchains that support SegWit.

Why Arwen avoids transaction malleability attacks

To avoid this problem, Arwen ensures that parties never need to send each other signatures on off-blockchain transactions that point to other off-blockchain transactions. Instead, parties only send each other signatures on off-blockchain transactions that point to on-blockchain transactions.

Taking this one step further, this means that if an off-blockchain transaction contains a smart contract, then each clause on that smart contract must require the signature of only one party. If a single clause required the signature of more than one party, then parties would need to send each other signatures on off-blockchain transactions that point to other off-blockchain transactions, which is vulnerable to transaction malleability.

Arwen is robust to transaction malleability, because each clause in every Arwen smart contract that is used in an off-blockchain transaction only requires the signature of a single party.

This is also one reason why Arwen does not use relative timelocks (namely the CheckSequenceVerify opcode of Bitcoin script). CheckSequenceVerify (which is used extensively in Lightning) provides a timelock which is relative to the time another transaction is confirmed on-blockchain. Instead, Arwen can only use absolute timelocks (namely, the CheckTimeLockVerify opcode). CheckLockTimeVerify allow a transaction output to be spent after a particular time, e.g. this output is spendable after May 5th 2019. This avoids transaction malleability attacks, because the time does not depend on the time the transaction is confirmed on the blockchain.

Diagram of transactions pointing to the user escrow for Arwen’s unidirectional RFQ protocol from the Arwen whitepaper. We suppose that the user has already received 1 BTC and is engaging in a trade for an additional 2 BTC. Transactions in color are only posted to the blockchain if a party becomes uncooperative. The lock represents as a signature.The circle-with-a-plus symbol is an XOR: only one of the transactions from the symbol can be posted to the blockchain. There are only two smart contracts involved in this transaction diagram: The 2-of-2 timelocked multisig on the user escrow (represented as (E and U) or (U and twA) in the diagram), and the HTLC on the off-blockchain puzzle transaction (represented as (x and E) or (U and tauA) in the diagram). To avoid transaction malleability, twA and tauA are absolute timelocks, and each clause in the off-blockchain puzzle transaction requires the signature of only one party. See the whitepaper for more transaction diagrams, and discussion on why they avoid malleability attacks.

Implications on protocol design

So what does this all mean?

Because Arwen must withstand transaction malleability attacks, our layer-two protocols must be designed with “one hand tied behind our back”. Namely, we must design secure protocols using (1) only absolute timelocks (rather than relative timelocks), (2) that are compatible with the very limited Bitcoin Script language (which is akin to assembly language with the addition of a few cryptographic opcodes) and (3) using extremely simple smart contacts, where every smart contract used in an off-blockchain transaction be such that only one party’s signature is required in each clause.

In other words, we have to build rich protocol functionality using extremely limited smart contract functionality.

This is the exact opposite of what is done when building protocols on Ethereum, which has a very rich set of smart contract functionalities available through the Solidity programming language.

Nevertheless, we think this is extremely fun: building rich protocols using extremely simple tools. To learn more about the Arwen protocol, have a look at the Arwen whitepaper.