How to deal with transaction malleability and RBF
Transaction malleability
In Bitcoin and similar cryptocurrencies, a phenomenon exists, called "transaction malleability", where, in some cases, arbitrary third parties can take a broadcasted transaction, and modify it in a way that preserves the validity of its digital signatures, but changes the txid of the transaction. The third party can then broadcast the modified transaction. Since the modified transaction is just as valid as the original transaction, it has some probability of being included in the blockchain instead of the original one. As soon as (one of the variations of) a transaction gets definitively included in the blockchain, its txid becomes permanent.
Obviously, the effects of the transaction are unchanged in this process, or otherwise it would be considered a security hole in the cryptocurrency. The third party cannot, for instance, change the destination of the funds. The fact that the txid can be changed is not normally considered a big deal(*).
RBF
In addition to transaction malleability, there is a method called "Replace By Fee" (RBF). The purpose of RBF is to deal with changing transaction fee prices on the blockchain. Wit RBF, when the sender of a transaction discovers that the original transaction has too low fees to be included in the blockchain in a timely manner, it creates a replacement transaction that has higher fees. They spend the same inputs (they are double-spends of each other), so only one of them will be accepted in the blockchain, and miners are incentivized to pick the one with the higher fees.
Note that, when increasing the fees in RBF, the contents of the transaction are changed, and therefore the txid also changes.
The issue in TRP
In TRP, the sender of the transaction sends the txid to the receiver, and "The txid
should only be communicated if the transaction has been broadcasted".
Note that a broadcasted transaction is usually not immediately, definitively, included in the blockchain, so, for a while, txid changes due to transaction malleability and RBF are still possible.
This is problematic for the receiver.
If the receiver receives funds through a replacement transaction with a different txid, it has to discover the link between the information received over TRP and the replacement transaction.
Moreover, depending on regulatory requirements, it may have to be able to prove this link.
There are some similarities between the original transaction and the replacement transaction, that can be used to establish the link. For instance, they send to the same destination address (which is known by the receiving VASP). This is not a reliable link though, even when the destination address is only shared with the sending VASP through TRP: as soon as the original transaction is broadcasted, the destination address becomes public knowledge, and others can craft other transactions to that address to confuse the receiving VASP.
Another similarity is that they spend the same coins (UTXOs). The receiving VASP isn't guaranteed to know what coins were spent by the original transaction tough: the txid alone isn't sufficient to learn this. The receiving VASP can often obtain this information by receiving the original transaction over the (Bitcoin) P2P network. This is not guaranteed to work though: if the original transaction is very quickly replaced by a replacement transaction, (Bitcoin) nodes aren't likely to forward the original transaction anymore.
Solutions
Without changes to the protocol, a receiving VASP could e.g. operate like this:
- Normally, it just works (transaction gets included in the blockchain without txid changes)
- If the original transaction is received but a replacement transaction ends up in the blockchain: store the original transaction as evidence. Normally, the replacement transaction should send the same amount to the destination address. If not: rare occurrence that needs manual judgement.
- If the original transaction is not received: look for transactions that send the expected amount to the destination address. If there's only one, assume that's the one from the sending VASP (even though there's no strong evidence). In case blockchain analysis suggests otherwise, or in case of multiple matching transactions: rare occurrence that needs manual judgement.
There's quite a few different cases, and some holes, in that process. I think it might be simplified and made more robust, if the sending VASP just sends the transaction itself over TRP. In case of RBF, it might make sense if the sending VASP has the opportunity to send the replacement transaction over TRP whenever it increases the fees.
I'm not sure whether this should be part of the core protocol or an extension. Sending the tx itself over RBF might make sense for Bitcoin, but it can't be done on Lightning (for Lightning you probably need to define something to be the txid, but that's a different issue). Maybe it can't be done either with some other crypto technologies: I don't have a complete overview of what exists out there.
(*) In some smart contract schemes, the Lightning Network in particular, preservation of the txid is necessary, because pre-signed follow-up transactions depend on it. Such schemes are designed in a way to avoid the possibility of transaction malleability.