Yes, there is a need. While there is no need for there to be more than one proof per outpoint, there can be an infinite amount of such proofs. And we want to be able to differentiate before we download the proof which one it is. As such, the hash-ID is not just an ID for the outpoint. It is an ID for the entire proof. The ID is a hash of the entire content to protect from altering the contents. Much like this is the case in most of the protocol (tx, block, etc). For instance you see a transaction being advertised by INV and if after download the transaction doesn't validate its txid is remembered and we don't download it again later. I have a patch for Flowee doing the same for proofs, that a proof is only downloaded once. Even if its tossed as invalid. If you were to use your suggestion of using an outpoint, the following attack is possible; Person intents to double spend outpoint O.

Person sends an invalid (not even validating) proof with ID based on 'O'

Node downloads, rejects and blacklists hash.

Person double spends and is certain no node will learn about it. If nodes do not black-list already validated but rejected proofs then sending INVs will cause a lot of bandwidth to be burned to send the same thing again and again. Hope that's clear. Let me know if its not.

Yes, there is a need. While there is no need for there to be more than one proof per outpoint, there can be an infinite amount of such proofs. And we want to be able to differentiate before we download the proof which one it is. As such, the hash-ID is not just an ID for the outpoint. It is an ID for the entire proof. The ID is a hash of the entire content to protect from altering the contents. Much like this is the case in most of the protocol (tx, block, etc). For instance you see a transaction being advertised by INV and if after download the transaction doesn't validate its txid is remembered and we don't download it again later. I have a patch for Flowee doing the same for proofs, that a proof is only downloaded once. Even if its tossed as invalid. If you were to use your suggestion of using an outpoint, the following attack is possible; * Person intents to double spend outpoint O. * Person sends an invalid (not even validating) proof with ID based on 'O' * Node downloads, rejects and blacklists hash. * Person double spends and is certain no node will learn about it. If nodes do not black-list already validated but rejected proofs then sending INVs will cause a lot of bandwidth to be burned to send the same thing again and again. Hope that's clear. Let me know if its not.