You’re right, I forgot about the second signature with SIGHASH_ALL.
Of course, v3 on HTLC transactions is still useful for package relay and saving space on chain.
IIUC this isn’t needed, for the reason @t-bast pointed out above?
Upon more reflection, I think your original intuition was correct – we need to presign remote v3 preimage spends but not remote timeout spends.
The edge case I had in mind was where Alice tries to get an HTLC-Success confirmed at the same time that the timeout path becomes spendable. But really Alice is screwed in that case even if we prevent Mallory from pinning her timeout path spend, since Mallory can just outbid Alice on fees for the timeout transaction while claiming the preimage spend path upstream. Really Alice needs to avoid getting so close to the timeout in the first place.
Yes, there’s some risk to the attacker. But as long as the attacker achieves a greater than 50% success rate, the pin pays off. Do we have strong evidence that an attacker cannot achieve that today?
Yeah, we’d need a new message to transmit HTLC signatures prior to the commitment signature. Naively, this doesn’t seem more complicated than adding new features to bitcoind or creating a preimage relay network. And it has the benefit that it actually fixes pinning, while the other solutions are only probabilistic ways to learn the preimage.