Are Micropayment channels still subject to malleability after BIP65?

Question

After BIP 65, are simple, unidirectional, MPC still subject to transaction malleability?

More specifically:

Is the payee at risk because of malleability? If yes, how? (as far as I understood, the payee is not at risk anymore)

Is the payor at risk because of malleability? If yes, how? (as far as I understood, the payee is still at risk)

Answer 1

There are a variety of different ways to construct a micropayment channel, but there are two designs that I think are particularly relevant to your question about "simple, one-directional, micropayment channels":

• Spillman-style micropayment channels: this was a commonly-described micropayment channel design prior to BIP65 (OP_CHECKLOCKTIMEVERIFY, CLTV). Spillman-style channels were first described by Jeremy Spillman in April 2013 and implemented in the BitcoinJ library in 2013.

• CLTV-style micropayment channels: this is a new way to construct a payment channel that became possible when CLTV became enforced in mid-December 2015. CLTV-style channels were described by BIP65 author Peter Todd as part of that BIP and implemented in two1-python in February 2016.

The following two sections describe how malleability relates to those two different types of micropayment channels.

Malleability in Spillman-style micropayment channels

BIP65 does not change how malleability affects Spillman-style micropayment channels, so the following description was true before BIP65 became enforced as well as now (at least for transactions which do not use segwit).

A Spillman-style micropayment channel is constructed using the following sequence of events between the Merchant (who is receiving the funds) and the Customer (who is spending the funds):

1. The Merchant gives his public key to the customer.
2. The Customer uses his public key and the Merchant's public key to construct a multisig P2SH address[1] that will require signatures from both the Merchant and the Customer to spend any funds paid to that address.
3. The Customer generates (but does not transmit) a transaction that pays the multisig P2SH address.
4. The Customer generates a second transaction that spends the first transaction back to one of the Customer's addresses, gives this transaction a locktime (so it can't be added to the blockchain until a certain time), and signs this transaction.
5. The Customer gives this second transaction to the Merchant (without giving him the first transaction), and the Merchant signs it and returns the signed transaction to the Customer.
6. Now the Customer will be able to use this second transaction, called the refund transaction, to claim a refund if the Merchant doesn't do anything by the time the locktime is reached.
7. With a backup refund assured, the Customer broadcasts the first transaction (called the deposit transaction) so it gets added to the blockchain.
8. Now the Customer can sign alternatives (called payment transactions) to the refund transaction which have no locktime, and so can be added to the blockchain immediately except for the fact that they also require the merchant's signature. By giving those to the Merchant, who can co-sign them (without returning them to the Customer), the Merchant can be assured that he can add them to the blockchain at a point earlier than when the refund transaction becomes valid.

The problem with malleability occurs in the seventh step above, when the deposit transaction is broadcast. If the transaction that gets added to the blockchain isn't byte-for-byte identical to the refund transaction which the Merchant signed in the fifth step, then the refund transaction is no longer valid because it attempts to spend a transaction with at different txid than the deposit transaction.

The Merchant can still voluntarily work with the Customer to return the Customer's money, but this means we don't have the trustless-style micropayment channels that we want.

A note on segregated witness (segwit): because segwit eliminates the type of malleability which would allow someone to change the txid of the deposit transaction without the Customer's permission, transactions that use segwit can safely use Spillman-style micropayment channels without risk of malleability-caused problems. As of this writing, segwit is not implemented on mainnet, but I expect it will be sooner or later, so I'm describing this here for future readers of this answer. Note that segwit is an optional feature that the Customer would already have to be using in order to eliminate malleability in this case, so activation of segwit by itself does not automatically eliminate malleability in Spillman-style channels.

[1] Bare multisig (multisig without a P2SH address) may also be used.

Malleability in CLTV-style micropayment channels

A CLTV-style micropayment channel is constructed using the following sequence of events between the Merchant and the Customer. These steps will be identical both before and after segwit is activated.

1. The Merchant gives his public key to the Customer.
2. The Customer uses his public key and the Merchant's public key to construct a P2SH address that will require either of the following sets of conditions to be satisfied:
   1. Both the Merchant and Customer sign any transaction that spends from this P2SH address.
   2. Just the Customer signs any transaction that spends from this P2SH---but those spending transactions must have a locktime greater than the refund time.
3. The Customer generates and immediately broadcasts the deposit transaction. The Customer is assured their ability to generate a refund transaction on demand by Condition 2.2 above.
4. Now the Customer can use Condition 2.1 above to half-sign (sign 1-of-2 required signatures) payment transactions that pay the Merchant. The Merchant can generate the second signature (without providing it to the Customer) and be assured that he can broadcast the final payment transaction before the Customer can add a refund transaction to the blockchain that was generated under the terms of Condition 2.2.

This process eliminates the concerns with malleability in CLTV-style micropayment channels, although it does not eliminate the malleability itself. Because the Customer can generate the refund transaction at any time per Condition 2.2 above, he doesn't need to pre-commit to a particular txid; he can wait until the deposit transaction has been added to the blockchain and its txid made nearly immutable before generating the refund transaction.

If, despite waiting for multiple confirmations, malleability happens anyway, the Customer can always generate and sign a new refund transaction using his private key. That's because all that is necessary, according to Condition 2.2 in the P2SH address, is a signature from the authorized key plus a locktime past a certain date.

The Merchant can be affected by malleability if the deposit transaction txid changes after he has accepted any payments. For this reason, it is best for the Merchant to wait for the deposit transaction to receive at least one confirmation before the Merchant accepts any payment transactions (waiting for more confirmations will provide more security and is recommended for high values). Since the Merchant should be waiting for the deposit transaction to receive confirmation any way in order to prevent the Customer from double-spending it (which is also the case in Spillman-style channels), this source of malleability doesn't significantly affect the security model.

Conclusion

BIP65 did not fix malleability for older Spillman-style channels, but it did make possible CLTV-style payment channels that are not adversely affected by transaction malleability. Segwit will also fix malleability for Spillman-style channels when all inputs in the deposit transaction are spending from segwit outputs.

Answer 2

Yes. Since you cannot sign a signature and signatures in a transaction are used when calculating a txid, therefore only segregated witnesses or normalized txids would fix transaction malleability.