On Selective Disclosure,
I think we're going to need to add simple multisig semantics to the attestation due to its lack of script capability. Would that help? Separate multisig semantics like quorum and total would be needed for each class of key, so that even if Schnorr signatures can be broken (or one or two of the other PQC signatures even), they don't count towards the quorum of the other signature types.
On Attestation structure,
What prevents arbitrary data being hashed and then included in the attestation is, each signature public key pair must be able to verify the transaction message in order to be considered a valid transaction. In other words, each public key and signature pair is validated against the transaction message upon transaction verification.
On Multisignature 256-bit security,
To be honest, I've read this a couple of times and I will admit I don't understand this attack. Can you provide more details on how it works, and how it might be possible to mitigate?
On General comments,
I agree with the worst-case transaction verification concern. I'll need to put some work into detailing NIST I variants and their signature verification times, and then computing worst-case scenarios for different discount constants.
On 128-bit security... Yes, I'm coming to realize that too. It's been a common point of feedback.
On adding three schemes, there are a couple of advantages of this. First, wallets can automatically decide how many signatures to add based on the amount being spent. This then acts as a sort of MEV opportunity for miners, because the higher the value of the transaction, the more signatures might be included, which increases fee revenue. Also, it addresses Matt's concern about security assumptions. There's a strong desire for SLH-DSA support, even though it's so large. However, from a practicality standpoint (thinking of plebs), it will make sense to include the smaller ML-DSA and FN-DSA also. While it does increase complexity, I believe that a libbitcoinpqc library, as mentioned in the BIP, will serve as a useful analogue to libsecp256k1. It's also worth noting that in my position at Anduro, I have resources to put into building such a library. Hopefully this can help meet the expectation of a well specified and implemented consensus level library.
On signature aggregation, yes, I'm excited to see those developments in FN-DSA, and maybe we can see that filter into SLH-DSA as well. Hopefully those improvements will be ready once the time comes to activate.