On the usage of the content of the double spend proof as a INV-hash:



this is useful to avoid re-downloading known invalid (previously failed) DSPs. A concept currently used in BU and others already for transactions and blocks. For instance if a BU node gets a BSV transaction, which fails due to missing outputs, then that iNV is put in the previously-failed list. This is the only place where we remember failing content in order to avoid re-download.



Similarly, there may be a valid-but-not-to-me double spend proof. For instance if an output is triple spend and thus there are two perfectly valid proofs. But only one will be accepted (first seen). And thus your change makes us promptly forget about the second and its hash. Which means that as more nodes send you that INV there is nothing that blocks you from re-downloading as you have no memory of rejecting it.



Then you continue into the suggestion to not use INV and GETDATA, which makes the previous point a little odd as your suggestion to hash stuff into a hash that can be used in INV is not needed if you make your own message to announce which output is being spent. If you want to avoid using INVs then you need not use the single hash either as a new message type can include anything.



Maybe it is indeed better to use a new message-type to announce it, but the INV system has spam protection and denial of service protection build in.



If you want to prioritize Double Spend Proofs, don't you think you'll end up reinventing the exact same rate limiting system to avoid denial of service based spamming of a node causing it to saturate the connection with only DSPs?



The system we have in place to do rate limiting of INVs does not, in actual fact, cause a problematic delay of a transaction moving though the network. Peter did the research on this and presented that in Italy. There is no difference for other types of INvs.



The maximum delay a single INV can possibly have is 5 seconds to any single peer. The probabilistic system makes the delay typically much less than that. BUT you are not connected to a single node that would propagate the proof. And you download it from the first that sends you the INV. So, the actual delay is not ranged between zero and 5 seconds. It is ranged between zero and 0.6sec (assuming 8 peers). So an average of 0.3 sec.



Next that, it is practically speaking useless to let a double spend proof outrace the transaction it is about, by introducing a new message format, as you need the transaction accepted and in your mempool to actually start to validate the DSP. So it would just end up waiting before it would get forwarded.





Too long didn't read:



* Using INV & GETDATA message types gives you the benefit of their build-in (D)DOS protection and there is no benefit to out-running a transaction as they wait at every peer anyway. So while making a new message type is possible, it doesn't have the benefit you seem to think it has.



* The usage of the hash of the content is there to avoid bandwidth waste, and its been in the client for ages. Change to a different INV-ID and you need to solve this problem again to avoid downloading the same thing from every one of your peers, only to immediately toss it again...