Published on: 2023-02-15T03:33:24+00:00
Several topics were discussed in a recent conversation regarding the security of multiparty transactions using Taproot. One concern raised was the potential for witness inflation and fee extraction in coinjoin transactions. It was noted that the last signer could manipulate the transaction's feerate by using an inflated witness, causing complications and wasting time value. To address this issue, several strategies were proposed, such as negotiating transactions at a lower feerate, enforcing minimal weights for non-witness data, requiring ownership proofs, and imposing minimum feerates or confirmation ages for inputs. It was also emphasized that full Replace-by-Fee (RBF) is necessary to ensure incentive compatibility in multiparty transactions.Another topic of discussion was a bug identified in Taproot where the same Tapleaf could be repeated multiple times within the same Taproot, potentially with different Taplevels and Tapfee rates. To mitigate this bug, it was recommended to always have knowledge of the entire Taptree when interacting with someone's Tapspend. Additionally, the CODESEPARATOR opcode could be used to prevent signature migration within or between branches.An email conversation between Yuval and LL highlighted a potential attack scenario in multiparty transactions, involving one participant unfairly extracting fee contributions from others. This exploit takes advantage of the variable size of Taproot spends by using a larger signature for the last input signed, reducing the feerate without affecting absolute fees. To prevent this attack, several mitigations were proposed. Negotiating a lower feerate ahead of time and establishing a minimum feerate that the attacker cannot go below was one solution. Another mitigation was enforcing a minimum weight for non-witness data in the transaction before considering it fully constructed. In a centralized setting with BIP-322 ownership proofs, the server could reject signatures that do not match the spend path specified in the ownership proof. Publicly verifiable protocol transcripts and requirements for minimum feerates or confirmation ages for inputs were also suggested as deterrents.Each mitigation proposed has its limitations and trade-offs. Pinning attacks can prevent RBF, but minimum confirmation age may not be applicable to lightning channels. Therefore, it is recommended to implement multiple mitigations simultaneously to effectively prevent this type of attack.
Updated on: 2023-08-02T08:55:58.334868+00:00