When writing my thread on Taproot signature commitments I found an actual criticism of the upgrade.

I am still very PRO Taproot even with the downside I will layout.

0/

1/ As I highlighted in my thread, Taproot changes the signature to now commit to the other inputs' previous utxo. This has some definite upsides that I stated already, but it will also have some downsides, especially for light clients. https://twitter.com/benthecarman/status/1334973770084323328

2/ The downside stems from retrieving the previous utxo for every input. Since the previous utxo is not actually in the transaction it is normally retrieved from the wallet that will store them for later.

3/ Generally, this is fine for normal transactions but can complicate things for dual funded sends. By dual funded sends, I mean anytime you are signing a transaction that has someone else's utxos as well.

4/ This is a problem because your wallet likely doesn't have their utxos stored and would need to look on chain for them. This could mean requesting them from a server or having to do a rescan to find the utxos.

5/ This could mean that wallets will take shortcuts and request the needed data from an electrum server or something similar. This could be really bad for privacy as you'd leak to unnecessarily which inputs you needed data for (and therefore aren't yours).

6/ This can be solved by having your counter party give you the previous utxo themselves. However, this requires some interactivity between the parties which is not ideal.

7/ This also will have some data size problems. For example if you are doing a large coinjoin, you will need the previous utxo for every input. If you have a 100 input coinjoin then you will need an extra 3100 bytes to be passed around to every peer.

8/ Finally, this change will likely require a decent sized refactor for a lot of software as they will need a whole new set of parameters. Luckily, if you have PSBTs implemented it should be easier to do as they have native support for having the previous utxo for inputs.

9/ It's not a show stopper but will definitely be annoying for developers and require some additional overhead in some protocols.

However, the trade off is totally worth it as we will remove some attack vectors when actually signing.